▲ Next.js Advanced

What are Next.js deployment strategies and considerations?

Why Interviewers Ask This

This is a differentiating question used for senior and lead roles. Interviewers want to see if you can explain not just what happens, but why — and what the trade-offs are in different approaches.

Answer

Next.js applications can be deployed in multiple ways: 1. Vercel (native platform): zero-config deployment. Automatic builds on push, serverless functions for API routes and Server Components, edge network, ISR support, preview deployments per PR, analytics. Best experience for Next.js. 2. Node.js server (self-hosted): next build && next start starts a Node.js HTTP server. Use output: "standalone" in next.config.js for a minimal build including only necessary files. Docker Dockerfile: copy .next/standalone, .next/static, public → set CMD [node, "server.js"]. 3. Docker + Kubernetes: containerize with standalone output. Kubernetes for scaling, rolling deployments, health checks. 4. Static export: output: "export" — generates static HTML/CSS/JS for all routes. No server-side features (no API routes, middleware, SSR, ISR). Serve from any static host (S3, Netlify, GitHub Pages). 5. AWS: Lambda via OpenNext (open-source adapter), ECS/EKS for Docker, CloudFront for edge caching. 6. Cloudflare Pages/Workers: Edge-native deployment with Workers for middleware, D1/KV for data. ISR in self-hosted: requires Node.js server and filesystem caching. cacheHandler config to use Redis for distributed cache. Environment variables: runtime env vars via platform (Vercel env vars, K8s secrets/configmaps). CDN considerations: put CDN in front of Node.js server for static asset caching and DDoS protection.

Pro Tip

Before answering, structure your response: one-line definition → real-world analogy → concrete example from a project. This makes even complex Next.js answers easy to follow.