Render's Bandwidth Shock Meets Fly.io's GPU Cutoff: What August 1, 2026 Means for EU Developers Choosing a PaaS

Two unrelated US platform-as-a-service providers are changing what you get for your money on the exact same day. On August 1, 2026, any Render workspace still sitting on a legacy plan auto-migrates to a new plan with dramatically less included bandwidth and a new per-gigabyte overage charge. On the same date, Fly.io's GPU Machines become permanently unavailable, with no in-platform replacement. Neither company coordinated with the other — this is coincidence, not conspiracy — but if you're running production traffic on either platform, the coincidence doesn't make the deadline less real. Here's exactly what changes, verified against both companies' own documentation, and what to do before the weekend.

Render: the auto-migration is real and it's dated

Render's own docs are unambiguous about the mechanism: "Workspaces on a legacy plan will automatically move to the corresponding new plan on August 1, 2026" (render.com/docs/new-workspace-plans). Render opened a voluntary opt-in window back in April 2026, so any workspace that hasn't already switched has effectively been given until August 1 to do nothing and get moved automatically.

The part that matters for your bill is bandwidth. Render's own changelog entry explains the logic plainly: "The new Hobby and Pro plans include less bandwidth than their legacy counterparts, because legacy plans subsidized bandwidth usage with seat fees." In other words, the old per-seat pricing was quietly paying for your bandwidth; the new flat pricing doesn't, so the included bandwidth allowance had to shrink to make the flat price work.

Here's the actual before/after, confirmed directly from Render's docs:

That's a 95% cut in included bandwidth on both the free Hobby tier and the paid Pro tier — Scale is the only workspace plan left untouched. Billing also changed shape, not just size: the changelog confirms the old system billed overages "in 100 GB increments," while the new system bills per individual gigabyte at $0.15. That's more precise, but it also removes the rounding buffer that a block-based system gave you — every extra GB now shows up on the invoice, not just every extra 100.

The pricing side of the story is more mixed than the bandwidth cut suggests, and Render is upfront about it. Its own pricing announcement states "75% of paying Render customers will see their Render costs decrease or remain the same," because the new plans drop per-seat billing entirely:

For a team of four or five on the old Professional plan, dropping to a flat $25/month is a real win even before bandwidth is considered. The 25% who don't see costs drop are, unsurprisingly, the workloads doing the thing bandwidth measures directly: serving images, video, file downloads, or any API returning large payloads to a lot of users. That's a common shape for exactly the kind of SaaS product Render has historically attracted.

A concrete number for a bandwidth-heavy case. A two-person team on the new Pro plan ($25/month flat) serving 700 GB/month of outbound traffic — a realistic figure for a product that streams reports, exports, or media — gets 25 GB included and pays overage on the remaining 675 GB: 675 × $0.15 = $101.25, for a total of $126.25/month. Compare that to a low-traffic solo project on the free Hobby plan using 40 GB/month: 35 GB over the new 5 GB allowance costs 35 × $0.15 = $5.25/month — a small number, but notable because it's the first bandwidth bill that project has ever had. "Free tier" on Render no longer means "no bill is possible."

Fly.io: GPUs are not being downgraded, they're being switched off

Fly.io's change is smaller in scope but has zero middle ground. Its own pricing documentation states it flatly: "GPUs are deprecated and will be unavailable after August 1." No downgrade tier, no reduced-capacity fallback — GPU Machines stop existing on the platform.

