Pick based on the shape of your cost curve, not on what's trendy on Twitter this month. VPS, managed PaaS, and serverless don't compete on price — they compete on where the bend in the curve sits, and most "which should I use" arguments miss that entirely because they compare a single month's bill instead of the shape the bill takes as traffic changes. A flat curve and a stepped curve and a per-invocation curve can all land on the same number in one specific month and diverge wildly the month after. Founders keep re-litigating this argument as if it were a taste question — Vercel versus a VPS, framed like a preference — when it's actually an arithmetic question with a knowable answer once the traffic pattern is known. Here's the actual three-way comparison, and a verdict at the end that picks one as the default, because a comparison that refuses to pick is worse than no comparison at all.
What does each one's cost curve actually look like?
A VPS is flat. A Contabo Cloud VPS 4 box at €5.50/month for 4 vCPU, 8GB RAM and 100GB SSD — that price good for the first 24 months, not indefinitely — costs exactly that whether it serves a hundred requests a day or a hundred thousand, right up until it runs out of capacity — at which point the cost doesn't creep, it steps, straight to the next tier's price. A managed PaaS like Render or Railway is stepped in a gentler way: a base plan (Render's always-on Starter service is $7/month, Railway's Hobby plan is $5/month with $5 of usage included) plus metered CPU, RAM and egress layered on top, so the bill moves with usage but inside a band, not in a straight line from zero. Serverless has no floor and no ceiling — Vercel's function billing charges for active compute time and invocations that actually happened, nothing when the app is idle, real money per request when it isn't. Three genuinely different shapes, and the right one depends entirely on which shape matches your actual traffic pattern, not which one sounds more modern. Where VPS vs PaaS vs serverless meets a revenue team, the practical guidance lives with the XenGrowth practice.
Dimension | VPS | Managed PaaS | Serverless |
|---|---|---|---|
Cost curve shape | Flat — same price regardless of usage, until it steps to the next tier | Stepped — base plan plus metered resources on top | Per-invocation — zero when idle, unbounded with real traffic |
Typical entry price | $7-25/month for a capable single server | $5-25/month base, plus usage | $20/seat plus a usage credit, then metered overage |
Operational burden | Highest — you own the OS, patching, and the deploy pipeline (or layer Coolify/Dokploy on top) | Low — the platform manages the server; you manage the app config | Lowest — no server exists to manage at all |
Scaling behavior | Manual, or self-built autoscaling across multiple boxes | Often automatic within the plan's ceiling | Automatic and effectively unbounded by design |
Cold starts | None — the process is already running | None on an always-on instance; possible on scale-to-zero tiers | Real, though warm-instance strategies reduce frequency |
Vendor lock-in | Lowest — plain Docker runs anywhere | Moderate — mostly portable containers, some platform config | Highest — platform-specific primitives like ISR and edge runtime APIs |
Best-fit stage | Predictable traffic, any DevOps willingness | Zero ops appetite, willing to trade some control for convenience | Pre-product-market-fit, or genuinely spiky traffic |
What happens to each curve as traffic actually grows?
The table above shows the shape; this is what that shape does as traffic moves from a trickle to something real. It's directional, not a precise forecast for any specific app — the point is which curve bends, not exact dollar figures, since that depends entirely on your own resource use. For the the operations side of this angle, see The XenGrowth resource library.
Traffic level | VPS | Managed PaaS | Serverless |
|---|---|---|---|
Early, low traffic | Comfortably inside the entry-tier box (Contabo's Cloud VPS 4 at €5.50/month for the first 24 months, for instance) | Comfortably inside the base plan (Render's $7/month Starter, Railway's $5 Hobby credit) | Comfortably inside the $20 seat's usage credit |
Steady growth | Same box, unless a specific resource (usually RAM) becomes the bottleneck first | Metered CPU/RAM/egress usage starts pushing toward the next plan tier | Credit exhausted; metered overage begins on whichever meter moves fastest — often invocations or ISR writes |
Real scale | One deliberate step to a larger VPS tier, then flat again at the new price | A meaningfully higher metered bill, but still bounded by the plan's own structure | Overage compounds across several meters at once — the least predictable of the three at this stage |
How much does operational burden actually differ between the three?
A raw VPS is the most work: you own the operating system, the firewall, the reverse proxy, the deploy pipeline, and every patch that ships for any of it — securing the box before anything else touches it is the first item on that list, not an optional one. A self-hosted PaaS layer like Coolify or Dokploy absorbs a lot of that without leaving the VPS model — Coolify vs Dokploy covers which one fits which situation — but the underlying server is still yours to patch and back up. A managed PaaS removes the server from the equation entirely: no OS to patch, no firewall rules to write, in exchange for less control over exactly how the app runs and a bill that moves with resource use rather than staying fixed. Serverless removes the most work of all — there's no always-on process, no capacity to size, nothing idling — but it replaces that operational simplicity with a different kind of attention: watching per-request cost the way you'd otherwise watch server load.
Do cold starts actually matter for a startup's users?
On a VPS, the answer is simple: there's no cold start, because the process is already running and stays running. An always-on managed PaaS instance behaves the same way; scale-to-zero tiers on some PaaS products reintroduce the problem the moment traffic resumes after idling, which is worth checking explicitly before assuming a PaaS plan is always-on by default. Serverless carries the real version of this cost, though it's smaller than its reputation — Vercel's Fluid compute model reuses warm function instances across nearby requests rather than cold-starting every single invocation, which meaningfully reduces how often a user actually experiences the delay. It doesn't eliminate it. For a marketing site or a low-traffic internal tool, an occasional cold start is invisible. For a product where every response is on the critical path of a user actually completing something — checkout, a live editing experience, anything real-time — that occasional delay is the kind of detail that decides the column, independent of everything else in this comparison. XenGrowth on governed AI marketing workflows goes further into AI agents and marketing automation.
How much does vendor lock-in actually cost you later?
A VPS running plain Docker containers is close to fully portable — the same Compose file runs on Contabo, Hetzner, or a laptop, and switching providers is a DNS change and a `docker compose up`, not a rewrite. A managed PaaS sits in the middle: most of what runs there is still a container or a standard buildpack, but the platform's own config format, environment variable handling, and deploy hooks are specific enough that moving off isn't free, even if it isn't a rewrite either. Serverless carries the most lock-in of the three, and it's not really about the code — a Next.js app runs anywhere — it's about the platform-specific primitives a team ends up depending on once they're actually using the platform well: incremental static regeneration tied to that platform's cache semantics, edge runtime APIs that don't have an identical equivalent elsewhere, image optimization behavior baked into how `next/image` resolves on that specific host. None of that is locked in on day one. It accumulates, one convenience at a time, and the bill for reversing it only shows up the day you actually try to leave — usually as a rewrite of exactly the parts of the app that were the easiest to build in the first place, which is a frustrating kind of debt to discover you're carrying.
A VPS's lock-in is close to zero — the constraint is your own willingness to run infrastructure, not the platform
A managed PaaS's lock-in is mostly in configuration and deploy hooks, not in the application code itself
Serverless's lock-in accumulates through platform-specific features adopted one at a time, not through a single decision
The true cost of lock-in isn't paid while you stay — it's paid entirely on the day you try to leave
Which stage of company actually fits which option?
Pre-product-market-fit, when the constraint is weeks and not dollars and the traffic pattern isn't understood yet because it doesn't really exist, serverless is defensible — the specific conditions where that's true are worth reading before assuming it applies by default. Once traffic starts to look predictable — a SaaS with a stable base of paying customers, a content site with a traffic pattern that repeats week over week — a flat VPS cost usually beats a metered one, because a curve that doesn't move is easier to budget against and, at real volume, cheaper per request than any of the metered alternatives. A managed PaaS is the right stage for a team that has outgrown "we'll figure out ops eventually" but genuinely doesn't want to own a server — not because they couldn't learn it, but because the time is better spent elsewhere and the stepped cost curve is an acceptable trade for that. XenGrowth on building one SEO and GEO content system covers the AI search, GEO and discovery side of this.
Do you know your traffic pattern yet, even roughly? If no, don't optimize cost — optimize for shipping fast and revisit once you do.
Is traffic steady or spiky? Steady traffic favors a flat curve; spiky traffic favors per-invocation billing.
Does anyone on the team have, or want, any ops appetite at all? Zero appetite rules out a raw VPS, though not necessarily a self-hosted PaaS layer on top of one.
How much does a cold start actually cost you — is a delayed response invisible, or does it sit on a path a user notices?
How much do you actually care about being able to leave a platform later? Weight vendor lock-in accordingly, not as an abstract principle.
The three options aren't ranked best to worst. They're ranked by which cost curve matches a traffic pattern you either already have or don't have yet — and most of the bad decisions in this space come from picking the curve before anyone checked which shape the traffic actually is.
So what should a startup actually run on?
Default to a self-hosted VPS behind Coolify or Dokploy the moment traffic is predictable enough to size one with any confidence, and there's real willingness on the team to own it — the flat curve is the cheapest one at real volume, and how far a small VPS actually stretches before it needs to step up is further than most people assume going in. Use serverless specifically pre-product-market-fit, or for a workload that's genuinely spiky rather than merely unpredictable-sounding — the difference matters, and the honest cases where that's the right call lays them out without pretending they cover everyone. Reach for a managed PaaS as the deliberate middle option for a team that wants zero server ownership and can tolerate a stepped, usage-based bill in exchange — not as a permanent default, but as a real answer for teams whose actual constraint is people-hours, not money. The mistake isn't picking any one of these; it's picking one out of habit and never checking whether the traffic pattern that justified it originally is still the traffic pattern you actually have now.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.
XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.
Where this work meets go-to-market
If VPS vs PaaS vs serverless is part of a growth programme rather than a standalone build, XenGrowth's growth engineering practice is the companion reading.
Five questions about your traffic and your team's ops appetite, not about what's fashionable this month. It follows the same reasoning as the post — the shape of the cost curve should match the shape of your actual traffic.
