Vercel
Vercel is a cloud deployment platform built around the idea that deploying a web app should take minutes, not days. You connect a GitHub repository, and Vercel handles building, deploying, and serving the app — automatically, on every push.
It was built by the same team behind Next.js, so the two work especially well together. Most Next.js features (server components, API routes, middleware, ISR) just work on Vercel without extra configuration.
How deployment works
- Push code to GitHub (or GitLab / Bitbucket).
- Vercel detects the framework automatically and runs the build.
- The output is deployed to Vercel's global edge network, served from locations physically close to users.
- The old version stays live until the new one is ready. No downtime.
Every pull request gets its own preview deployment — a live URL you can share to test a feature before it merges. Once merged to main, the production URL updates automatically.
Key concepts
Serverless functions
Backend code (like Next.js API routes) runs as serverless functions. Each request spins up an isolated execution environment, runs the handler, and tears it down. No servers to manage or scale manually.
The trade-off: serverless functions have a cold start delay (first request after inactivity is slower), and in-memory state (like a rate-limit Map) doesn't persist across requests or instances.
Edge functions
Code that runs on Vercel's edge network, physically close to the user, before the request even reaches your main server. Useful for redirects, auth checks, and lightweight middleware. Lower latency than a full serverless function.
Next.js middleware (or proxy.ts in Next.js 16) runs at the edge by default.
Environment variables
Configured per project in the Vercel dashboard. Available at build time and runtime. Variables prefixed NEXT_PUBLIC_ are embedded into the client bundle; everything else stays server-side.
Limitations worth knowing
- In-memory state doesn't survive: each function invocation is isolated. A
Map-based rate limiter works locally but breaks across multiple serverless instances. Use a shared store (Redis, KV) for anything that needs to persist between requests. - Function timeout: serverless functions have execution time limits (10s on free tier, 60s on Pro). Long-running tasks need a queue or background worker instead.
- Cold starts: infrequently used functions take a moment to wake up.
Related notes
- Cloud Computing