Build Pipeline Reference · Next.js 16 · App Router

The anatomy
of a Next.js build

Thirteen phases stand between your app/ directory and the .next folder you deploy. Every next build walks all of them — reading config, walking the dependency graph, compiling with SWC, splitting client from server, shaking the tree, chunking, minifying, pre-rendering, and emitting the manifests that make runtime routing possible. Click any node in the pipeline, any phase card, or any highlighted term to see exactly what happens and why it matters.

Phases

Diagrams

95+

Glossary terms

57%

Of original size

01 — Map

The build, visualised.

Source code enters at the top. A deployable .next folder falls out the bottom. Each block is one phase; the arrows show how output flows from one to the next, where the pipeline branches, and where parallel work rejoins. Click any node.

02 — Watch it shrink

One component, five phases.

The same file is rewritten at every stage of the build. Step through to watch a page.tsx lose its types, shed unused imports, fold its constants, and finally get crushed by the minifier — ending at roughly 57% of where it started.

03 — Phases

Thirteen phases, in order.

Each card is one phase of next build. Click for the deep cut: what actually happens, why it matters, what it costs in build time, and how it changes what ships to the browser. Every highlighted term is clickable too.

04 — Artifacts

The missing map: manifests, graphs and runtime lookup tables.

The build does not only emit JavaScript. It also emits maps about the JavaScript: which route owns which chunks, which server entry renders which URL, which paths were prerendered, which files a standalone server needs, and which Client Component chunk should be loaded when a Server Component references it.

Manifests from first principles

A manifest is a build-time lookup table that lets runtime code avoid guessing.

During authoring, relationships are implicit: folder names imply routes, imports imply dependencies, 'use client' implies a browser boundary, and generateStaticParams implies a finite set of dynamic paths. During production, the runtime cannot afford to rediscover all of that by walking your source tree. So next build resolves those relationships once and writes them down as JSON or JS manifest files.

Lock this in: a manifest is not the app itself. It is the app's index. The build creates the expensive truth once; the server, router, CDN adapter and browser use the index later to answer fast questions.

Source conventionsapp/, page.tsx, layout.tsx, route.ts, middleware.ts, metadata files.

Build graphsRoute graph, module graph, client graph, server graph, prerender graph.

Emit manifestsConcrete JSON/JS lookup tables inside .next/ and .next/server/.

Runtime lookupServer matches a URL, loads the entry, finds assets, cache rules and render mode.

Client navigationThe browser prefetches and loads only the chunks/payloads needed for the next route.

Family 1

Browser-facing metadata manifests

This is the public : app/manifest.json, app/manifest.webmanifest, or generated app/manifest.ts. It describes your web app to the browser: name, icons, theme color, display mode and start URL.

It is a web-platform file, not an internal bundler map.

Family 2

Next runtime manifests

These are private build outputs such as , , , and the RSC reference manifests.

They connect routes, chunks, server entries, static paths, middleware and Server Action references.

Family 3

Deployment and tracing manifests

These describe what must be copied or configured when the app is deployed: , , image config, font config and middleware metadata.

They matter most when self-hosting, containerizing, or building a minimal output: 'standalone' image.

How many manifests are there?

There is no single stable “count”; there are manifest roles.

A real .next/ folder can include different manifests depending on App Router vs Pages Router, middleware, Server Actions, fonts, images, output mode, bundler and static export settings. The important model is not “memorize one list”; it is “know which runtime question each manifest answers.”

The common set below covers the manifests you are most likely to see in a production App Router build. Some are JSON files, some are JS modules that assign data into a global runtime object, and some have extensionless base names paired with .json or .js outputs.

Manifest atlas

Common manifests and the runtime questions they answer.

Manifest / artifact

Where it usually lives

Who reads it

Question it answers

BUILD_ID

.next/BUILD_ID

Server + client asset loader

Which immutable version of the app is currently being served?

build-manifest

.next/build-manifest.json

Server renderer + client runtime

For a route, which JS/CSS files must be included or prefetched?

app-build-manifest

.next/app-build-manifest.json

App Router runtime

Which App Router pages map to which app chunks?

routes-manifest

.next/routes-manifest.json

Next server / adapter

Which redirects, rewrites, headers, dynamic route regexes and route metadata exist?

prerender-manifest

.next/prerender-manifest.json

Next server + cache layer

Which routes were prerendered, what are their data routes, and how should ISR/fallback behave?

app-paths-manifest

.next/server/app-paths-manifest.json

Server renderer

Which compiled server file corresponds to an App Router page or route handler?

app-path-routes-manifest

.next/server/app-path-routes-manifest.json

Server route matcher

How do normalized app paths map back to public URL paths?

client-reference-manifest

.next/server/app/**/client-reference-manifest.js

RSC runtime

When server output references a Client Component, which browser chunk exports it?

server-reference-manifest

.next/server/server-reference-manifest.*

Server Actions runtime

Which encrypted action IDs map to which server functions?

middleware-manifest

.next/server/middleware-manifest.json

Request router / platform adapter

Which middleware or proxy bundle should run before which routes?

react-loadable-manifest

.next/react-loadable-manifest.json

Dynamic import runtime

Which dynamic imports produced which loadable chunks?

required-server-files

.next/required-server-files.json

Self-host / standalone copy step

Which files must be present beside the production server?

What .next really contains

The output folder is three things at once: static assets, server program, and build bookkeeping.

The mistake is to think .next/ is “the bundle.” It is closer to a miniature filesystem database. Some files are served directly to browsers; some are executed by Node or Edge; some are read by the runtime to decide what to execute or serve.

That is why copying random pieces of .next/ often breaks production. The server code, hashed assets and manifests are coupled by the same .

.next/
├─ BUILD_ID                         # deployment version key
├─ build-manifest.json              # route → JS/CSS assets
├─ app-build-manifest.json          # app route → app chunks
├─ routes-manifest.json             # rewrites/redirects/dynamic matchers
├─ prerender-manifest.json          # SSG/ISR/fallback rules
├─ required-server-files.json       # files needed by next start
├─ static/                          # hashed browser assets
│  ├─ chunks/                       # route/shared/framework chunks
│  ├─ css/                          # extracted CSS
│  └─ media/                        # fonts/images copied into output
├─ server/                          # code executed on server/edge
│  ├─ app/                          # compiled App Router entries
│  ├─ middleware-manifest.json      # middleware/proxy routing map
│  ├─ app-paths-manifest.json       # app entry lookup
│  └─ server-reference-manifest.*   # Server Actions map
└─ cache/                           # build cache, usually kept for CI not deploy

Concept map

Do not collapse the build into one “bundle” idea. There are several overlapping graphs.

Route graphBuilt from folders and special files. It answers: “what URLs exist and what layouts wrap them?”

Module graphBuilt from imports. It answers: “what code does each entry point transitively depend on?”

Client graphCut from 'use client' boundaries. It answers: “what JavaScript must ship to the browser?”

Server graphEverything allowed to stay on the server. It can import databases, secrets and filesystem code.

Render graphStatic, dynamic, ISR and streaming decisions. It answers: “when is this route rendered?”

Asset graphChunks, CSS, fonts and media. It answers: “what files must be fetched for this route?”

Reference graphRSC Client Component references and Server Action references. It answers: “what ID maps to what real code?”

Deployment graphOutput tracing and standalone files. It answers: “what must be copied to run this server?”