MENU
Vercel
Vercel is built by the same team that builds Next.js, so it is treated as the framework's native deployment target: new Next.js features are frequently designed with Vercel's infrastructure in mind, and most of them -- Incremental Static Regeneration, Server Actions, Middleware, streaming, on-demand Image Optimization -- run there without any extra configuration. Deploying elsewhere is fully supported (see Self-Hosting and Other Platforms), but Vercel is the baseline every other target is compared against.
Zero-Config Git Deploys
Connecting a GitHub, GitLab, or Bitbucket repository to Vercel is enough to deploy it -- there is no build script, Dockerfile, or server configuration to write. Vercel detects that the project is Next.js, installs dependencies, runs next build, and splits the result across static assets, prerendered pages, and serverless/edge functions automatically. Every subsequent push to the production branch triggers a new deployment.
The same detection works from the command line for one-off deploys or CI pipelines that don't use the git integration:
terminal:
npm i -g vercel
# from inside the project directory
vercel # deploys a preview build and prints its URL
vercel --prod # promotes/deploys straight to the production domainPreview Deployments
Every branch and every pull request gets its own deployment at a unique, shareable URL, built from that branch's code without touching production. Reviewers can click through the actual running app instead of reading a diff, and the deployment stays live for as long as the branch does. Merging (or pushing again) simply produces a new preview; promoting a specific deployment to production is a separate, explicit step.
The Edge Network
Static assets, prerendered HTML, and cached responses are distributed across Vercel's global Edge Network, so they are served from a location close to the visitor rather than from a single origin region. Middleware and any code marked to run on the Edge Runtime execute at those same edge locations, before a request reaches your application's regular serverless functions -- useful for redirects, auth checks, and A/B testing logic that should run with minimal latency ahead of the actual page render.
How Next.js Features Map Onto Vercel
Several App Router features are really just APIs for describing intent; Vercel is what turns that intent into running infrastructure without you having to provision anything by hand.
| Incremental Static Regeneration | Revalidated pages are regenerated in a serverless function on demand and the result is pushed back out to the Edge Network, so revalidate and on-demand revalidation work exactly as documented with no cache server to run yourself. |
| Server Actions | Each action is deployed as its own serverless (or edge) function, invoked directly by the client without you defining a Route Handler for it. |
| Middleware | Runs on the Edge Runtime at every Vercel edge location by default, rather than on a single server, so it adds negligible latency regardless of where a visitor connects from. |
| Image Optimization | The <Image> component's optimization endpoint is backed by Vercel's own image infrastructure -- resized, re-encoded, and cached variants are generated automatically with no loader configuration required. |
Environment Variables
Environment variables are set per-project in the Vercel dashboard (or via the CLI) and scoped independently to Production, Preview, and Development, so a preview deployment can safely point at a staging database while production points at the real one. Variables prefixed NEXT_PUBLIC_ are inlined into the client bundle at build time exactly as they are in any other environment; unprefixed variables stay server-only.