Fly.io Kills GPU Hosting on August 1, 2026: Where the Workloads Go, and What It Actually Costs

On July 31, 2026, every GPU Machine on Fly.io stops being billable. On August 1, they stop existing. Fly's own docs now carry a single blunt line at the top of every GPU page: "GPUs are deprecated and will be unavailable after August 1." No grace period beyond that date, no grandfathered pricing, no quiet sunset — a hard stop for every team that built an inference endpoint, a fine-tuning job, or a document-processing pipeline on Fly GPU Machines.

If you're one of those teams, the question isn't whether to move. It's where, and what it actually costs once you get there.

The community thread announcing the deadline makes the stakes concrete. One team describes a document-processing pipeline built around L40S Machines for OCR and layout analysis — chosen specifically because Fly was the easiest platform to build the rest of the app on — now facing a forced split between wherever the GPU work goes and wherever the app itself stays. That split, and the deadline forcing it, is the actual problem this post is here to solve.

Where the workload actually goes, with real numbers​

Fly's GPU rates, as billed until the shutdown, were never expensive: $0.75/hour for an A10, $0.70/hour for an L40S, $1.25/hour for an A100 40G PCIe, $1.50/hour for an A100 80G SXM, billed by the second on top of the underlying Machine. Whatever you migrate to gets measured against that baseline.

There are exactly two kinds of destination, and they don't cost the same way:

Rental marketplaces — RunPod, Modal, Google Cloud Run GPU — sell GPU-hours the same way Fly did, just without the exit risk (for now).

Owned hardware — a dedicated GPU box you rack under your own control plane instead of renting someone else's — is priced flat, by the month, regardless of how many hours you actually use it. Hetzner's two dedicated GPU servers, the closest thing to an "own it instead" option for a Cluster-API-managed fleet:

Here's the fact that has to come first: if your Fly workload runs on an A100 or bigger, owning isn't an option at all. Hetzner's dedicated GPU line tops out at the RTX 6000 Ada — a 48GB workstation-class card good for inference and fine-tuning up to roughly 70B parameters at 4-bit quantization, not the 80GB data-center card Fly billed at $1.50/hour. There's no H100 or A100 dedicated server to buy. For that tier, renting from a marketplace isn't the cheaper option — it's the only option.

For the RTX-class tier Hetzner does sell, run the actual break-even math before assuming ownership wins. A GEX130 costs about $935/month, which is $1.28/hour amortized over a full 730-hour month. RunPod's Secure Cloud rents the same RTX 6000 Ada for $0.77/hour. Run it every hour of every day for a month and the rental bill is $562 — still $373 cheaper than owning the box outright. At 100% utilization, for one team's workload, renting still beats owning. That's the opposite of the usual "buy hardware once utilization gets high enough" intuition, and it's worth stating plainly instead of assuming the math works out the way owned-infrastructure pitches usually claim it does.

Ownership only pencils out once the box stops being one team's box. A GEX130's $935/month fixed cost is the same whether one workload uses it eight hours a day or five different tenants' jobs fill every hour between them. Spread across five tenants each already paying, say, $200/month in marketplace rental fees, that's $1,000/month in aggregate rental spend against $935 to own the same hardware outright — a win, but only because a Cluster-API-managed fleet can bin-pack multiple tenants' inference jobs onto the same physical GPU. A single company buying one GPU server for its own workload is very likely making the wrong bet; a platform operator scheduling many tenants onto shared GPU hardware is making a different one.

There's one more variable worth factoring in before writing off ownership entirely: data residency. Hetzner's GPU servers run exclusively out of Germany (Nuremberg, Falkenstein) and Finland — every byte of model input and output stays inside the EU by construction, no separate compliance configuration required. A team with GDPR obligations weighing RunPod or Modal against owned EU hardware isn't just comparing dollars per hour; they're comparing dollars per hour against the cost of proving data never left the EU on a rented marketplace instance. That doesn't change the break-even math above, but it does mean the math isn't the only input to the decision.

Why Fly is walking away from GPUs​

Fly told the reasoning part of this story itself, a year before the shutdown notice, in a post candidly titled "We Were Wrong About GPUs." The core admission: "developers don't want GPUs. They don't even want AI/ML models. They want LLMs." Fly's own design principle is to build for 10,000 developers, not 5 or 6 — and GPU renters turned out to be the 10,001st developer, a niche the core platform wasn't shaped around.

The mechanics backed up the conclusion. Fly shipped GPUs on dedicated hardware to avoid mixing them with ordinary CPU workloads, which meant utilization was bad by construction — the exact opposite of the pooling math above, at Fly's own scale. Getting Nvidia's driver stack working reliably inside Fly's lightweight flyd hypervisor took months of fighting an ecosystem built for bare metal, not microVMs, and Fly's security review process for running someone else's untrusted code on directly-attached hardware (rather than a virtualized slice of it) added cost on every GPU Machine shipped. Of the GPU tiers Fly offered, only the L40S saw adoption that looked like a real product line rather than a curiosity — serious AI researchers needing large-scale training capacity found Fly's offering too small, while lightweight inference users ran into a platform that never built GPU-slicing to right-size a card for a small workload.

Fly isn't the only hosted platform quietly admitting a hardware bet didn't clear the bar. AWS announced on March 31, 2026 that App Runner is moving to maintenance mode — no new customers after April 30, 2026, existing ones kept on life support while Amazon steers everyone toward ECS Express Mode instead. That's a hyperscaler, not a startup, deciding a managed compute product wasn't worth continued investment. On the GPU side specifically, DigitalOcean's own community forum has carried reports of GPU Droplet capacity simply running out in multiple datacenter regions — not a deprecation notice, but the same underlying signal: hosted GPU capacity is a line item platforms adjust when it doesn't fit their roadmap, and the adjustment lands on whoever built on top of it.

The migration checklist, and the lesson underneath it​

Before July 31, every team still on Fly GPU Machines needs to work through the same four steps:

1. Pull your model weights and volumes off Fly now. Fly's GPU Machines mount local NVMe for model weights; that storage disappears with the Machine. Copy weights to S3-compatible storage (Tigris, Cloudflare R2, or your destination provider's blob store) before the deadline, not the week of it.
2. Sort your workload by GPU tier. If you're on A100 or bigger, you're choosing between rental marketplaces — RunPod, Modal, GCP Cloud Run GPU — full stop, per the table above. If you're on L40S or smaller, you additionally have the owned-hardware question to answer.
3. Answer the owned-hardware question with the utilization math, not intuition. One workload, even run continuously: rent. Multiple tenants' workloads that a scheduler can pack onto shared hardware: owning starts to make sense.
4. Separate the GPU decision from the rest of your stack. The API layer, the web frontend, the queue workers, the cron jobs — the non-GPU majority of what was running on Fly — don't have an ownership-versus-rental tradeoff. They're ordinary compute, and they're exactly what a Cluster-API-managed fleet on owned hardware is built for.

That last point is the real lesson Fly's shutdown leaves behind, and it isn't about GPUs specifically. Every team that built GPU Machines into their Fly deploys got zero vote in Fly's decision to walk away from the product line — the notice arrived, and the deadline started. That's the risk inherent to building on any hosted platform's roadmap: the parts of your infrastructure that live on someone else's business decision can be discontinued out from under you, no matter how solid the pricing or how good the docs looked the day you signed up.

Owning the box doesn't make that risk disappear for GPU-heavy workloads — the math above shows renting often wins there anyway. But it does remove that risk for everything else: the services that make up the bulk of most teams' deploys, running on hardware nobody can sunset out from under you on a date they picked.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.