Dora NodaMove a SaaS doing 2 TB of monthly egress from Render to a single Hetzner Cloud server and the bandwidth line on the invoice falls from about $296 to zero. Not 20% less. Not half. Zero — with 18 TB of headroom left. That is not a sale or a credits program. It is what happens when bandwidth stops being a metered product and goes back to being a bundled property of the box.
Here is the punchline in one table — what one terabyte of egress overage costs once you are past the included allowance:
| Platform | Overage rate | Included allowance |
|---|---|---|
| Hetzner Cloud (EU/US) | €1.00/TB (~$1.20) | 20 TB/server/month (EU), pooled per project |
| Hetzner Cloud (Singapore) | €7.40/TB (~$8.49) | 1 TB/server/month |
| Fly.io (NA/EU) | Metered from the first byte on current PAYG pricing | |
| Railway | $0.05/GB ($50/TB) | $5 usage credit on Hobby; ingress and private-network traffic free |
| Render (post-Aug-2026 plans) | $0.15/GB ($150/TB) | 5 GB (Hobby), 25 GB (Pro), 1 TB (Scale) |
Render's per-terabyte overage rate is roughly 125 times Hetzner's EU rate. Railway's is about 40 times. Fly.io's — the cheapest of the metered three — is still 17 times. Hetzner bills in euros, so the dollar figures move with FX; the order-of-magnitude gap does not.
If you operate a self-hosted PaaS on owned hardware, this inversion rewrites how you should think about tenant bandwidth pricing: the fleet's bandwidth bill stays near-flat until aggregate tenant egress crosses the pooled allowance, which means per-tenant metering is showback, not cost recovery. And if you price tenant bytes the way the metered PaaS vendors do, the difference is pure margin — until one egress-heavy tenant eats the whole pool's headroom and teaches you the noisy-neighbor lesson flat pricing hides.
How Hetzner's allowance actually works
Every Hetzner Cloud server in an EU location ships with 20 TB of included outbound traffic per month, and allowances pool across all servers in the same project: a quiet server's unused terabytes cover a loud server's overage before a cent is charged. (Hetzner's Cloud page quotes the allowance and the €1.00/$1.20 per-TB overage directly.) Past the pool, overage is a flat €1.00 per terabyte in the EU and US (Hetzner quotes $1.20), and €7.40 per terabyte in Singapore. Traffic between servers on a Hetzner private network does not count at all.
Three qualifiers matter before you do any math:
- Cloud servers, not dedicated. These are Cloud-server numbers; Hetzner's dedicated lines have their own traffic terms, so check the product you actually run.
- The 20 TB pool is an EU story. Servers in US and Singapore locations include only 1 TB each — a Singapore fleet crosses into overage far sooner, at a 7x rate.
- Compute got pricier; bandwidth did not. Hetzner raised compute prices twice in 2026 — the AMD shared plans more than doubled and dedicated-vCPU lines roughly tripled in June — while the traffic allowance and the €1/TB overage did not move.
Compare that shape with the metered PaaS model. Render's new workspace plans, force-migrated on August 1, 2026, include just 5 GB on Hobby and 25 GB on Pro, with Scale at 1 TB — and every gigabyte past that is $0.15. Render did cut the rate from $30 to $15 per 100 GB in the same motion, but the included allowances shrank so far that almost any production workload lives in overage. Railway charges $0.05/GB against usage-based plans (Hobby's $5 buys $5 of credit), and Fly.io bills roughly $0.02/GB in North America and Europe from the first byte. On all three, bandwidth is the line item that surprises teams, because it scales with success while compute stays flat.
One SaaS at four egress levels: the worked comparison
Allowances subtracted, overage applied — here is the monthly bandwidth-only bill for a single app at four traffic levels. Render column assumes a Pro workspace (25 GB included); Railway is gross before the $5 Hobby credit; Hetzner is one EU Cloud server inside its 20 TB pool share.
| Egress/month | Hetzner (1 EU server) | Fly.io | Railway | Render Pro |
|---|---|---|---|---|
| 500 GB | $0 | $10 | $25 | $71.25 |
| 2 TB | $0 | $40 | $100 | $296.25 |
| 10 TB | $0 | $200 | $500 | $1,496.25 |
| 30 TB | ~$12 (10 TB over × €1) | $600 | $1,500 | $4,496.25 |
Read the Hetzner column top to bottom: zero, zero, zero, twelve dollars. The first three rows never leave the included pool, which is the normal case — most SaaS apps, APIs, and dashboards live under a few terabytes a month. The 30 TB row is there to exercise the overage math on both sides: even 50% past a single server's allowance, Hetzner's marginal cost is a rounding error next to the metered columns, where the bill scales linearly from byte one (Fly.io, Railway) or gigabyte 26 (Render).
Now zoom out from one server to a fleet, because that is where a PaaS operator actually lives. Five EU Cloud servers pool 100 TB of monthly headroom. A fleet serving thirty tenants at a combined 30 TB of egress pays nothing for bandwidth — the per-tenant average is irrelevant; only the aggregate against the pool matters.
On Render Pro pricing, that same 30 TB split across workspaces would cost on the order of $4,500 a month in overage alone, before a dollar of compute. The fleet framing is the whole argument: pooled allowances turn bandwidth from a per-tenant meter into a shared buffer that is almost never full.
What the inversion means for tenant pricing
When your bandwidth bill is flat at zero until the fleet crosses a 100 TB pool, passing through per-gigabyte egress charges stops being cost recovery and becomes a pricing choice. Consider what each model implies for a self-hosted PaaS:
- Charge tenants per GB at metered-PaaS rates, and the spread is margin. Billing egress at anything like $0.05–$0.15/GB against a €1/TB underlying cost is a 40–125x markup. Some operators do this deliberately — bandwidth as a profit center subsidizes cheap compute — but call it what it is: a business-model decision, not cost passthrough.
- Bundle bandwidth into the plan, and pricing gets simpler. A flat per-seat or per-service price with a generous fair-use egress cap matches the actual cost shape: the platform pays nothing extra for the next gigabyte until the pool is crossed. This is how Hetzner itself prices — the allowance is bundled, the overage exists but rarely binds.
- Meter anyway, but as showback. Per-tenant byte counts still belong on the invoice or dashboard, labeled as informational. The day the fleet approaches the pool ceiling, showback data is what lets you have the "your video thumbnails are 60% of fleet egress" conversation with evidence instead of vibes.
The honest version of tenant bandwidth pricing on owned hardware is therefore: price the compute, meter the bytes, and keep the overage clause in the contract for the tenant you have not met yet.
Where flat bandwidth pricing breaks
Everything above holds until one tenant stops looking like the average. The failure modes are specific enough to name:
The egress-heavy tenant eats the pool. A single customer serving large downloads, video, software updates, or an image-heavy storefront can push 30–50 TB a month alone — half the headroom of a five-server fleet. Under flat pricing, every other tenant's margin subsidizes that one workload, and nobody notices until the pool crosses and the overage line appears.
This is the exact noisy-neighbor problem flat pricing hides: the cost is socialized, so the signal arrives late. The fix is a fair-use cap with a contractual heavy-egress tier — not to recover €1/TB, but to force the outlier onto dedicated capacity before it consumes shared headroom.
Regional headroom is not uniform. The 20 TB pool is an EU story. A fleet (or a tenant pinned) to Singapore gets 1 TB per server at a €7.40/TB overage — still an order of magnitude cheaper than Render's $150, but a pool that a single busy tenant crosses in days, not months. If your PaaS offers region choice, the fair-use cap has to be regional, or Singapore tenants get a free ride on EU-priced assumptions.
Overage is cheap, not free, at real scale. Past the pool, every terabyte is €1 — which means a 500 TB month (a fleet that became someone's CDN) is €500. Trivial next to the $75,000 Render would charge for the same bytes, but no longer zero. The guardrail that matters is alerting on pool utilization, not on spend: warn at 70% of pooled headroom, page the outlier tenant's account at 90%, and never let the first overage invoice be the discovery mechanism.
None of this requires per-byte billing to solve. It requires per-tenant metering, a published fair-use policy with teeth, and pool-level alerting — the boring operational surface that makes flat pricing safe to offer.
Price compute, meter bytes
Bandwidth on owned Hetzner hardware is close to a solved cost: a 20 TB-per-server pooled allowance covers nearly every realistic tenant mix, and the €1/TB overage behind it means even the overflow month costs less than a team lunch. The metered PaaS vendors, meanwhile, have spent 2026 shrinking included bandwidth — Render's Pro tier went from a 100 GB legacy allowance to 25 GB — while holding overage at $50–$150/TB. The gap between those two shapes is where a self-hosted PaaS wins its margins: not by reselling bytes at a markup, but by treating bandwidth as infrastructure that is already paid for and competing on everything above it.
The remaining work is guardrails, not billing code. Meter every tenant, publish the fair-use cap, alert on the pool — and let the flat part of the cost curve stay flat.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, where bandwidth is a bundled property of the box instead of the line item that surprises you. Star the repo on GitHub or deploy your first app today.
