How to Deploy a Next.js App to Production in 2026

Disclosure: This guide contains affiliate links. If you sign up through them, First Bridge Consulting may earn a commission at no extra cost to you. We only recommend platforms we actually deploy on for client projects — the rankings here are not for sale.

Next.js makes deployment look like a solved problem — and on Vercel, it nearly is. But "push to Vercel" isn't the right answer for every project. Some teams need to self-host for cost, data residency, or control. This guide covers the four real ways to deploy a Next.js app to production in 2026, when each makes sense, and a pre-launch checklist that applies to all of them.

TL;DR

• Vercel — the path of least resistance, built by the team behind Next.js. Best when you want zero ops and full feature support.
• Node server on a VPS — next start behind a reverse proxy on DigitalOcean or Hetzner. Best for cost control and full ownership.
• Docker — containerize once, run anywhere (any VPS, Kubernetes, or PaaS). Best for portability and consistent environments.
• Static export — for fully static sites with no server features. Host on any CDN/static host, cheapest of all.
• The catch: your choice must support the Next.js features you actually use — Image Optimization, ISR, middleware, and server components behave differently off Vercel.

First: which Next.js features are you using?

This determines what's possible. A marketing site and a dynamic app have very different deployment needs.

If you only ship static pages, static export is the cheapest path. The moment you use SSR, API routes, or ISR, you need a running Node server — Vercel, a VPS, or a container.

Option 1 — Vercel: zero-ops, full support

Connect your Git repo and Vercel builds, deploys, and serves your app on a global edge with preview deployments per pull request. Every Next.js feature works because Vercel builds Next.js. There's nothing to patch and nothing to configure for the common case.

Pick it when: you want to ship without thinking about infrastructure, and the usage-based pricing (bandwidth, image transforms, function execution) fits your budget. For most teams shipping a Next.js product, this is the default — and we explain why in our hosting guide.

Option 2 — Node server on a VPS

Build your app and run next start as a long-lived Node process on a VPS, behind Nginx or Caddy for TLS and static assets.

The production setup mirrors any Node app:

1. A Droplet or cloud server running current LTS Node.
2. next build then next start, kept alive by PM2 or a systemd service.
3. Nginx/Caddy in front terminating TLS (Let's Encrypt).
4. A deploy step — pull, build, restart — ideally automated in CI.

This is the cost-control and full-ownership path. Self-hosted ISR and Image Optimization need a little configuration (a cache handler and an image loader), but both work. DigitalOcean's docs cover the Node-on-VPS stack thoroughly; choose between DO and Hetzner with our comparison.

Option 3 — Docker: build once, run anywhere

Next.js supports a standalone output mode that produces a minimal, self-contained server — ideal for a small Docker image. Containerizing gives you a reproducible environment you can run on any VPS, a PaaS that takes containers, or Kubernetes.

Pick it when: you want portability, consistent dev/prod parity, or you're heading toward orchestration. It's the most flexible option and the foundation for scaling later. The official Next.js deployment docs document the standalone output and Docker setup.

Option 4 — Static export: cheapest, most limited

If your site uses no server-side features, next build with output: 'export' produces plain HTML/CSS/JS you can host on any static host or CDN — often free or near-free. No server, no scaling concerns. The trade-off is hard: no SSR, no API routes, no ISR, no middleware. Great for docs, marketing sites, and blogs; wrong for anything dynamic.

Pre-launch checklist (every deployment path)

• Environment variables set in production (and never committed to the repo).
• next build runs clean locally and in CI — no type or build errors.
• Image config correct for your host (domains allowed; loader set if not on Vercel).
• Caching headers / ISR revalidation behaving as intended.
• Custom domain + TLS configured and redirecting www/non-www consistently.
• Error monitoring and uptime checks wired up before launch, not after.
• A rollback plan — previous build or container tag you can revert to fast.

FAQ

Do I have to use Vercel for Next.js? No. Vercel is the easiest path and supports every feature, but you can self-host Next.js on a VPS, in Docker, or as a static export. Self-hosting trades convenience for cost control and ownership.

Does Image Optimization work when self-hosting? Yes, but it needs configuration — either Next.js's built-in optimizer (which requires sharp and adequate server resources) or an external image loader/CDN. On Vercel it's automatic.

Can I run ISR outside Vercel? Yes. Self-hosted Incremental Static Regeneration works with a running Node server (and a cache handler for multi-instance setups). It does not work with a fully static export.

What's the cheapest way to host a Next.js site? If it's fully static, a static export on a CDN is cheapest. If it needs server features, a small VPS (DigitalOcean/Hetzner) is usually cheaper than usage-based platform pricing once you have steady traffic.

Deploying a Next.js app and want it done right — CI, monitoring, and a rollback path included? Tell us your setup and we'll handle the deployment.