Frontend Beauty
ESC

Type to search the knowledge base.

Deploying Next on Vercel

Deploy Next.js on Vercel: git integration, env vars, previews, build cache, and production checklist.

beginner3 min read
  • nextjs
  • deploying-next

Vercel is the platform that ships first-class support for Next.js features (ISR, middleware edge, image optimization, streaming). Deploying well is mostly git + env + build correctness, not special config.

Docs: Deploying, Vercel Next.js.

Typical flow

  1. Import the GitHub/GitLab/Bitbucket repo in Vercel.
  2. Framework preset: Next.js (auto-detected).
  3. Set Environment Variables for Production / Preview / Development.
  4. Push to main → production deploy; PR → preview URL.
# local production check
next build && next start

Catch build-only errors before CI burns minutes.

Environment variables

Mirror secrets from env docs. Preview deployments need their own DB/auth config or shared staging — do not point previews at production databases casually.

Build and output

  • next build compiles server/client graphs and static pages.
  • Image optimization and middleware run on Vercel’s infrastructure.
  • Check Functions region if latency-sensitive.

Preview best practices

Practice Why
Protect production env secrets Previews should not get prod keys by default
Use preview DB Avoid mutating real user data
Check mobile on preview URLs Catch layout before promote

Common failures

  • Missing env at build time for NEXT_PUBLIC_*.
  • Node version mismatch — set in project settings / package.json engines.
  • Relying on local filesystem writes — serverless is ephemeral.
  • Wrong root directory in monorepos.

Interview out-loud

“I deploy Next on Vercel via git integration with separate preview and production envs, run next build locally to verify, keep secrets out of NEXT_PUBLIC_, and treat serverless as stateless. Previews validate PRs before production.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides