Deploying a Next.js App in 2026: Four Routes Compared

Deployment advice for Next.js tends to collapse into a preference. It is more useful as a decision about constraints, because all four routes below work — they differ in what they cost you up front, what they cost you every month afterwards, and which failure they hide until production.

Assume throughout a realistic application rather than a demo: server components, incremental regeneration, image optimisation, a Postgres database and file uploads. Each of those exercises a different part of the deployment story, and the last two are where routes quietly break.

Route 1: managed platform

Setup: minutes. Connect the repository, add environment variables, done. Image optimisation, caching headers and incremental regeneration work without configuration, because the platform is built around this framework.

Where it bites: bandwidth pricing. An image-heavy publication generates far more egress than a typical dashboard, and the tiers are sized for the latter. Model your bill at ten times current traffic before committing, because the jump between tiers is where the surprise lives.

The failure it hides: writable filesystems. Code that writes uploads to local disk works perfectly in development and silently fails to persist on ephemeral infrastructure — the write succeeds, the file is gone after the next deploy or scale event. It is usually one function to change, but nothing warns you, and the symptom appears days later as missing images.

Route 2: container on a VPS

Setup: an afternoon, most of it TLS, a reverse proxy and a deploy script rather than anything Next.js-specific.

A standalone build in a container behind a proxy. Predictable monthly cost, no bandwidth billing surprises, and a persistent volume for uploads and the regeneration cache.

The persistent volume is the part people miss. Without it, uploads and the incremental cache vanish on every restart, and the failure is quiet.

What you now own: certificate renewal, log rotation, security updates, and being the person who notices when the disk fills. None of it is hard; all of it is yours.

Route 3: Kubernetes

Setup: days, not hours — and that assumes a cluster already exists.

Everything worked. Nothing about it was better than route 2 for a single web application. The features that justify Kubernetes — scheduling across many services, sophisticated rollouts, autoscaling on real load — do not apply to one Next.js app.

If you already run a cluster and this is service number fifteen, add it there and ignore route 2. If this is service number one, do not start here.

Route 4: static export

Setup: trivial, if it applies to you at all.

A static export is genuinely excellent — cheap, fast, trivially cacheable — and it requires that you have no server-side rendering, no route handlers and no on-demand regeneration.

An application with server actions, route handlers or a database is ruled out before you begin. This is worth stating plainly, because static export gets recommended enthusiastically to people whose applications cannot use it — and the incompatibility only becomes obvious after the build fails or, worse, after a route quietly stops working.

Side by side

	Setup	Monthly cost	You maintain	Good for
Managed platform	Minutes	Scales with bandwidth	Nothing	Almost everyone
VPS container	An afternoon	Flat and predictable	TLS, logs, updates, disk	Cost or data-residency constraints
Kubernetes	Days	Cluster cost	Everything	Teams already running one
Static export	Trivial	Near zero	Nothing	Genuinely static sites only

How to decide

Work down this list and stop at the first line that applies:

1. A data-residency or compliance rule constrains where the application runs. That decides it — a container you place yourself, on infrastructure you chose.
2. You already operate a Kubernetes cluster. Add it there. The marginal cost is small and the alternative is a second thing to maintain.
3. The application genuinely has no server-side rendering, route handlers or database. Static export, and enjoy it.
4. None of the above. Managed platform, and revisit only when the bandwidth bill starts to matter.

The last case covers most projects. The setup cost is minutes and the operational cost is nothing, which is difficult to beat before you have traffic. When the bill does start to matter, moving to a container on a VPS is an afternoon of work in exchange for a flat monthly cost — a good trade at that point and a premature one before it.

We know that is an unexciting recommendation, and we are making it anyway. Deployment is the least differentiated part of this stack now — all four routes work, and the decision should be made on your constraints rather than on anyone's benchmark. Which of the four is actually binding for you?