Every other post in this cluster argues for a VPS. This one doesn't, and it isn't a hedge or a disclaimer tacked on to look balanced — Vercel is the right call for a specific, identifiable set of teams, and pretending otherwise just because I run Coolify on my own box would be the same intellectual laziness as pretending self-hosting is always harder than people say. The honest version of this argument has to concede real ground, or it isn't worth reading. So here's where Vercel actually wins, argued the way I'd argue it to a friend asking which one to pick, not the way a comparison post argues it when it's already decided the answer.
When does spiky traffic actually favor serverless billing?
A VPS is a fixed amount of capacity you rent whether you use it or not. Size it for a normal Tuesday and a launch-day spike knocks it over; size it for the spike and you're paying for idle headroom every other day of the month. Vercel's function billing doesn't have that problem by construction — you're charged for active CPU time and invocations that actually happened, not for a box sitting warm in case they happen. For a workload that's genuinely spiky — a newsletter that occasionally goes viral, a tool that sees ferocious usage the week before a tax deadline and near-silence the rest of the year, a marketing site that spikes hard during a launch — that shape of billing is a real advantage, not a marketing claim. The VPS answer to the same problem is over-provisioning or autoscaling infrastructure you now have to build and maintain yourself, and both of those cost real engineering time that a spiky, low-average workload may never justify. The commercial governance around self hosting is covered properly by XenGrowth.
What does 'no ops appetite' actually cost a team?
This is the concession that matters most, and it's the one self-hosting advocates undersell the hardest. A $7-25/month VPS looks like an obvious win against a $20 seat until you count what actually has to happen around it: hardening SSH, configuring a firewall, setting up backups and actually testing that they restore, watching for security patches, and being the person who gets paged when the disk fills up at 2am. None of that is hard exactly — this whole site is built on the argument that it's more approachable than people think — but it isn't free, and for a team with zero existing ops capacity and no interest in building any, the honest comparison isn't $10 against $20. It's $10 plus however many hours of an engineer's time against $20 and zero hours. A team that would rather spend every available hour on the product, and genuinely means it, is making a rational trade by paying Vercel to make the operational side disappear entirely. The mistake is treating that trade as permanent rather than conditional — the moment someone on the team does have the appetite, or the moment the ops burden gets small enough relative to the bill, the calculation is worth redoing rather than left on autopilot.
What does 'compliance-free' speed actually buy you?
Early on, before there's real customer data flowing through a product or a regulator anyone cares about yet, infrastructure-level compliance work is pure overhead — time spent proving a posture nobody's actually asking to see. A self-hosted stack puts all of that on the team from day one: who patches the box, who can SSH into it, what the audit trail for a production change even looks like, questions that matter enormously later and matter close to nothing before a first paying customer exists. A managed platform doesn't make those questions disappear forever, but it does let a team defer nearly all of them, because the platform's own infrastructure posture stands in for the parts a pre-revenue product doesn't need to answer yet. That's a real, honest advantage during the exact window when a team has the least time and the least reason to spend it there — not a permanent exemption, just a deferral that's worth taking while it's available. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
Operational task | On a self-hosted VPS | On Vercel |
|---|---|---|
Initial server hardening (SSH, firewall, fail2ban) | One-time setup, and staying current with it afterward | Not applicable — there's no server to harden |
TLS certificates | Self-managed, or delegated to a reverse proxy or Cloudflare | Issued and renewed automatically per deployment |
Security patching | Ongoing, and it's whoever's on the team's job | Handled by the platform, invisibly |
Backup verification | Has to be built, scheduled, and actually test-restored | Code lives in git; the platform's infrastructure is ephemeral by design |
Incident response when something goes down at 2am | A person on the team is the pager | Vercel's infrastructure, not the team's, is what's paged |
Scaling under a sudden traffic spike | Manual intervention or self-built autoscaling | Automatic, billed per unit of actual use |
Why are preview deploys a workflow, not just a feature?
Every pull request on Vercel gets its own live URL automatically, with zero configuration, the moment it's opened. That sounds like a convenience until a team has actually built a review process around it — a designer clicking through a real, running version of a change before it merges, a product manager testing an edge case on staging without asking an engineer to deploy it somewhere first, a client approving a feature on a URL instead of a screen-share. Reproducing that on a self-hosted VPS is possible — branch-based deploys, subdomain routing, a bit of Coolify or Dokploy configuration — but it's a project you build once and maintain, not something that exists the moment you connect a repo. For a team whose actual review workflow depends on that URL existing without anyone thinking about it, that difference is worth real money, not a rounding error.
How much does global edge latency actually matter?
A single VPS lives in one region. A visitor on the other side of the planet from that region pays for the round trip every time — DNS resolution, TCP handshake, TLS negotiation, then the actual request, each leg adding real milliseconds before a single byte of the response comes back — and there's no config flag that fixes it. The fix is deliberately re-architecting around a CDN, which is exactly what Cloudflare in front of a self-hosted app is for. That gets a self-hosted stack most of the way there for static and cached content, and what Cloudflare's free tier actually does for a self-hosted app covers exactly how far. But dynamic, per-request compute close to the visitor — not just cached assets — is a genuinely different problem, and it's one Vercel's edge network solves by default without anyone having to design for it. For a product whose users are actually spread globally and whose experience depends on low latency for personalized or dynamic content, that default matters, and matching it on a single-region VPS is a real architecture project, not a checkbox. XenGrowth on governed AI marketing workflows covers the AI agents and marketing automation side of this.
When is speed to market worth more than the money saved?
Pre-product-market-fit, the constraint that actually matters is weeks, not dollars. A founder validating an idea, or a team under fundraising pressure to show a working demo, isn't optimizing for the cheapest infrastructure — they're optimizing for the fastest path to a real answer about whether the product should exist at all. Vercel's deploy-in-minutes path, with no server to provision and no firewall to configure first, removes an entire category of decisions a founder doesn't need to be making in month one. The seat fee at that stage is closer to insurance than to a bill: a few months of $20/seat is a trivial cost against the risk of spending that same time building a self-hosted stack for a product that pivots twice before it finds its shape. This is exactly the argument for defaulting to Vercel early and reconsidering once traffic, cost, or a specific pain point makes the trade worth revisiting — not for staying on it forever by default.
Situation | Favors Vercel because | Would favor self-hosting instead if |
|---|---|---|
Spiky, unpredictable traffic | Billed on actual usage, not fixed capacity sized for the peak | Traffic is steady and predictable enough to size a server confidently |
No ops capacity or appetite on the team | The seat fee replaces hours of firewall, patching, and backup work | Someone on the team already enjoys and is competent at this work |
Preview deploys are core to code review | A URL per pull request exists automatically, no configuration | The team's review process doesn't lean on live preview environments |
Users are genuinely global | Multi-region edge compute is the default, not a project | Users are concentrated in one region a single VPS can serve well |
Pre-product-market-fit, validating fast | Time to ship matters more than infrastructure cost this early | The product and its traffic pattern are already well understood |
What would make this argument dishonest?
Claiming any of the above applies to every team, or claiming Vercel is cheap once traffic is real. It isn't, and the anatomy of where that bill actually comes from is the honest accounting of why. It would also be dishonest to pretend self-hosting is uniformly harder than the five conditions above make it sound — Coolify vs Dokploy and the rest of this cluster exist because a lot of that difficulty is smaller than its reputation once someone's actually done it once. The five conditions here aren't a permission slip to stop thinking; they're the specific, checkable reasons the trade genuinely flips, and a team that doesn't match any of them is very likely paying for a convenience it doesn't need. XenGrowth on building one SEO and GEO content system approaches this from the AI search, GEO and discovery side.
Spiky traffic with a low average — not "traffic might grow eventually," which is true of almost everything
An honest, current lack of ops capacity — not a temporary gap that a week of learning would close
A review workflow that already depends on live preview URLs, not a hypothetical future one
A genuinely global user base today, not an aspiration for one someday
A pre-validation stage where weeks matter more than the monthly bill, with a plan to revisit the decision once that stops being true
The question was never whether Vercel is good. It clearly is, for the teams above. The question is whether your team is actually one of them, or whether you're paying the price of one of these conditions out of habit, long after it stopped being true.
So who should actually stay on Vercel?
A team that matches at least two of the five conditions above, honestly, without stretching. One condition alone is sometimes enough — genuinely global users with real latency sensitivity can justify it by itself, and so can a review workflow that's already deeply built around live preview URLs — but most teams reading this will recognize that only one or two apply, and the rest of their reasoning for staying is closer to inertia than to any of the five. That's not a criticism; inertia is a legitimate reason to not spend a weekend migrating a working system, and a working system that isn't costing anyone sleep is worth more than a theoretically cheaper one that might. But it's worth being honest about which reason is actually doing the work, because the decision doesn't stop at Vercel or a VPS — a managed PaaS sits in the middle of that choice too, and for a team that matches none of the five conditions here, deciding what's actually worth self-hosting is the more useful next post to read, not another Vercel-versus-VPS comparison.
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 self hosting is part of a growth programme rather than a standalone build, XenGrowth's marketing operations practice is the companion reading.
Four questions about your situation rather than your instincts. It follows the same reasoning as the post: the honest answer for a lot of teams is stay, and the cases where that's true are specific.
