Deploying a Next.js App

The plain-language idea

next build doesn't produce one universal artifact — it produces one of three, chosen by the output option in next.config.ts, and each supports a different slice of what you've learned:

• Default (no output set) — a full Next.js server build. Everything works: proxy.ts, Route Handlers with real request-time logic, ISR, on-demand image optimization. It needs a Node.js server actually running next start (or an adapter-managed equivalent), not just static files on a CDN.
• output: 'standalone' — Next.js traces exactly which files your app needs (including select node_modules entries) and copies only those into .next/standalone, alongside a minimal server.js. This is built for small Docker images: no full node_modules install in the image, just the traced output plus manually-copied public/ and .next/static folders. It's still a real server — everything the default mode supports still works here too.
• output: 'export' — a fully static build: plain HTML/CSS/JS in an out/ folder, deployable on literally any static file host. In exchange, it drops everything that requires a server at request time: proxy.ts, cookies, rewrites/redirects/headers config, ISR, Server Actions, Draft Mode, Route Handlers that read the request, and dynamic routes without generateStaticParams(). next dev errors immediately on any of these, the same as setting export const dynamic = 'error'.

The newer piece is Adapters — a formal interface a hosting platform implements once (NextAdapter, pointed to via adapterPath in next.config.ts, or NEXT_ADAPTER_PATH for zero-config platform setup) so next build output maps cleanly onto that platform's infrastructure, instead of every app hand-rolling platform-specific glue.

See it in a real thing: what an adapter actually does with your build

// my-adapter.js — a minimal NextAdapter implementation
/** @type {import('next').NextAdapter} */
const adapter = {
  name: 'my-hosting-platform',

  async modifyConfig(config, { phase }) {
    if (phase === 'phase-production-build') {
      return { ...config /* platform-specific tweaks */ }
    }
    return config
  },

  async onBuildComplete({ routing, outputs, buildId }) {
    // outputs.appPages, outputs.appRoutes, outputs.prerenders, outputs.staticFiles...
    for (const page of outputs.appPages) {
      console.log('deploying page:', page.pathname, 'from', page.filePath)
    }
    // routing.dynamicRoutes tells the platform which paths need a live server
  },
}

module.exports = adapter

onBuildComplete hands the adapter structured build output — every prerendered page, every dynamic route, every static file — so the platform can package and route each piece correctly without parsing .next/ internals itself. This is the same underlying build output that made proxy.ts, ISR, and next/image each show a "Platform Support" table in their own docs: those tables are really asking "does this deployment target run a server that understands this output, or is it a static host that only serves files?"

What people usually miss

Watch out

• output: 'export' isn't a stripped-down version of the default mode — it removes an entire category of feature, not just performance overhead. Reaching for it on an app that uses proxy.ts or Server Actions means either a rewrite or the wrong output mode, not a minor config tweak.
• standalone still needs a running Node process. It's a smaller, self-contained deployment artifact for the same server-based app — not a step toward static hosting. public/ and .next/static aren't copied automatically; you copy them in after the build.
• A missing node_modules install isn't a bug in standalone builds — that's the entire point of Output File Tracing: only the files actually reachable via import/require/fs usage get copied in.
• Adapters are a build-output contract, not a hosting service. NextAdapter is an interface any platform can implement — modifyConfig adjusts the Next config per build phase, onBuildComplete receives the finished routing and output manifest to act on. It's infrastructure plumbing, not something most app developers write themselves.
• The "Platform Support" tables scattered across other lessons (proxy.ts, ISR, image optimization) are all answering the same underlying question — whether the deployment target runs a Next.js-aware server or adapter, versus serving static files with no server-side logic at all.

Why this matters in interviews

"Your app uses ISR and proxy.ts-based auth — could you deploy it as a static export to cut hosting costs?" tests whether a candidate connects specific features they've used back to the deployment model underneath them, rather than treating "deployment" as an afterthought disconnected from the App Router features the rest of the interview covered.