Deploying to Vercel
Vercel is the company behind Next.js, and its hosting platform is built to run Next.js apps with essentially no configuration. Every App Router feature — Server Components, Server Actions, ISR, Middleware, the Image Optimization API — works out of the box, and the deployment flow is built around connecting a Git repository once and letting pushes drive deploys from then on.
Git-connected, automatic deployments
The typical setup is: import a GitHub, GitLab, or Bitbucket repository into a Vercel project once. From then on:
Every push to the production branch (commonly
main) triggers a new production deployment automatically.Every push to any other branch, and every pull request, gets its own preview deployment with a unique URL.
Vercel detects that the project is Next.js and picks the correct build command and output directory automatically — no build configuration to write.
First deploy from the CLI (alternative to the Git integration)
npm install -g vercel vercel # deploy the current directory, prompts for project setup vercel --prod # deploy straight to production
Preview deployments for every pull request
Preview deployments are one of the most practical reasons teams pick Vercel. Every pull request gets a fully working, publicly reachable deployment of that branch — including a real backend for Server Actions and Route Handlers — that reviewers can click through before merging, instead of only reading a diff.
Environment variables
NEXT_PUBLIC_ are inlined into the client bundle at build time, exactly as they are locally; everything else stays server-only.Environment | When it applies |
|---|---|
Production | Deployments from the production branch |
Preview | Deployments from pull requests and non-production branches |
Development | Values pulled locally via |
Pull environment variables down for local development
vercel env pull .env.local