Part 11 of 12 · ~2 min
Deployment on Vercel
Next.js is a framework, not a hosting requirement — but Vercel (the company that builds Next.js) is where its deploy story is most fully automated, and it's worth being precise about why "it just works" holds up, so you can also be precise about the parts of your app it was never going to cover.
What actually happens behind a Vercel deploy:
- Per-route serverless (or edge) functions. Each Route Handler and each dynamically rendered page gets deployed as its own independently invoked function — not one giant server process handling everything. A spike in traffic to one route doesn't need every other route's code loaded into the same process to handle it, and routes scale independently of each other.
- Automatic image optimization.
next/image serves images resized and re-encoded (typically to a modern format like WebP or AVIF) on demand, per requesting device, without you standing up an image-processing pipeline or a CDN configuration yourself.
- Preview deployments per pull request. Every PR gets its own live, shareable URL running that exact branch's code, generated automatically — no manual staging environment to provision or keep in sync by hand.
What is not automatic
- A real database. Vercel hosts your application code — it does not conjure a persistent database out of nothing. You still provision one yourself (a managed Postgres, a hosted MongoDB, whatever fits) and connect to it explicitly, exactly like you would on any other host.
- Background jobs. A serverless function is invoked to handle one request and then goes away — there's no long-lived process sitting around to run a recurring nightly cleanup job or process a lengthy queue on its own initiative. That needs an external scheduler (a cron trigger, a queue-consuming worker running somewhere that isn't request-invoked serverless) explicitly wired up.
- Long-running processes. A serverless function has a maximum execution duration on every plan. A WebSocket server held open indefinitely, or a job that's genuinely expected to run for many minutes, isn't a fit for the per-request serverless model at all — those belong on a persistent process somewhere else, with your Next.js app calling out to it as a service rather than trying to run it as a route handler.
The general shape worth remembering: Vercel automates everything about running your Next.js code correctly and quickly, and automates nothing about state or work that needs to outlive a single request. Anything stateful or long-running is a deliberate integration you build, not a checkbox you flip.