Route Segment Config and Runtimes

The idea in one sentence

Route Segment Config is a set of file-level export const values that let you override how a single route segment renders, caches, and which runtime it runs on.

The segment config exports

Each of these is a named export at the top of a layout.tsx, page.tsx, or route.ts. They apply to that segment and its children.

// app/blog/page.tsx — route segment config exports
export const dynamic = 'auto';       // 'auto' | 'force-dynamic' | 'error' | 'force-static'
export const revalidate = 3600;      // ISR: rebuild this route at most once per hour
export const runtime = 'nodejs';     // 'nodejs' (default) | 'edge'
export const fetchCache = 'auto';    // control the default caching of fetch() in this segment
export const dynamicParams = true;   // allow params not returned by generateStaticParams

dynamic — force the rendering mode; 'force-dynamic' renders every request, 'force-static' forbids dynamic APIs.
revalidate — seconds between background rebuilds; this is how you turn on ISR.
runtime — the execution environment, 'nodejs' or 'edge'.
fetchCache — override how fetch() calls in the segment are cached by default.
dynamicParams — when false, a param not listed by generateStaticParams returns a 404 instead of being rendered on demand.

Node.js runtime vs Edge runtime

Every route runs in one of two runtimes. The default, Node.js, gives you the full Node API surface. The Edge runtime is a smaller environment that starts faster and runs close to the user, at the cost of a limited API set.

// Opt a route into the Edge runtime
export const runtime = 'edge';

Choose by what the route needs:

Node.js (default) — full Node APIs, native modules, larger libraries, database drivers. Pick it when you need the whole ecosystem or heavy work.
Edge — tiny bundle, near-zero cold start, runs geographically close to the user. Pick it for lightweight, latency-sensitive routes like personalization, redirects, or simple auth checks — as long as they stay inside the limited Edge API set.

ISR through revalidate

Incremental Static Regeneration keeps a route static and fast while still letting it go stale and refresh on a timer. Set revalidate to a number of seconds and Next.js serves the cached static page, then rebuilds it in the background after that window.

// app/products/page.tsx — serve static, refresh in the background every 60s
export const revalidate = 60;

export default async function Products() {
  const products = await fetch('https://api.example.com/products').then((r) => r.json());
  return <ul>{products.map((p) => <li key={p.id}>{p.name}</li>)}</ul>;
}

The first request after 60 seconds triggers a background rebuild; visitors keep getting the fast cached page until the fresh one is ready.

flowchart TD
  A[Route segment config] --> B[dynamic]
  A --> C[revalidate for ISR]
  A --> D[runtime]
  D --> E[nodejs, full APIs, default]
  D --> F[edge, small, fast cold start, limited APIs]

Route segment config and the two runtimes