Serverless or Serverful?

Functions that scale to zero, a server that never sleeps — or both.

Eight questions. We will tell you when a $5 VPS beats the fancy edge platform.

1. What does your traffic look like?
2. What kind of work does your app do per request?
3. How sensitive are you to cold starts and tail latency?
4. Does your app need a full server environment?
5. How do you want the bill to behave?
6. How much server ops do you want to own?
7. What does your team already know?
8. How do you feel about platform lock-in?

Serverless vs serverful, in plain terms

Serverless means your code runs as functions on a platform's fleet — Cloudflare Workers, Vercel Functions, AWS Lambda. Nothing runs between requests, so nothing bills between requests. The platform handles scaling, patching, and capacity. In exchange you accept execution time limits, a constrained runtime, and pricing that is metered per request.

Serverful means a process that is always on: a VPS from Hetzner, a Fly Machine, a Railway container. You get a real server — persistent connections, background threads, local disk, any binary you can compile. In exchange you pay for it around the clock and own more of the operational story.

The trade-offs that actually matter

Cost shape. Serverless is a curve: $0 at rest, cents at hobby scale, and potentially painful at sustained high volume. Serverful is a flat line: the same $5–20/mo whether you serve ten requests or ten million (until you need a bigger box). The crossover point is real — steady traffic at scale often makes the boring server cheaper, while spiky or near-zero traffic makes serverless nearly free.

Long-running work. Functions have time limits — from seconds to a few minutes depending on the platform. Video encoding, big data imports, scraping runs, and anything that holds a WebSocket open for hours are shaped like a server, not a function. Platforms are closing the gap (queues, durable objects, containers-on-demand), but the default answer for long-lived work is still an always-on process.

Cold starts. Container-based serverless (Lambda) can add hundreds of milliseconds on a cold path; V8-isolate edges (Workers) start in single-digit milliseconds. A server that is already running has no cold start at all — that is what the idle bill buys you.

Ops burden. Serverless removes the pager for infrastructure: no patching, no capacity planning, no disks filling up. A managed container platform is a middle ground — you deploy an image, they keep it running. A raw VPS is the far end: cheapest per unit of compute, but you are the SRE.

Lock-in. A container runs anywhere; a Worker with platform bindings runs on that platform. That is not automatically bad — the productivity may be worth it — but it is a real cost you should price in before you depend on vendor-specific APIs.

When hybrid wins

Plenty of real apps are two workloads wearing one trench coat: a spiky request/response web tier plus steady background work (jobs, queues, realtime connections). Serving the web tier from serverless and running the workers on an always-on machine puts each workload on the pricing model that suits it. The cost is complexity — two deploy targets, two mental models — so only split when a single model genuinely fits badly.

Rules of thumb

Want a full stack recommendation — compute, database, storage, and a cost estimate at your traffic level? Describe your app and we will build the whole plan.