Study notes · 10% of the exam

Configuration, Environments and Deployment

Know when each setting takes effect (build time vs request time), what a static export cannot do, and what multiple self-hosted instances must agree on.

Key points

1
NEXT_PUBLIC_ values and the config env option are inlined during next build, in client and server code alike. Changing them later requires a rebuild.
2
Variables are looked up in process.env, .env.$(NODE_ENV).local, .env.local (skipped in test), .env.$(NODE_ENV), then .env. The first match wins.
3
Server code that must read env at runtime should render dynamically, for example after await connection(). serverRuntimeConfig and publicRuntimeConfig were removed in 16.
4
output: 'standalone' emits a minimal server.js configured by PORT and HOSTNAME. Copy public and .next/static yourself, and set outputFileTracingRoot in monorepos.
5
output: 'export' writes to out/ and drops server features: Server Actions, Proxy, cookies, rewrites, redirects, headers, ISR, Draft Mode and default image optimization.
6
Multiple instances need the same NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, the same deploymentId per deployment, and a shared cache handler with tag coordination.
7
Next.js 16 requires Node.js 20.9+, uses Turbopack by default (a found webpack config fails the build), removes next lint, and renames middleware to Node.js-only proxy.

Common traps

Restarting a container with a new NEXT_PUBLIC_* value changes nothing in browsers; the old value is baked into the bundle.
typescript.ignoreBuildErrors skips type checking entirely, so run tsc --noEmit separately.
A $ in a .env value starts a variable reference; escape it as \$ to keep it literal.

Read the source

Test yourself on Configuration, Environments and Deployment

Ten questions, with the answer and explanation after each one.