Deployment Overview

A Next.js app can be shipped in a few fundamentally different ways, and the right choice depends entirely on which features your app actually uses. An app built purely from static pages has very different hosting requirements than one built on Server Actions, dynamic rendering, and Incremental Static Regeneration. This page maps out the main options before the following pages go deep on Vercel, self-hosting, and static export individually.

The main options

Option	What it is	Pros	Cons
Vercel	The managed platform built by the creators of Next.js	Zero-config support for every App Router feature (ISR, Server Actions, Image Optimization, Edge Middleware); Git-connected deploys; generous free tier	Vendor-specific pricing at scale; less control over the underlying infrastructure
Self-hosting (Node.js server)	`next build` + `next start` on your own server, VM, or container platform	Full control over infrastructure, networking, and cost; works with any cloud provider	You own scaling, caching, monitoring, and zero-downtime deploys yourself
Static export	`output: 'export'` produces a folder of plain HTML/CSS/JS with no Node.js server required	Deployable to any static host or CDN (S3, GitHub Pages, Netlify); extremely cheap and simple	Loses Server Actions, dynamic Route Handlers, ISR, on-demand Image Optimization, and Middleware
Docker / container platforms	A containerized Node.js server, deployed to services like AWS ECS, Fly.io, Railway, or a Kubernetes cluster	Portable across cloud providers; plays well with existing container infrastructure	More moving parts to configure than a managed platform

Note

Anything that needs to run code on a request — Server Actions, dynamic Route Handlers, on-demand revalidation, cookie- or header-based rendering, Middleware — needs a platform capable of executing server-side JavaScript for every request. A plain static file host (an S3 bucket, GitHub Pages) cannot run that code, no matter how the app is deployed to it.

How to choose

Using Server Actions, ISR, on-demand revalidation, or Middleware, and want the least operational overhead: choose Vercel (or another Next.js-aware managed platform).
Need to deploy inside an existing cloud account, Kubernetes cluster, or on-prem infrastructure, and are willing to own the operational side: self-host with next build + next start, typically inside Docker.
The app is fully static (marketing pages, docs, a blog with no per-request logic) and cost or hosting simplicity matters most: use output: 'export' and put it on any static host or CDN.

Tip

You are not locked in at the start. It is entirely reasonable to build an app assuming a self-hosted Node.js server and move to Vercel later, or vice versa — the App Router code itself does not change. Static export is the one path that constrains which features you can use, so decide on that one early if cost or hosting simplicity is a hard requirement.