Fly.io's 'Global Edge' Has a 6x Egress Cliff — and Flat Hetzner Pricing Wins the Workload It's Marketed For

Fly.io's pricing page lists exactly three numbers for outbound data transfer: $0.02 per GB to North America and Europe, $0.04 per GB to Asia-Pacific, Oceania, and South America, and $0.12 per GB to Africa and India. That's not a rounding difference between regions — it's a 6x spread between the cheapest tier and the most expensive one, and it lands precisely on the traffic pattern Fly's own pitch says it's built for: an app deployed close to users wherever they are, not just in the US and EU.

Run a global user base through that rate card and the bill stops looking like a footnote. A startup serving 10TB of monthly egress across a realistic worldwide audience — say 45% North America/Europe, 45% Asia-Pacific/Oceania/South America, 10% Africa/India — pays a blended $390/month on Fly.io. Skew the audience toward the regions Fly's edge pitch is supposed to serve better — 30% Africa/India — and the same 10TB costs $570/month. A single Hetzner box with 20TB of included, destination-blind bandwidth costs about $6.26/month and would swallow either number without a single overage charge. That gap is the whole story here: it's not that Fly is expensive everywhere, it's that "deploy close to your users everywhere" and "pay 6x more for exactly the users furthest from North America and Europe" are the same feature.

The Three Numbers, and Who They're Actually Grouping​

Fly.io's pricing documentation splits public-internet egress into three region groups:

Inbound traffic is free everywhere, and traffic between apps or Machines in the same region is free. But the moment a response actually leaves the edge and reaches a paying user in Lagos, Mumbai, or Nairobi, it costs six times what the identical response costs reaching a user in Chicago or Frankfurt — and twice as much as delivering it to Singapore or São Paulo. Africa and India aren't an edge case buried in a long region list; they're one of Fly's three billing tiers, named explicitly, at the top of the price sheet.

That grouping matters because those are exactly the markets a platform advertising "35+ global edge regions" and low-latency delivery "wherever your users are" would need to serve well to make the pitch true. India alone has well over 800 million internet users; Africa has north of 570 million. A platform that pools those two billing regions together at 6x its cheapest rate isn't an edge case in its own marketing — it's pricing the growth markets its edge story is aimed at as the most expensive traffic on the network.

The tiers aren't arbitrary — they track real differences in what it costs to move a byte in each region. Markets without a mature local peering ecosystem route even nearby traffic over long-haul international transit, and much of Africa's international connectivity still depends on a handful of undersea cables rather than the dense, competitive peering fabric that makes North American and European transit cheap, a pattern Cloudflare's own bandwidth-cost breakdown documents across providers, not just Fly. So the 6x spread isn't Fly padding a margin on users in Lagos or Mumbai — it's a real, unequally distributed cost being passed straight through, with no averaging across the network to soften it. That's the part worth naming plainly: a platform could choose to blend that cost into a single global rate the way a flat-bandwidth provider does; Fly's pricing model chooses instead to itemize it region by region, and the region that ends up itemized highest is also the one with the least infrastructure spend already in it.

What Serving an Actually-Global Audience Costs​

Here's the worked number, shown across a range of audience mixes rather than one convenient split, because the honest question isn't "what does a US-only app pay" — it's "what does a global app pay, and how much does that change as the audience gets less US/EU-centric."

Hold North America/Europe and Asia-Pacific/Oceania/South America split evenly, and vary the Africa/India share:

Even the mildest global mix in that table — just 10% of traffic reaching Africa and India — nearly doubles the bill against the US/EU-only baseline, because that 10% alone costs as much as the other 90% combined at the low tier. At 30%, the blended rate is 2.85x Fly's advertised $0.02/GB headline; a team that priced its infrastructure budget off the number on the pricing page's first line is paying nearly three times what that number implied, and only because it actually reached the users the edge network was built to reach.

Scale the same 30% mix up to a bandwidth-heavier 50TB/month — a media-serving or data-sync workload, not just API responses — and the bill becomes $2,850/month. None of these numbers require an adversarial or unusual traffic pattern. They're what "global" costs once "global" stops meaning "US and EU with a few extra pins on the map."

Picture the kind of team this actually happens to: an API startup that launched serving mostly US and European customers, then landed real growth in Nigeria and Indonesia — exactly the outcome a founder pitches as a success story. On Fly, that growth doesn't just add revenue-generating traffic; it silently drags the blended egress rate up the table above, because every new user in Lagos costs 6x what the last user in Chicago cost to serve the same response to. Nothing about the app changed. The infrastructure bill got worse specifically because the product started working in the markets it was ostensibly built to reach.

Hetzner's Bandwidth Doesn't Know or Care Where the Request Came From​

Hetzner's cloud pricing has no destination tier at all. A CX23 box — 2 shared vCPUs, 4GB RAM, €5.49/month after 2026's price adjustments (about $6.26 at 1.14 USD/EUR) — ships with 20TB of included outbound traffic, and every gigabyte of it costs the same whether the request came from Chicago or Lagos. There's no billing distinction to make, because Hetzner doesn't track where a response ends up — only how much left the box. Traffic beyond the included 20TB is billed flat, at €1.00/TB ($1.14/TB), the same rate no matter the destination.

