Next.js Fundamentals: The App Router, Server Components, and the Caching Rules That Just Flipped

Part 11 of 12 · ~3 min

Deployment on Vercel

Next.js itself doesn't lock you into any particular host, but Vercel built the framework, and it shows in how much of deploying there just happens without being asked. Getting specific about what that automation genuinely covers is the only honest way to also get specific about the parts of the job it quietly leaves for you.

Three things a Vercel deploy takes care of without being asked:

• Each route becomes its own function. A Route Handler, or a page that renders dynamically, gets its own independently invoked serverless function rather than sharing one process with everything else. A traffic spike hitting the Stripe webhook doesn't need /dashboard's code pulled into memory to absorb it — every route scales on its own.
• Images get optimized without you building anything for it. Company logos on OpenRoles arrive however each employer happened to export them — a 4,000-pixel PNG from one, a badly compressed JPEG from another. next/image resizes and re-encodes each one on demand, matched to whatever's actually requesting it, with no pipeline or CDN configuration required from you.
• Every pull request gets its own live URL. A redesign of the employer dashboard is reviewable at a real, shareable link the moment the branch is pushed — no staging environment to stand up or keep synchronized by hand.

What you still have to build yourself

• An actual database. Vercel will run your application code all day; it isn't going to summon a Postgres instance into existence on its own. OpenRoles's job and applicant records still need somewhere to live, provisioned and connected to explicitly, exactly as on any other host.
• Anything that has to happen on a schedule. OpenRoles wants a Monday-morning digest — "12 new jobs this week" — sent to candidates who opted in. A serverless function exists only for the duration of the request that triggered it; nothing is sitting around watching a clock to fire that email on its own. That takes something external deliberately wired up — a scheduled trigger hitting a Route Handler, or a worker process running somewhere that isn't request-triggered serverless at all.
• Anything that has to stay running. Every serverless invocation has a ceiling on how long it's allowed to run. A live "you have a new applicant" notification held open over a WebSocket, or anything meant to keep going for minutes at a stretch, has no home in a model built around one request in, one response out. That kind of thing needs its own always-on service parked outside Vercel entirely, with OpenRoles's Next.js app treating it as a dependency to reach out to, not a route it hosts itself.

Line all three up and a pattern falls out: everything Vercel hands you for free is about executing your Next.js code — quickly, correctly, without you configuring a pipeline for it. None of it is about remembering anything, or continuing anything, once the request that triggered it has finished. Durability and long life are things you deliberately build and connect; they were never going to arrive as a default.