Render's Aug 1, 2026 Repricing Deadline: What Auto-Migrating to Flat Fees and a 25GB Egress Cap Actually Costs You vs a Self-Hosted Fleet

Nineteen days from today, every Render workspace still sitting on a legacy per-seat plan gets moved — automatically, with no confirmation click required — onto Render's new flat-fee pricing. August 1, 2026 is not a soft recommendation; it's a cutover date Render set back on April 23, 2026, and any team that hasn't touched their Billing page by then gets migrated whether they meant to or not.

Whether that migration is good news or a quiet bill increase comes down to two numbers you can compute right now: your team's seat count, and your monthly egress. Do the math and two breakeven points fall out cleanly. Below roughly 1.3 seats, the new flat fee costs more than the old per-seat rate even at trivial traffic. Above 500GB/month of egress, the breakeven shifts to roughly 5 seats — below that, the bandwidth you lose costs more than the seats you save. Here's the worked model, and what it looks like stacked against a bill that has no seat count in it at all.

What Actually Changes on August 1​

Render's repricing swaps per-seat billing for flat workspace fees and re-meters bandwidth. The table below is the full mechanical change, pulled from Render's own migration docs:

Overage on both the legacy and new plans is billed at the same rate, $0.15/GB, so that part of the equation doesn't change — only how much bandwidth you get before it kicks in. That's the part of this migration nobody opts into on purpose: Professional's 500GB monthly cushion becomes Pro's 25GB cushion, a 20x cut, while the flat fee replaces whatever your team was paying per seat. Custom domains get the same treatment — Professional's unlimited domains become 15 free on Pro, then $0.25/month each after that.

Render frames this as "better pricing for fast-growing teams," and for a specific kind of team, it is. The question this piece answers is which kind of team that actually is — and which kind eats a bill increase from a cutover they never opted into.

The Worked Before/After​

Set up the two cost formulas using Render's own published numbers. For a legacy Professional workspace with s seats and e GB of monthly egress:

Legacy cost = $19 × s + $0.15 × max(0, e − 500)
New cost    = $25 + $0.15 × max(0, e − 25)

The seat term drops out of the new formula entirely — Pro's $25/month is flat no matter how many people are on the workspace. That's the whole story at low egress: it's a pure seat-count comparison. Below 25GB/month (neither plan's overage kicks in), the delta is just $25 − $19s, which crosses zero at s = 25/19 ≈ 1.32 seats. A solo developer on Render — one seat, any egress under 500GB — currently pays $19/month and gets moved to a $25/month plan on August 1. That's a $6/month increase for doing nothing, before a single byte of overage is counted.

Two or more seats, and the flat fee wins outright at low egress: a 3-person team goes from $57/month down to $25/month, a straightforward $32/month saving.

The more interesting crossover shows up once a workspace is pushing enough traffic to blow through both plans' included bandwidth. Above 500GB/month, the egress terms in both formulas grow at the identical $0.15/GB rate, so they cancel out of the delta — leaving a constant that depends on seats alone:

New − Legacy = $96.25 − $19 × s     (for e > 500GB)

That crosses zero at s ≈ 5.07 seats. Below roughly 5 seats, a heavy-egress workspace pays a flat $96.25/month more than it used to, permanently, no matter how much traffic climbs past 500GB — because that $96.25 is entirely the price of the 475GB of cushion Professional had that Pro doesn't. Here's the same math laid out across representative team sizes and traffic levels, holding the plan (Professional → Pro) fixed and varying only seats and egress — no cherry-picked scenario, the same $19/$25/$0.15 rates apply at every cell:

(Positive = new plan costs more per month; negative = new plan saves money. Egress figures beyond 500GB stop changing the delta, which is the flat-$96.25-minus-seats result derived above.)

Who Wins, Who Loses​

Two groups get a real bill increase on August 1 that has nothing to do with anything they did:

• Solo developers and 1-2 person teams, full stop, regardless of traffic — the $25 flat floor is simply higher than what a 1-seat Professional workspace was paying.
• Small teams (under ~5 seats) running egress-heavy workloads — image or video delivery, chatty internal APIs, webhook-heavy integrations, anything that used to comfortably fit inside the old 500GB cushion. That cushion silently becomes 25GB, and the difference shows up as a new, metered line item that wasn't there before.

Everyone else — teams of 6+ with typical web-app traffic — is a genuine winner, sometimes a large one; a 10-seat team saves $165/month at low egress and still saves nearly $94/month even at triple-digit-gigabyte traffic. But "genuine winner" comes with a footnote: that team's bill is now metered on a resource (bandwidth) it never had to think about before, on a cap 20x tighter than what they had. The saving is real this month; the exposure to a future traffic spike is new.

What the Same Traffic Costs Off Render Entirely​

The reason this cap is worth comparing against something other than Render's own legacy tier: 25GB is a genuinely small number against what a single self-hosted box includes by default. A Hetzner CX23 — €5.49/month (~$6 at mid-2026 exchange rates) — ships with 20TB of included outbound traffic, and overage past that runs roughly €1/TB, i.e. about $0.001/GB. That's not a discount tier; it's Hetzner's standard cloud-server allowance.

Put the two caps side by side: Render Pro's 25GB versus a single €5.49 box's 20,000GB is roughly 800x more headroom, for less money than the Pro plan's flat fee by itself. Run the entire 1,000GB/month scenario from the table above against that box, and it doesn't even touch the included allowance — no overage line, no metering decision, nothing to recompute if traffic doubles next quarter. And critically, that number doesn't move with team size. A self-hosted platform's bandwidth bill has no seat term in it at all, because the box doesn't care whether one person or ten people are pushing deploys to it.

This is also why a self-hosted platform never faces an August-1-style deadline in the first place: there's no legacy per-seat tier to be auto-migrated off of, because there was never a seat-metered tier to begin with. Bex is built around that same idea for the deploy workflow itself — push a git repo, get a running HTTPS service on machines you own, using a Render-compatible API, with no per-seat license and no separate bandwidth product bolted onto the compute bill.

Before August 1: Do the Arithmetic on Your Own Workspace​

Three concrete steps, in order:

1. Pull your actual numbers. Render's dashboard Usage tab shows your workspace's egress for the current billing period — that's your e. Count your active seats — that's your s.
2. Run both formulas. If e is under 25GB, you're comparing $25 against $19s. If e is over 500GB, you're comparing a flat $96.25 against $19s. Either way, the breakeven seat counts above (1.3 and ~5.1) tell you which side of the line you're on without waiting for August 1 to find out from an invoice.
3. Act on the answer. If you're a clear winner, opt in from the Billing page now — the migration is available today, and there's no reason to wait three weeks to start collecting the savings. If you land in the losing zone — a small team with real egress — that's the moment to ask whether the workload belongs behind a CDN, on a bigger plan, or off Render's metered egress entirely.

Render's flat-fee pricing is a real improvement for a real slice of its customer base. It's just not the improvement the migration email implies for everyone getting swept into it on August 1st — and for the teams it makes worse off, the honest comparison isn't the plan two tiers up, it's a $6 box that was never metering bandwidth by the gigabyte in the first place.