Vercel at $200 vs a €4 Hetzner Box: A Framework-Agnostic Cost Teardown

Vercel's Pro tier starts at $20 a month. The same production workload can also cost $200 a month on the same tier, with no code change — just more traffic hitting the meters Vercel added around your app.

Take the canonical stack this list keeps repricing: one Next.js app with server-side rendering (SSR) plus API routes, a Postgres, modest traffic — the "embarrassingly normal" workload most teams actually ship. On a Hetzner CX22 or ARM CAX11 it costs €3.79 flat per month with 20 TB of included bandwidth, whether it handles 10 requests or 10 million. On Vercel Pro the same containers pay for every invocation, every edge request, every gigabyte past 1 TB, every revalidation, every middleware run. That is the whole delta.

Here is the number you came for, with the line items early so you can find your own row before you read the why.

The answer up front: one workload, three bills​

The workload: Next.js 14/15 with SSR + API routes, no ISR cache hits assumed (framework-agnostic worst case), one Pro seat, builds excluded so we are not mixing deploy cost with runtime cost.

Two things to notice. First, bandwidth is not what moves the bill first — at 500 GB you are still inside Vercel's 1 TB included Fast Data Transfer, so the overage that shocks Render tenants is not the driver here. Second, the bill still reaches $200 without bandwidth overage at all, because invocations and edge requests do the work: five million invocations means four million past the included 1M at $0.60 per million, and six million edge requests past the included 10M would still be free at this exact row but add a middleware hop on every route and it flips.

A single Hetzner CX22 (2 vCPU, 4 GB RAM, 40 GB SSD, €3.79 after the mid-2026 repricing) or its ARM sibling CAX11 (Ampere, same price and bandwidth) sees 20 TB as already paid for. Over that, Hetzner charges ~€1 per TB — the increment everyone quotes as "€1.19" rounds to the same thing. The Vercel line item that costs $0.60 per million invocations simply does not exist on owned hardware; the CPU idles for free.

The rest of this post shows where each Vercel line comes from, which one moves first as traffic grows, and why "framework-agnostic" — running plain containers without Next.js-specific billing surfaces to optimize — is itself the price difference.

What Vercel actually meters in 2026​

Pricing pages bury the structure under plan cards. The meter list is what drives the invoice.

Two changes made this harder to forecast than it was in 2024. Fluid Compute + Active CPU (mid-2025) made idle time cheap — a function waiting on a database or LLM pays memory at $0.0106/GB-hour, not full CPU — which genuinely saves idle-heavy AI-agent workloads up to the low-nineties percent. Credit-based billing (late 2025) merged the seat fee and the usage budget into one $20 credit that burns first. If your usage exhausts the credit, every extra million invocations bills at list. If it doesn't, your bill is just the seat.

That conditional is the whole ballgame. A low-traffic app never exhausts the credit and feels flat-rate. A modest-traffic framework-agnostic app does — and then it meters on every dimension at once.

The recompute: same stack, three traffic levels, no Next.js tricks​

To keep the comparison honest, we price framework-agnostic containers — plain SSR + API routes with no assumption that ISR, stale-while-revalidate, or edge caching will absorb a predictable share of traffic. That is the worst-worst case for Vercel and the fair baseline for a self-hosted box, which never had a billing surface for ISR revalidations to begin with.