This is a real reversal, not a quiet feature sunset. In a February 2025 blog post, Fly.io had explicitly reassured GPU users it wasn't abandoning the offering, while conceding the business case was hard: "developers don't want GPUs. They don't even want AI/ML models. They want LLMs" — most developers call an API rather than run their own inference, which made Fly's GPU Machines a niche product relative to the engineering investment (the post describes wrestling with Nvidia driver compatibility inside Fly's container-based virtualization stack). Eighteen months later, that niche-market problem apparently won: GPUs are gone entirely.

While they're still live, current GPU pricing on Fly.io is:

Worth flagging: Fly.io's own community forum has a thread (started February 2026, unresolved as of this writing) from a developer who says the deprecation email they received from Fly.io cited July 31, 2026 — one day earlier than the "after August 1" language in the official docs. Treat July 31 as the operative deadline if you're running anything GPU-dependent on Fly.io; a day of slack you didn't plan for is better than a day of downtime you didn't expect. More importantly, that same thread has no official Fly.io reply with a migration path — the only suggestions come from other community members pointing at RunPod, Modal, and Google Cloud Run. If you're running fine-tuning jobs, local inference, Whisper transcription, or image-generation workloads on Fly GPU Machines, there is no in-platform successor. You are choosing a new GPU provider, full stop, and you have roughly 72 hours to have picked one.

Two providers, two very different problems

It's worth being precise about what these two changes have in common and what they don't, because the right response is different for each.

Render's change is a cost and predictability problem. Your application keeps running exactly as it does today; the only thing that changes is what shows up on next month's invoice, and by how much depends entirely on your bandwidth profile. Nothing breaks on August 1 — you just might not like the bill on September 1.

Fly.io's change is an availability problem. If you have GPU Machines running, they stop existing. There's no overage to pay your way out of; there's no "acceptable cost increase" framing that fixes it. You either migrate the workload before the cutoff or it stops running.

What to actually do before August 1

If you're on Render:

1. Pull your last three months of bandwidth usage from the Render dashboard right now — don't estimate, check the real number.
2. Compare it against the new included allowance for your plan (5 GB Hobby / 25 GB Pro / unchanged on Scale) and multiply the overage by $0.15/GB to see your realistic new monthly cost.
3. If the number is uncomfortable, the fastest lever is offloading static assets (images, JS bundles, downloadable files) to a CDN — Cloudflare's free tier absorbs a lot of this without any application changes.
4. If you're evaluating a platform switch rather than architecture changes, we've published a full Render migration checklist covering the GDPR/CLOUD Act side of that decision in more depth than this post does — worth reading before you commit to a target platform.

If you're on Fly.io with GPU workloads:

1. Assume July 31, 2026 as your real deadline, not August 1 — the community-reported email date, not the docs' softer "after August 1" phrasing.
2. Inventory exactly which services depend on GPU Machines (inference, fine-tuning, batch ML jobs) — these need a new home, not a config tweak.
3. Evaluate a dedicated GPU cloud (RunPod, Modal, Lambda, or a major hyperscaler's GPU instances) for the GPU-dependent piece specifically. This is a genuinely different market than general-purpose PaaS hosting, and no general PaaS — sota.io included — is a substitute for it.
4. If your GPU workload was bolted onto an otherwise ordinary Fly.io app (API, background workers, database), you can decouple: move GPU inference to a specialist provider and keep — or migrate — the rest of the stack separately.

Where sota.io actually fits, and where it doesn't

To be straightforward about it: sota.io does not offer GPU hosting. If your problem is the Fly.io GPU deprecation specifically, this post can't sell you a fix — you need a GPU-specialist provider, and pretending otherwise wouldn't do you any favors.

What sota.io addresses is the other half of this story: the unpredictability that comes from usage-metered pricing on infrastructure you didn't choose for its billing model. sota.io runs on flat, predictable pricing — €9/month for 2 dedicated vCPU and managed PostgreSQL — with no per-GB bandwidth meter and no overage line item that changes shape when a provider updates its plans. It's also EU-incorporated (Germany), which sidesteps the CLOUD Act exposure question that comes with any US-incorporated PaaS regardless of which region you deploy to.

If you're the Render user staring at a new bandwidth bill and deciding whether it's cheaper to optimize your current setup or move, that's the actual decision this post can help with. If you're the Fly.io user with a GPU workload, solve that problem first with a specialist — then, if the rest of your stack is also due for a rethink, come back to the bandwidth-and-jurisdiction question separately.

Related: Render Bandwidth Cuts August 2026: EU Developer Migration Checklist and GDPR Alternatives · Render Pro Is $85/Month. sota.io Is €9. Both Give You 2 vCPU.