Put that against the table above: the 10TB/30%-Africa/India scenario that costs $570/month on Fly.io fits inside a single Hetzner box's included allowance with 10TB of headroom to spare, for a base cost of $6.26. Even the 50TB media-workload scenario — $2,850/month on Fly.io — needs only 30TB of Hetzner overage on top of the base allowance: 30 × €1.00 = €30 (~$34), for a total of about $40/month. That's not a cheaper alternative; it's a different pricing model entirely, one where "where did this byte go" was never a variable in the first place.

The one honest wrinkle: Hetzner's included allowance does vary by where the server itself lives, even though the rate doesn't vary by where the traffic goes. The cost-optimized CX line above is EU-only. The broader CPX line, available in the EU, US, and Singapore, includes 20TB in EU regions but only 1TB in the US and 0.5TB in Singapore — and Singapore's overage rate jumps to €7.40/TB, seven times the EU/US rate.

A team building a genuinely self-managed multi-region footprint — one Hetzner box each in Nuremberg, Ashburn, and Singapore, to approximate the latency benefit Fly gets automatically — needs to size each box's allowance to its own regional traffic, not assume 20TB everywhere. That's a real planning cost Fly's single global account doesn't impose. But it's a capacity-planning problem, not a pricing cliff: nothing about a request's destination changes what any of those three boxes charges per gigabyte once provisioned.

Put a real number on that three-box fleet. A CPX22 in Nuremberg, one in Ashburn, and one in Singapore — 2 vCPUs, 4GB RAM each, €7.99/month post-hike per box — costs about €23.97/month total (roughly $27.30), with 20TB + 1TB + 0.5TB of combined regional headroom before any overage applies anywhere. Route each user to whichever of the three boxes is geographically nearest — the same job Fly's scheduler does automatically — and the bill is still under $30/month regardless of whether that routing sends 10% or 50% of total traffic to the Singapore box serving South and Southeast Asia. Fly's pricing has to answer "where did this byte go" for every gigabyte; this fleet only ever has to answer "which of my three boxes sent it," and the second question doesn't get more expensive as the user base globalizes.

The Tradeoff That's Still Real​

None of this makes Hetzner a drop-in replacement for what Fly.io actually does well. Fly's Machines get placed automatically near where traffic originates, spread across regions with no manual provisioning; a self-managed Hetzner fleet needs a human (or a Cluster API-driven controller) to decide where boxes live and to route traffic to the nearest one. For an app where round-trip latency to a user in Mumbai or Lagos is a genuine product requirement — real-time collaboration, gaming, anything sub-100ms-sensitive — that automatic edge placement is worth paying for, and no flat-rate bandwidth pitch changes that calculus.

The cliff in Fly's pricing only bites hard when the workload is bandwidth-heavy but not latency-critical: API responses, file downloads, static assets, webhook payloads, batch data sync — traffic where an extra 100-200ms doesn't matter but every gigabyte does. For that shape of workload, the honest move is to stop paying a per-destination premium for placement the app doesn't actually need, and either put a CDN in front of a single-region deployment (moving the "close to the user" job to a layer that's built to do it cheaply, since most CDNs price bandwidth flat or bundle it into a fixed plan rather than tiering by visitor region) or run a small self-managed multi-region fleet where the per-GB rate is the same no matter which region answered the request.

The two approaches aren't mutually exclusive, and combining them is usually the actual answer rather than a clean either/or. Static assets, images, and anything cacheable belong behind a CDN regardless of where the origin lives, because that traffic never needs to touch origin bandwidth pricing — Fly's or Hetzner's — a second time after the first cache fill. What's left after that split is the genuinely dynamic, per-request traffic a CDN can't cache: exactly the slice where an origin's per-GB rate structure matters most, because it's the slice that scales with every user interaction rather than flattening out after the first hit. That's the traffic this post's numbers are actually about, and it's also the traffic where a flat-rate origin keeps its advantage even after a CDN absorbs everything else.

That's the workload a self-hosted PaaS built on owned infrastructure is actually suited for. Bex.co provisions node pools onto Hetzner capacity through Cluster API — the same flat, destination-blind bandwidth model priced above, not a per-region rate card that gets more expensive exactly when an app succeeds at reaching the users furthest from North America and Europe.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with no per-destination bandwidth surcharge hiding in the invoice. Star the repo on GitHub or deploy your first app today.

Sources​

• Fly.io: Resource Pricing (official docs)
• Fly.io: Regions reference
• Fly.io Blog: We cut bandwidth prices. Go nuts.
• Hetzner: Price Adjustment 15 June 2026 (official docs)
• Better Stack: Hetzner Cloud Review 2026 — Benchmarks, Pricing, and the Real Trade-offs
• Northflank: Railway vs Fly.io in 2026 — pricing, infrastructure, and platform comparison