23 — Deployment Options — Node, Docker, Static Export, Adapters

The feature-vs-host trade-off turned out to be the entire deployment decision. The model that clicked: there are four target shapes — a Node.js server, a Docker container, a static export, or a platform adapter — and the choice is driven by which Next.js features I need versus where I'm forced to host [1]. The feature-vs-host trade-off is the decision, because some targets (static export) can't run features that require a server.

Node.js server — the full-feature default

Next.js can be deployed to any provider that supports Node.js [2]. I build the application and start a Node.js server with next start, and that server supports all Next.js features — SSR, ISR, route handlers, Server Components, middleware, the lot. If I need server-side rendering or any runtime feature, this is the baseline.

next build
next start

This is the most feature-complete target and the one most managed platforms (Vercel, Netlify with an adapter) effectively run under the hood.

Docker container — portable full features

Next.js can be deployed to any provider that supports Docker containers — including orchestrators like Kubernetes, or any cloud that runs Docker [3]. Docker deployments, like the Node.js server, support all Next.js features. The win is portability: the same image runs on any infrastructure, and I control the runtime environment precisely.

The Docker path matters when the org already standardizes on containers, when compliance requires a specific base image, or when the deployment target isn't a managed Next.js platform. The trade is operational overhead — I'm now responsible for the image, the scaling, the logging.

Static export — serverless, but feature-limited

Next.js enables starting as a static site or SPA, then optionally upgrading to features that require a server [4]. With a static export, the build produces pure HTML/CSS/JS that can be hosted on any web server that serves static assets — AWS S3, Nginx, Apache, a CDN.

The catch is in the same sentence: running as a static export does not support Next.js features that require a server [4]. No SSR, no ISR, no route handlers, no Server Functions, no middleware. The app must be statically generatable at build time. If every page can be SSG, static export is viable and gives the cheapest, most portable hosting. If any page needs a server, it isn't.

Adapters — platform-tuned deployment

Next.js can be adapted to run on different platforms to support their infrastructure capabilities, including AWS Amplify Hosting, Cloudflare, Deno Deploy, Netlify, and Vercel [5]. An adapter wraps the Next.js build so it runs natively on a specific platform's runtime — Cloudflare Workers, Deno Deploy's edge, Netlify Functions, Vercel's edge network.

Adapters are the answer when the target platform is fixed (an org standardizes on Cloudflare, say) and I want Next.js to run there without managing a raw Node or Docker deployment. The adapter handles the platform-specific plumbing; I keep writing standard Next.js.

The decision

The choice collapses to two questions:

1. Which Next.js features do I need? If anything requires a server (SSR, ISR, Server Functions, route handlers, middleware), static export is out.
2. Where must I host? A managed Next.js platform (Vercel) is the lowest-friction; a container orchestrator if the org standardizes on Docker; a static host if every page can be SSG and cost/portability is the priority.

How I use this

For most projects, a managed platform (Vercel) is the path of least resistance — it runs the full Node server, supports every feature, and handles scaling, caching, and edge deployment. When the deployment target is fixed by the org, I reach for the matching adapter (Cloudflare, Netlify). Docker comes in when containerization is a hard requirement. Static export is the choice only for genuinely static sites — a docs site, a marketing page — where the cheapest hosting matters and no page needs a server. The principle: start from the features I need, then pick the simplest target that supports them.

References

[1] Vercel, "Deploying in Next.js," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/app/getting-started/deploying

[2] Vercel, "Node.js server," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/app/getting-started/deploying#nodejs-server

[3] Vercel, "Deployment with Docker," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/app/getting-started/deploying#nodejs-server

[4] Vercel, "Static export deployment," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/app/getting-started/deploying#static-export

[5] Vercel, "Deployment with adapters," Next.js Docs, 2024. [Online]. Available: https://nextjs.org/docs/app/getting-started/deploying#adapters

[6] "Visit the dedicated Docker roadmap," roadmap.sh, 2024. [Online]. Available: https://roadmap.sh/docker