"Serverless" is a slightly misleading name — there are still servers, you simply don't manage them. Your code runs in short-lived functions that a cloud provider spins up on demand, runs, and tears down, and you're billed for actual execution time rather than for a server sitting idle.
How it actually works
Instead of deploying to a server that runs continuously, you deploy a function. When a request comes in — an HTTP call, a file upload, a scheduled trigger — the platform starts an instance of that function, executes it, returns a result, and eventually shuts the instance down. Scaling from zero requests to thousands happens automatically, without you provisioning anything.
The real benefits
- No idle cost — you pay for execution, not for a server waiting around between requests.
- Automatic scaling — a traffic spike doesn't require you to manually add capacity.
- Less operational overhead — no OS patching, no server monitoring, no capacity planning for the underlying infrastructure.
Where it starts to hurt
- Cold starts — a function that hasn't run recently can take a noticeable moment to spin up, which matters for latency-sensitive requests.
- Execution time limits — most platforms cap how long a single function can run, which rules out long-running processes.
- Cost at high, steady volume — if you're running enough sustained traffic that a traditional server would rarely be idle anyway, a fixed server can end up cheaper than paying per invocation.
- Local state doesn't persist — each invocation may run on a fresh instance, so you can't rely on in-memory state surviving between requests.
Where we use it
Serverless is a strong default for typical web application backends — API routes, form submissions, scheduled jobs, image processing triggered by an upload — anything short-lived and bursty. It's exactly the model Next.js's own API routes and Server Actions are built around when deployed on a platform like Vercel.
Serverless removes a category of operational work, not a category of engineering thought. You still need to design for cold starts, timeouts, and stateless execution.
The rule of thumb
If your workload is bursty, unpredictable, or intermittent, serverless usually wins on both cost and simplicity. If it's a steady, high-volume, long-running process, a traditional server (or a container running continuously) is often the better fit. Most real applications end up using a mix of both, and that's the right outcome, not a compromise.