Deploying Next.js on Vercel: Preview, Env Vars, and Rollbacks

Deploying Next.js on Vercel is straightforward; using previews, env vars, and rollbacks well keeps releases safe and debuggable.

Preview deployments

Every push to a branch (or every PR) can get a unique preview URL. That lets you test before merging and share a link with stakeholders. Enable previews in the project settings; they use the same build as production but with the branch’s code. Use preview for staging or QA: run E2E tests against the preview URL or manually verify. Preview env vars can differ from production (e.g. point to a staging API); set them in Vercel for the preview environment so previews don’t hit production data.

Environment variables

Set env vars in the Vercel dashboard (or via CLI) per environment: Production, Preview, and optionally Development. Sensitive values (API keys, secrets) should be set in the dashboard and never committed. Use different values for preview (e.g. staging API URL, test keys) so previews don’t affect production. Reference vars in Next.js with process.env; for client-exposed vars use NEXT_PUBLIC_. Redeploy after changing env vars so the new values are baked into the build (or use runtime env if your plan supports it). Document which vars are required so new devs and CI can set them.

Rollbacks

If a deployment is broken, roll back to a previous deployment. In Vercel, open the Deployments list, find the last good deployment, and use “Promote to Production” (or the equivalent) so that deployment becomes the live one. No need to revert the Git branch first—you can fix the code in the repo and redeploy after. For critical fixes, roll back immediately to restore service, then fix forward. Optionally, use Vercel’s “Rollback” or similar if your plan exposes it; the idea is the same: point production at a known-good deployment.

Build and branch strategy

Connect the repo and set the production branch (usually main). Merges to that branch trigger a production deploy. Use branch protection and required checks so only reviewed, passing code gets to production. If you use previews for every PR, you can require “preview passed” before merge. With previews, env vars, and a clear rollback path, deploying Next.js on Vercel stays predictable and safe.

Summary

Use preview deployments for every PR or branch to test before merge; set preview-specific env vars. Manage env vars in the dashboard per environment; redeploy after changes. Roll back by promoting a previous deployment to production when needed. That’s a solid deployment flow for Next.js on Vercel.