Vercel

The platform built by the Next.js team. Zero-config deployment for frontend frameworks, with serverless and edge functions attached.

Pages

1. Deploy Next.js
2. Custom Domains
3. Environment Variables

---

1. What Vercel Is

A hosting platform where a git push becomes a deployment. It detects your framework, runs the build, puts static assets on a global CDN, and turns server code into serverless functions.

Feature	What you get
Git integration	Push to deploy, no pipeline to write
Preview deployments	A unique URL per pull request
Global CDN	Static assets served from the edge
Serverless functions	API routes and SSR, scaled automatically
Edge functions/middleware	Runs close to the user
Image optimisation	next/image handled for you
Analytics	Real-user Core Web Vitals
Instant rollback	Promote any previous deployment

---

2. The Deployment Model

git push
  → Vercel detects the framework
  → npm ci && npm run build
  → static assets → global CDN
  → server code → serverless functions
  → unique deployment URL
  → main branch also updates the production domain

Every deployment gets a permanent immutable URL. Nothing is overwritten — production is just a pointer at one of them. That is why rollback takes seconds: you move the pointer.

Preview Deployments

Every branch and pull request gets its own URL, with the PR comment updated automatically. Reviewers click a link instead of pulling the branch.

This is the single highest-value feature for a frontend team and a good thing to name when asked what you like about a platform.

---

3. Serverless Functions

Your API routes and server-rendered pages become serverless functions — a container spun up per request, then frozen or discarded.

Consequences You Must Know

Constraint	Implication
Stateless	No in-memory cache, session store or rate-limit counter — each invocation may be a different container
Cold starts	The first request after idle is slower
Execution limit	Seconds, not minutes — no long jobs
No persistent connections	Each invocation may open its own DB connection
Ephemeral filesystem	/tmp only, and it does not persist

The Database Connection Problem

The most important practical gotcha. Traffic spikes to 500 concurrent invocations, each opens a connection, Postgres has a limit of 100 — and everything fails.

Fix: a connection pooler between your functions and the database — PgBouncer, Prisma Accelerate, Neon's pooler, or Supabase's. Or use an HTTP-based database driver (Neon serverless, PlanetScale, Upstash) that doesn't hold a TCP connection at all.

This is the most common real-world serverless failure and a strong interview answer.

---

4. Edge vs Serverless (Node) Functions

	Node.js function	Edge function
Runtime	Full Node	V8 isolate, Web APIs only
Cold start	Slower	Near zero
Location	One region	Distributed globally
Node APIs (fs, crypto)	Yes	Limited
Database drivers	All	HTTP-based only
Best for	Business logic, ORM queries	Auth checks, redirects, geolocation, A/B tests

Edge sounds better but is often worse: if your function must query a database in us-east-1, running it in Singapore adds a round trip. Put compute near the data, not near the user, unless the function does no data access.

That nuance is worth stating — it's the answer that shows judgement rather than buzzwords.

---

5. Configuration

// vercel.json
{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "X-Content-Type-Options", "value": "nosniff" }
      ]
    }
  ],
  "redirects": [
    { "source": "/old-blog/:slug", "destination": "/blog/:slug", "permanent": true }
  ],
  "rewrites": [
    { "source": "/api/legacy/:path*", "destination": "https://old.example.com/:path*" }
  ]
}

Redirect changes the user's URL (301/302). Rewrite keeps the URL and proxies internally — useful for putting a separate backend under the same domain and avoiding CORS entirely.

Cron Jobs

{
  "crons": [{ "path": "/api/cleanup", "schedule": "0 3 * * *" }]
}

Hits a route handler on a schedule. Protect it — check a secret header, since the endpoint is publicly reachable.

---

6. Pricing and Limits — Know These

Interviewers sometimes ask "why would you not use Vercel?" These are the honest answers.

Concern	Detail
Bandwidth overages	The most common surprise bill — an image-heavy viral page
Function execution time	Charged by GB-seconds; a slow function is an expensive one
Image optimisation	Metered per source image
Long-running work	Not possible — use a queue and a worker elsewhere
WebSockets	Not supported on serverless functions
Vendor coupling	Some Next.js features are best (or only) supported here

When Vercel Is the Wrong Choice

• Persistent WebSocket connections (use Render, Fly, or a dedicated service)
• Long-running jobs, video processing, big data exports
• Very high bandwidth where a flat-rate host is far cheaper
• Compliance requiring a specific region or self-hosting

The Balanced Answer

"Vercel for the frontend and light API routes — the DX and preview deployments are genuinely worth it. Anything long-running, stateful or WebSocket-based goes on a normal server. The failure mode is treating serverless functions like a persistent server, especially with database connections."

---

7. Vercel vs Render vs Netlify

	Vercel	Render	Netlify
Model	Serverless + CDN	Long-running containers	Serverless + CDN
Next.js support	Best in class	Good	Good
Always-on server	No	Yes	No
WebSockets	No	Yes	No
Managed Postgres/Redis	Partner integrations	Built in	No
Background workers / cron	Cron only	Yes	Scheduled functions
Free tier sleeps	No	Yes (free web services)	No
Pricing model	Usage-based	Mostly flat per service	Usage-based

Common architecture: Next.js frontend on Vercel, Node API and Postgres on Render. You get the best frontend DX and a normal always-on backend with a database next to it.

---

8. Deployment Checklist

• [ ] Build passes locally with npm run build before pushing
• [ ] No secret behind NEXT_PUBLIC_
• [ ] Environment variables set for all three scopes (Production, Preview, Development)
• [ ] Database connection pooler configured
• [ ] Custom domain added with DNS verified
• [ ] Security headers set in vercel.json or next.config.ts
• [ ] robots.txt and sitemap.xml present
• [ ] Preview deployments protected if the site isn't public yet
• [ ] Analytics and Speed Insights enabled
• [ ] Error monitoring wired up (Sentry) with source maps uploaded

The Most Common Deployment Failures

Symptom	Cause
Build works locally, fails on Vercel	Case-sensitive imports — Linux build, macOS/Windows dev
Module not found	Dependency in devDependencies but needed at build time
Env var is undefined at runtime	Not set for that environment scope, or missing NEXT_PUBLIC_ for client code
Env var change had no effect	NEXT_PUBLIC_ values are baked in at build — needs a rebuild
Function timeout	Long-running work on serverless; move it to a queue
Database connection errors under load	No pooler

The case-sensitive import one catches almost everyone once: import Button from "./button" works on macOS and fails on Vercel's Linux builders.