Self-hosting vs Vercel and Netlify: what you actually take on

The question underneath the question

“Should we self-host or use Vercel or Netlify?” is almost never a technical question. All three run modern web frameworks perfectly well, and any of them will serve your site fast enough that visitors won’t notice which you chose.

The real question is which costs you’d rather own. A platform converts hosting into a predictable monthly invoice and someone else’s on-call rota. Self-hosting converts it into cheaper infrastructure and a standing claim on your engineers’ time. Both are legitimate. The mistake is choosing between them on the sticker price, because the sticker price is the one line where the two are closest.

This page is the buy-side evaluation. If you’ve already concluded that the workloads belong in your own tenancy, bring your own cloud covers what that setup actually involves.

What you’re actually buying from Vercel and Netlify

Four things, and only one of them is servers:

• A review workflow. Every branch and pull request gets a real URL that a marketer, a lawyer, or a brand owner can open and approve. On a large marketing organisation this is the feature that changes how fast anything ships. It is also, quietly, the hardest thing to replicate yourself.
• Framework behaviour that works on release day. Vercel builds Next.js, so incremental regeneration, image optimisation, and middleware are first-party rather than adapted. Netlify is deliberately even-handed across Astro, Nuxt, SvelteKit and Next.js, which suits estates that arrived on several frameworks over ten years.
• Compliance paperwork you didn’t have to produce. SOC 2, SSO and SCIM, audit logs, regional deployment options, contractual SLAs. On the paid tiers these clear most security reviews without your team writing anything.
• Nobody on your side carrying a pager. Patching, capacity, certificates, DDoS mitigation, and the 2am incident belong to the vendor.

Strip those out and the remainder — “it serves files from a CDN” — is a commodity you can buy anywhere for very little. That’s why the comparison is never really about performance.

What self-hosting actually means now

It means less bespoke work than it did a few years ago, which is the fact that has genuinely changed this decision.

Astro, Nuxt and SvelteKit ship Node adapters that run in any container. Next.js self-hosts through its standalone output as a plain Node process or Docker image with no adapter at all, and the OpenNext project maps a Next.js build onto cloud primitives — serverless functions for rendering and image optimisation, object storage for assets, a CDN in front — for teams who prefer that shape. In front of either sits your CDN: CloudFront, Azure Front Door, Google Cloud CDN, or an existing Akamai, Fastly or Cloudflare contract.

What you build around it is the part that isn’t free: a pipeline that rebuilds on merge and on a CMS webhook, cache invalidation that fires on publish, an atomic promotion and rollback path, and — if you want the review workflow back — ephemeral environments per pull request. All solved problems. All now yours.

The cost lines that actually differ

Three lines move; the rest is noise.

Delivery. This is where self-hosting genuinely wins, and it’s the only line where the win is large. Platform bandwidth is metered — Vercel meters data transfer per gigabyte past the included allowance, and Netlify charges bandwidth against its credit allowance — while a committed CDN contract or a network that doesn’t meter egress does not scale that way. On a high-traffic, media-heavy estate this line alone can outweigh everything else.

Compute. Roughly a wash. Rendering costs what rendering costs, and the platform margin you stop paying is offset by the headroom you now provision. What moves this number is your rendering strategy, not your host: a site that renders statically and revalidates costs a fraction of the same site rendering every request, on any of the three.

People. The line that decides it, and the line nobody puts in the spreadsheet. Pipeline maintenance, CDN configuration, runtime and base-image patching, framework upgrades that now need deliberate testing, and incident response are a recurring commitment measured in engineer-days per month. Price them at your loaded rate. For most organisations that number is larger than the platform invoice it was meant to replace — and it doesn’t go down after launch.

The ops you inherit

Written plainly, because this list is what the decision actually turns on:

• Build and deploy pipeline, including atomic releases and a rollback that works under pressure.
• Cache strategy: keys, TTLs, stale-while-revalidate policy, and invalidation on publish. Campaign pages launching behind a stale cache is the most common self-hosting incident we’re called about.
• Certificates, DNS, WAF rules, and bot and DDoS mitigation.
• Runtime versions, dependency and image patching, and a security response process.
• Preview environments, if stakeholder review matters — which on a marketing estate it does.
• Someone who answers when it breaks, including when that person is on holiday.

None of this is difficult. All of it is continuous, and it needs a named owner rather than a willing volunteer.

Where compliance settles it

Data residency is the one requirement that ends the debate rather than informing it. If a policy or regulator requires that content, logs, and processing stay inside a specific jurisdiction or inside your own tenancy, self-hosting gives you control that a platform’s regional options approximate but don’t replicate.

It’s worth being precise here rather than treating “compliance” as an automatic argument for self-hosting. Both platforms offer regional deployment and the certification set on their upper tiers, and for a great many organisations that is genuinely sufficient — the security review passes and the project moves on. The cases where it isn’t are specific: sovereignty rules that name the tenancy, sector regulation that requires infrastructure under your own control, or a procurement function for which adding a processor is a longer project than building a pipeline.

And control cuts both ways. Self-hosting gives you the ability to satisfy a residency requirement; it also makes satisfying it your job, permanently, including the evidence you’ll produce at the next audit.

Side by side

How teams with cloud contracts split the difference

The most common real-world answer isn’t at either pole.

Plenty of organisations keep the estate on a platform for the workflow and move only the expensive part — delivery — onto a CDN contract they already hold, fronting a platform-hosted origin with their own Akamai, Fastly or Cloudflare. Others self-host the public marketing estate inside an approved cloud account because procurement required it, and keep a platform for the smaller sites where velocity matters more than tenancy. Others again start on a platform deliberately, ship the replatform, and revisit the hosting decision a year later with real traffic data instead of forecasts.

That last pattern is worth naming, because it’s usually the right sequence. Hosting is the most reversible decision in the stack — framework code moves between hosts in an afternoon. The CMS choice, the content model, and the component library are the decisions that are expensive to unwind. Don’t let the hosting debate hold up the ones that matter.

Choosing

Self-host when residency or procurement requires it, when you hold cloud or CDN commitments the estate can be absorbed into, when traffic is high and steady enough that metered delivery dominates the bill — and, in every case, when a named team already operates production infrastructure and wants to keep doing it.

Choose Vercel when the estate is Next.js and you want each framework release working as designed without adapter lag, and when preview-driven review is what the marketing organisation is actually buying. It’s our default for Next.js, and when the costs stop making sense is a question of scale rather than principle.

Choose Netlify when the estate spans several frameworks, when many people review and few people commit, or when you’re already on it and the rebuild budget would do more good on the CMS layer. If you’re weighing the two platforms directly rather than against self-hosting, Vercel vs Netlify is the narrower comparison.

The Bejamas take

We build on all three and we don’t have a house answer. What we do have is a consistent finding: the organisations that regret self-hosting almost never regret the infrastructure — they regret assuming the ownership would arrive with the project. And the organisations that regret a platform are usually the ones that never priced the meter against their real traffic before signing.

Both are avoidable with arithmetic. In an audit we model your actual traffic, contributor count, framework mix, and compliance constraints across all three paths, and hand you the recommendation with the numbers and the assumptions written down — including the engineer-days, which is the number that decides it.