---
title: "23 — Deployment Options — Node, Docker, Static Export, Adapters"
uid: nextjs-deployment
tags: ["roadmap:nextjs", "deployment", "nodejs-server", "docker", "adapters", "static-export", "nextjs"]
excerpt: "Four target shapes — Node.js server, Docker container, static export, platform adapter — and the choice is driven by which features you need versus where you're forced to host."
date: 2026-08-13T03:27:58+0000
source: https://www.aveshina.my.id/en/blog/nextjs-deployment
---

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.

```figure
<svg viewBox="0 0 720 300" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="Four deployment targets from one Next.js build. Node.js server (all features), Docker container (all features, portable), static export (limited — no server features, runs on any static host), and adapter (Vercel/Cloudflare/Netlify/Deno, tuned to the platform).">
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">

    <!-- source -->
    <rect x="280" y="20" width="160" height="44" rx="8" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <text x="360" y="46" font-size="12" font-weight="700" fill="#1e1b4b" text-anchor="middle">Next.js build</text>

    <!-- four targets -->
    <line x1="360" y1="64" x2="120" y2="110" stroke="#64748b" stroke-width="1.5"/>
    <line x1="360" y1="64" x2="320" y2="110" stroke="#64748b" stroke-width="1.5"/>
    <line x1="360" y1="64" x2="500" y2="110" stroke="#64748b" stroke-width="1.5"/>
    <line x1="360" y1="64" x2="640" y2="110" stroke="#64748b" stroke-width="1.5"/>

    <rect x="40" y="110" width="160" height="80" rx="8" fill="#dcfce7" stroke="#16a34a" stroke-width="1.5"/>
    <text x="120" y="132" font-size="11" font-weight="700" fill="#052e16" text-anchor="middle">Node.js server</text>
    <text x="120" y="150" font-size="10" fill="#475569" text-anchor="middle">next start</text>
    <text x="120" y="170" font-size="9" font-style="italic" fill="#052e16" text-anchor="middle">all features</text>

    <rect x="240" y="110" width="160" height="80" rx="8" fill="#dcfce7" stroke="#16a34a" stroke-width="1.5"/>
    <text x="320" y="132" font-size="11" font-weight="700" fill="#052e16" text-anchor="middle">Docker</text>
    <text x="320" y="150" font-size="10" fill="#475569" text-anchor="middle">Kubernetes, any cloud</text>
    <text x="320" y="170" font-size="9" font-style="italic" fill="#052e16" text-anchor="middle">all features, portable</text>

    <rect x="420" y="110" width="160" height="80" rx="8" fill="#fee2e2" stroke="#dc2626" stroke-width="1.5"/>
    <text x="500" y="132" font-size="11" font-weight="700" fill="#7f1d1d" text-anchor="middle">Static export</text>
    <text x="500" y="150" font-size="10" fill="#475569" text-anchor="middle">S3, Nginx, CDN</text>
    <text x="500" y="170" font-size="9" font-style="italic" fill="#7f1d1d" text-anchor="middle">no server features</text>

    <rect x="600" y="110" width="100" height="80" rx="8" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.5"/>
    <text x="650" y="132" font-size="11" font-weight="700" fill="#1e1b4b" text-anchor="middle">Adapter</text>
    <text x="650" y="150" font-size="9" fill="#475569" text-anchor="middle">Vercel, CF,</text>
    <text x="650" y="164" font-size="9" fill="#475569" text-anchor="middle">Netlify, Deno</text>

    <text x="360" y="240" font-size="11" fill="#64748b" text-anchor="middle" font-style="italic">decision: which features do I need, and where must I host?</text>
    <text x="360" y="260" font-size="10" fill="#dc2626" text-anchor="middle">static export is the only one that drops features — the others keep all of them</text>
  </g>
</svg>
```

## 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](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](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](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](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](https://nextjs.org/docs/app/getting-started/deploying#adapters)

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

```quiz
Q: Which deployment targets support all Next.js features?
- Static export and adapters
- Node.js server and Docker container
correct: 1
explain: Both the Node.js server (next start) and a Docker container support every Next.js feature, including SSR, ISR, route handlers, Server Functions, and middleware.

Q: What's the key limitation of a static export?
- It can only be hosted on Vercel
- It doesn't support features that require a server (SSR, ISR, Server Functions, route handlers, middleware)
correct: 1
explain: A static export produces pure HTML/CSS/JS. Any feature needing a server is unavailable — every page must be statically generatable at build time.

Q: When is an adapter the right deployment choice?
- When you want the absolute cheapest hosting
- When the target platform is fixed (e.g., your org standardizes on Cloudflare or Netlify) and you want Next.js to run natively there
correct: 1
explain: Adapters wrap the Next.js build to run on a specific platform's runtime. They're the answer when the host is predetermined and you want native platform integration.

Q: The two questions that drive the deployment decision are…
- which framework version, and which package manager
- which Next.js features you need, and where you must host
correct: 1
explain: First, determine if any server features are needed (rules out static export). Second, determine the hosting constraint (managed platform, container orchestrator, or static host) and pick the simplest target that fits.

Q: A docs site where every page is statically generatable and cheapest hosting is the priority fits…
- a Node.js server with full SSR
- a static export on a CDN or S3
correct: 1
explain: A fully-static docs site needs no server features, so a static export is the cheapest, most portable option. SSR would be unnecessary overhead.
```