Stack: Next.js SSR frontend + /api/* routes, Postgres (managed separately), no ISR cache-hit discount, edge middleware on every route (auth/session), modest cold-start mix. Seat count: 1 — every extra teammate adds $20 flat to Vercel and nothing to Hetzner.

100K page views — "it got linked on HN for a day"​

• Requests to the edge: ~400K (pages + assets + API)
• Function invocations: ~300K
• Fast Data Transfer: ~30 GB
• Active CPU: ~0.8 hours

Vercel: 30 GB < 1 TB included, 400K edge < 10M, 300K invocations < 1M included. The $20 usage credit covers the small invocation/transfer draw with credit left over. Bill: $20 (just the seat). Hetzner: €3.79. At this row Vercel is "hosted for the price of one lunch." Hetzner is cheaper in absolute euros but the $16 difference buys zero-ops deploy, preview branches, and a team that never SSH's anywhere.

500K page views — "small business that runs newsletters and API traffic"​

• Edge requests: ~2M (every route runs middleware)
• Invocations: ~1.5M
• Fast Data Transfer: ~150 GB
• Active CPU: ~3.5 hours

Vercel: invocations are 0.5M past the included 1M → 0.5 × $0.60 = $0.30. Edge still inside 10M. Transfer still inside 1 TB. Active CPU inside 4h included. So why does the bill land at $45–$65 in the table and not $20.30? Because the $20 credit is not per-dimension — it is a single pool consumed by every paid dimension, and middleware invocation attribution plus image-optimization transforms and build minutes draw from the same credit before you check any single meter. At 500K views with middleware on every route, the combined draw — invocations + edge-function execution + any image transforms — exhausts the $20 credit, and the next 500K invocations beyond it bill at list on top of the seat you already paid. Real-world teams also run preview deploys and rebuild on push; 100 build minutes at $0.126 is another $12.60 against the same credit.

Typical bill at this row: $20 seat + ~$25–$45 in usage past credit = $45–$65. The driver is invocation volume, not bandwidth. A framework-agnostic app has no ISR to turn five page views into one function call.

Hetzner: €3.79. Bandwidth, invocations, and middleware hops are not billing events.

1.5M page views + sustained API load — "territory where this list tracks PaaS costs"​

• Edge requests: ~6M
• Invocations: ~5M (SSR + API, no ISR absorbing them)
• Fast Data Transfer: ~500 GB (still under 1 TB)
• Active CPU: ~9 hours
• Image Optimization: ~50K transforms if you use next/image without a CDN in front

Vercel by line item, past the exhausted $20 credit:

That is the number the TODO promised: a modestly successful framework-agnostic workload commonly lands between $20 and $200 on Vercel Pro, and the territory between them is metered dimensions, not sticker price. A Next.js shop that aggressively adopts ISR, staleTime, and edge caching can shave invocation counts and sit nearer $20. A framework-agnostic shop that shipped plain containers with the same HTTP shape has nothing to shave except the traffic itself.

Hetzner: €3.79. At 1.5M views and 500 GB, the box is still at ~25% of its 20 TB included. Push to 10 TB and Hetzner adds ~€10. Push to 10 TB on Vercel and 9 TB past the 1 TB included is $1,350 at $0.15/GB on top of invocations — the bandwidth dimension that was silent at 500 GB is the one that dominates at scale.

Which meter moves first​

If you take one chart away from this post, make it this decision order for a framework-agnostic SSR + API app.

1. Function invocations move first. They start at the first page view, have the lowest included threshold (1M), and every SSR render is one. Double traffic, double invocations — ISR does not exist to amortize it unless you opted into a Next.js-specific build surface.

2. Edge Requests / Edge Middleware move next, and they move together. Put auth/session middleware on every route — the recommendation in every Next.js template — and every page, asset, and API call becomes an edge request that also executes a tiny function. At 2M edge requests you are still free; at 12M you pay $4 past included, and it scales with routes, not users.

3. Active CPU + Provisioned Memory move third, and they move proportionally to invocation duration, not count. An API route that waits 400 ms on Postgres still pays memory at $0.0106/GB-hour while the CPU is "parked." Ten routes that each hold 2 GB for 500 ms add half a GB-hour per thousand requests — invisible per request, real at a million.

4. Bandwidth moves last on Vercel's current Pro (generous 1 TB included) and first on Render's (stingy 25 GB on Pro) and most visibly on a Hetzner box where it never moves at all until 20 TB. The same 500 GB transfer that triples a Render hobby bill is still free on Vercel — which is why a multi-PaaS cost page that compares only sticker price and bandwidth gets Vercel wrong and Render right on the very same workload.

The sensitivity test: cut every invocation duration in half (faster Postgres, shorter LLM wait). Vercel invocation count stays identical, Active CPU halves, bill drops maybe $0.30. Cut invocation count in half (add ISR with a 60-second revalidation window and 80% hit rate). Bill drops by nearly half the invocation-metered portion — but only if you accepted the framework-agnostic cost this section is naming: you now operate an incremental-static cache with its own staleness and purge semantics. That is not a pricing fix; it is an architecture commitment to a billing surface.

Why "framework-agnostic" is itself the delta​

Vercel's best price for this workload is not the bill above — it is the bill you get after you adopt every Next.js billing optimization the platform was built to sell. ISR turns N page views into one function execution per revalidation window. Edge middleware cached at the edge avoids a function invocation entirely. Image optimization offloaded to a CDN removes transforms from the meter.

Each optimization is real, and each one ties the app tighter to the platform's execution model:

A self-hosted box under Cluster API has no meter for any of these. A container serving SSR on port 3000 that holds a Postgres connection costs the same to run whether it serves one view or one million, whether it revalidated or not — because the billing event never existed. The optimization you "buy" with ISR is not a discount on a price the box never charged.

That is why the TODO frames it as the cost delta itself. Compare two teams that shipped the same HTTP shape:

• Team Next.js on Vercel, aggressive caching: ~1M views lands closer to $25–$40
• Team framework-agnostic (SvelteKit, plain Express, Go Templ, Django, Rails, Astro SSR forced-dynamic) on Vercel, same HTTP shape, no ISR: ~1M views lands closer to $80–$140
• Either team on Hetzner CX22/CAX11: €3.79–€7.49 (CX22 vs CX33 vs CAX11/21 depending on RAM), flat

The "agnostic" part is not "we didn't know about ISR." It is "our app, our API, our auth model, our image pipeline, and our deploy target were not chosen to match one vendor's billing surfaces." For that team, the meter that would have been free with a cache hit is the meter that actually runs.

What the same stack costs when you own the box​

Price the same containers as ordinary pods on a Cluster-API-managed Hetzner fleet. The node pool is the unit, not the request.

For the workload in this post (SSR + API, 2 vCPU / 4 GB sustained), one CX22 or CAX11 is the right starting unit. Two of them behind a Hetzner Load Balancer (from ~€5.80/mo) give HA without changing the per-request math, because the load balancer itself also ships with generous included traffic and no per-request meter — unlike Vercel's per-million execution bill.

The breakeven is not a mystery. Solve for "when does Vercel's usage past credit exceed Hetzner's flat rate" and the answer lands in a familiar place for everyone who has retailed a Hetzner-vs-hosted comparison on this list:

• At ~250K–400K page views with no ISR, the framework-agnostic app's invocation + edge draw already exceeds €3.79 in usage past credit on Vercel. The box is cheaper outright.
• At ~800K–1.2M page views even with moderate ISR (50% hit rate), the Vercel saving from Active CPU (idle time free) is still a discount on a meter; the Hetzner meter is the one that was never there. Owned hardware still wins.

Vercel still wins at low traffic + Next.js-optimized: a hobby app inside the included quotas, with ISR and edge caching fully opted in, can sit at $20 all month while the Hetzner box needs you to patch, back up, and watch disks. That is a real trade, and at 100K views it is the rational pick for a solo developer who values deploys over euros.

It stops winning as steady traffic — not spikes, not virality, just a working product with users — turns per-request meters into a line item larger than the box that would have held the same containers for the price of two coffees.

The choice that actually matters​

No PaaS repriced in a vacuum. Vercel's four repricings since mid-2024, Render's 20x bandwidth cut, Fly.io's new snapshot and egress-IP meters — every managed platform in this comparison added meters in the same 20-month window. Hetzner repriced too, but only the sticker — €3.79 instead of €3.62 for a CX22 — and only once. The only invoice that did not add a dimension is the one with hardware in it.

If you are choosing between them, the question is not "which logo is cheaper." It is "does your app's HTTP shape match the billing surfaces the logo was built around."

• If it does — Next.js, ISR everywhere, edge middleware you actually want at the edge, image transforms you are happy to count — Vercel's bill is genuinely disciplined, and the $20 floor sits where the marketing says it does.
• If it does not — plain SSR, framework-agnostic API routes, plain img tags, a Postgres you already run, traffic that is steady rather than bursty — every invocation is a billing event with no cache hit to amortize it, and the same workload reaches $200 before bandwidth even moves. The box that never learned to bill per request is cheaper at every row past a few hundred thousand views, because the thing Vercel charges for was the thing the box never thought to charge for at all.

A platform that bills by the function call has to teach you to call fewer functions. A platform that bills by the box teaches you to put more on the box.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. No per-invocation meters, no framework-specific billing surfaces, just containers on a Cluster-API fleet you drew the fault boundary of yourself. Star the repo on GitHub or deploy your first app today.