Render's April 2026 Egress Cut From 100GB to 5GB on Hobby: Recalculating a Bandwidth-Heavy App's Bill Before the August 1 Deadline

On August 1, 2026, every Render workspace still sitting on a legacy plan gets migrated automatically — no confirmation dialog, no opt-out. If that workspace is running a bandwidth-heavy app, the bill on the other side of that migration can look nothing like the bill today. Render cut included egress on its Hobby plan from 100GB to 5GB and on its Pro plan from 1TB to 25GB, then started billing every gigabyte past that at $0.15. A post titled "Tell HN: Render.com cuts included bandwidth on Pro plan, from 1 TB to 25GB" went up within days of the announcement, and the top complaint wasn't the new number — it was customers discovering they'd been defaulted onto the $499/month Scale plan without asking for it.

Three weeks remain before the automatic cutover. Here's what actually happens to a real bill.

What Changed, in One Table​

Render announced the new plans on April 23, 2026, replacing per-seat pricing with flat workspace fees and re-cutting bandwidth allowances to match. The change is real and dated — this isn't a rumor from a pricing aggregator, it's in Render's own docs and changelog.

Two changes are stacked on top of each other, and it's worth separating them. The per-seat-to-flat-fee switch is genuinely good news for larger teams — Render says 75% of paying customers will see costs decrease or stay flat, and a 12-person team paying $19/seat/month on Pro ($228/month) drops to a flat $25. But that same repricing gutted included bandwidth by 97.5% on Hobby and 97.5% on Pro too. For a team whose app barely touches the network, the flat-fee change is a clear win. For a team serving video, images, large API payloads, or file downloads, the bandwidth cut can erase — and reverse — that savings entirely.

Render also trimmed custom domains (15 included on Pro, $0.25/month each beyond that) and build-pipeline minutes, but those are secondary. Bandwidth is the number that turns a webhook indie project into an unpleasant invoice surprise.

The Recompute: A 500GB/Month App, Before and After​

Here's the concrete case the title promises. Take a mid-size bandwidth-heavy app — an API-heavy SaaS product or a service that streams media/large files — doing a genuinely typical 500GB of egress per month. Not a worst case, not cherry-picked: 500GB/month is roughly what a moderately-trafficked image or document API, a small video-adjacent product, or a data-export-heavy B2B tool pushes without doing anything unusual.

On the legacy Pro plan (3-person team, $19/seat): the base fee is $57/month, and 500GB fits comfortably inside the 1TB included allowance. Total: $57/month, no overage.

On the new Pro plan: the flat fee is $25/month, but only 25GB of that 500GB is included. The remaining 475GB bills at $0.15/GB — $71.25 in overage alone. Total: $96.25/month.

That's a 69% increase in monthly hosting cost for a workload that didn't change at all — the app served the exact same 500GB either side of April 23. The flat-fee savings on the base plan ($32/month cheaper) get wiped out more than twice over by the bandwidth line item. A bill can go up substantially even under a repricing Render's own messaging frames as a net win for most customers, because "most customers" is doing a lot of work in that sentence — it's true in aggregate and false for exactly the workload profile that used to lean on the old bandwidth allowance.

It Gets Worse as Usage Grows — the Sensitivity Table​

500GB isn't the only number that matters; what happens as egress scales is the more useful question, since "how much bandwidth does my app actually use" is exactly the figure most teams have never had to compute before now.

The crossover point — where the new plan stops being cheaper and starts being more expensive than the legacy plan — sits at roughly 238GB/month for this 3-seat example (below that, the flat-fee savings still win; above it, the per-GB overage takes over). Below that line, Render's repricing is exactly the good-news story in its own blog post. Above it, and the further above it, the worse the math gets — because there's no cap on the overage line, only a rate.

That crossover point moves with team size (a solo Hobby workspace has no seat-fee cushion to offset against — its bill starts climbing the moment usage passes the new 5GB allowance) and moves with usage pattern (bursty traffic that occasionally spikes to 2TB in a big month pays the overage rate on the whole spike, not an averaged rate). The one thing that doesn't move is the mechanism: egress switched from a bundled, seat-subsidized allowance to a metered line item, and metered line items scale with usage in a way flat fees never did.

What the Same Workload Costs Without a Metered Egress Line​

The reason this specific repricing keeps showing up in cost comparisons is that it's not really a Render-specific story — it's what happens whenever a platform's bandwidth allowance was implicitly cross-subsidized by something else (seat fees, in this case) and that subsidy gets pulled out. The fix, for a bandwidth-heavy workload, isn't finding a different vendor with a temporarily larger allowance. It's not depending on a per-app metered allowance at all.

A Hetzner dedicated server with a 10Gbit uplink ships with roughly 20TB of included monthly traffic, with overage billed at about €1 (~$1.20) per TB — not per GB. That 500GB/month workload from the example above doesn't even register against a 20TB allowance; the 2TB scenario still uses just 10% of it. The pricing model is structurally different: bandwidth comes bundled in bulk with the box you're already paying for, rather than metered per gigabyte against an allowance sized to protect a vendor's margin on a specific tier.

This is the gap a self-hosted platform running on owned hardware is built to close. bex.co runs a git-push, Render-API-compatible deploy experience on top of a real Cluster API fleet on Hetzner capacity — the same declarative node lifecycle a managed PaaS gives you, minus the layer where bandwidth becomes a re-priced line item every time a vendor needs to protect margin on a tier. It's not a claim that self-hosting is free — a Hetzner dedicated box has its own flat monthly cost, and running it well is real work bex is built to absorb. It's a claim about which knob moves when your traffic grows: on Render, the egress line item; on owned hardware, nothing, until you're well past 20TB.

Before August 1: A Short Checklist​

Three things worth doing this week, in order:

1. Pull actual egress numbers from the Render dashboard — not an estimate, the real trailing-30-day bandwidth figure for each service. This is the single input the entire recompute above depends on, and most teams have never had to look at it because it never showed up as its own line item before.
2. Run that number through the delta above. If it's comfortably under the crossover point for your seat count, the migration is a savings — opt in early rather than waiting for the automatic August 1 move, since Render lets you pick the plan rather than being auto-assigned one (the HN complaint about landing on the $499 Scale plan by default is avoidable if you opt in deliberately).
3. If the number is well above the crossover point, price out the alternative before the deadline forces the decision, not after the first overage invoice arrives. A bandwidth-heavy workload that's outgrowing a metered egress allowance is exactly the workload where the math for owning the machines starts to pencil out.

The repricing itself isn't the story — platforms adjust pricing constantly. The story is that egress went from a number nobody tracked to the line item that decides whether this migration saves money or costs it, and the only way to know which side of that line an app lands on is to actually run the numbers before August 1 does it automatically.

bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with bandwidth that comes bundled with the hardware instead of metered against a tier. Star the repo on GitHub or deploy your first app today.