Skip to main content

Fly.io Killed GPUs on August 1: Where the Workloads Go and What They Cost Now

10 min readDora NodaDora Noda
Share
On this page

On August 1, 2026, Fly.io turned off its entire GPU product. Not a price hike, not a region consolidation — a whole compute category, gone. A100s, L40S cards, all of it: deprecated as of July 31, unavailable after. If you were running inference or fine-tuning on a Fly GPU Machine, your workload needed a new home before the deadline, full stop.

Here is the uncomfortable part: Fly.io is not dying. In July 2026 the company announced a $25M raise to double down on "computers for agents," alongside its strongest quarter on record, 37,000 customers, and agent-native workloads driving two-thirds of revenue from its largest accounts. The GPU shutdown is not a death rattle. It is a healthy company pruning a category that never became core — Fly staff said plainly that GPU users were "a very small amount" of the base, contacted directly, while the public notice was a quiet docs update.

That is precisely why this story matters beyond the handful of teams that had to migrate. A vendor does not need to be failing to delete your compute category. It just needs that category to stop being the strategy. So this post does two concrete things: it prices exactly what a Fly GPU workload cost versus what its replacements cost, and it maps where each workload shape should actually go.

Note: all prices below are per-GPU, on-demand, as last published — treat them as order-of-magnitude inputs, not quotes.

What Fly GPUs cost versus what replaces them

Fly's GPU pricing, as last documented, was the price of a standard Fly Machine plus the attached GPU. The on-demand GPU rates were:

GPUVRAMFly.io last rate
A1024 GB$1.50/hr
L40S48 GB$2.50/hr, later cut to $1.25/hr
A100 40 GB PCIe40 GB$2.50/hr
A100 80 GB SXM80 GB$3.50/hr

The headline feature was scale-to-zero: a GPU Machine could stop when idle, so bursty workloads paid only for active hours. That single property is what most replacements fail to reproduce, and it dominates the math below.

Now the replacements. There are two honest ways to price an owned box against an hourly rental: amortize the month over 730 hours for 24/7 workloads, and compare directly for bursty ones.

OptionHardwareMonthly~Hourly (24/7)
Hetzner GEX44 (when available)RTX 4000 Ada, 20 GB~€184/mo~€0.25/hr
Hetzner GEX131RTX PRO 6000 Blackwell, 96 GB~€889+/mo~€1.22/hr
RunPod on-demand (market)L40S 48 GBn/a~$1.19/hr
Vast.ai market rangeA100 80 GBn/a~$0.54–1.76/hr
Vast.ai market rangeL40S-classn/a~$0.61–0.88/hr

Worked example one — steady inference, 24/7. A single L40S on Fly at the reduced $1.25/hr costs roughly $912/month before the base Machine cost. The same always-on shape on an owned Hetzner GEX131 is on the order of €889/month for the entire machine with a larger 96 GB card. At full utilization, the hosted premium was roughly 1x the whole owned box — and at the original $2.50/hr L40S rate ($1,825/month), it was 2x.

Worked example two — bursty inference, ~100 active hours a month. Fly at $1.25/hr: ~$125/month, with nothing owed for idle time. An owned €184/month box is underwater here — you pay for 730 hours and use 100. This is the workload shape that genuinely loses from the shutdown, and it is where hourly markets (RunPod, Vast.ai, Lambda-style serverless GPU endpoints) earn their place: 100 hours of L40S-class compute at ~$0.70–1.20/hr lands at $70–120/month with no hardware commitment.

Worked example three — fine-tuning batches. A 40-hour A100 80 GB fine-tuning run cost $140 on Fly at $3.50/hr. On spot/preemptible markets the same run is $25–70. Fine-tuning never belonged on Fly's on-demand rates in the first place; the shutdown just forces the move teams should have priced out already.

The sensitivity is the point: utilization decides the winner. Above ~60% utilization, owning the machine wins by multiples. Below ~20%, hourly markets win. Fly's scale-to-zero GPUs occupied the awkward middle — convenient, premium-priced, and now gone.

Where each workload shape should go

There are three destinations, and the right one is determined by duty cycle, not by loyalty to any vendor.

Steady inference and always-on agents: buy the box. If your GPU is warm more than half the month, a Hetzner GEX-class dedicated server (or any owned/leased single-tenant box) is the cheapest correct answer. You trade away scale-to-zero and multi-region footprint for a fixed monthly bill and hardware nobody can deprecate. Run inference behind a queue with autoscaling replicas on the one box, and you recover most of what the Fly setup gave you operationally. Caveat: Hetzner's GPU line is thin — two models, frequently out of stock — so have a second-sourced fallback (a hourly-market account in warm standby) rather than assuming a GEX44 is orderable on demand.

Bursty, scale-to-zero workloads: hourly GPU markets. This is the shape Fly served best, and there is no owned-hardware answer for 5% utilization. RunPod, Vast.ai, and the newer serverless-GPU endpoints (Modal, serverless RunPod, Cloudflare-style inference APIs for standard models) reproduce the pay-for-active-seconds model, mostly at lower per-hour rates than Fly charged. The operational cost is real: you now manage machine images, cold-start latency, and spot-interruption handling that Fly abstracted. Budget a week of engineering to rebuild the autoscaling glue fly machines gave you for free.

Fine-tuning and batch training: spot and reserved capacity. Batch work with checkpointing should never pay on-demand hourly rates. Spot A100/H100 capacity on the large GPU markets runs a third to a half of Fly's discontinued $3.50/hr, and reserved machines or dedicated hosts close the gap further for recurring jobs. If you were fine-tuning on Fly on-demand, the migration is a pay cut for your GPU bill, not a raise.

One shape has no clean destination: GPU workloads that depended on Fly's global anycast footprint — inference that had to run in a dozen regions at once. No single owned box and no single-region hourly rental reproduces that. Those teams face a genuine architecture change: either consolidate regions behind higher latency, or split into per-region hourly capacity with the orchestration Fly used to provide. If that was you, the shutdown was not a migration; it was a redesign.

What actually breaks in the move

The cost table is the easy part. Migration checklists earn their keep on the unglamorous incompatibilities:

  • Scale-to-zero disappears. Nothing about an owned box idles to zero cost. Size for it explicitly: either accept paying for idle hours or rebuild autoscaling on an hourly platform. Do not port a bursty workload to dedicated hardware and act surprised by the bill.
  • fly.toml GPU config has no translation. GPU size, count, and Machine sizing were Fly-native concepts. Every destination has its own machine vocabulary — Docker images transfer, orchestration does not. Plan to rewrite deploy config, not convert it.
  • Cold starts get worse before they get better. Fly's Firecracker-based Machines booted fast with images cached warm. Hourly-market cold starts (image pull plus model weights into VRAM) are measured in minutes on a bad day. Pre-baked snapshots and kept-warm minimums are the fix, and both cost money — put them in the comparison.
  • Regions and networking change shape. Fly gave every Machine a global anycast address and private WireGuard mesh by default. An owned box gets you one data center and a public IP; multi-region means building your own routing, and private networking means Tailscale or equivalent. This is solvable weekend work, not a blocker — but it is work the old bill included.
  • Discounts and reservations evaporate. Fly offered reserved GPU machines and dedicated hosts at reduced rates. Those contracts are gone with the product. Whatever you negotiate next starts from zero volume history.
  • Watch the adjacent billing. The GPU shutdown arrived alongside other Fly monetization moves — free allowances removed for new orgs in October 2024, volume snapshots billed from January 2026. Migrating GPUs while leaving stateful volumes and CPU Machines on Fly without re-reading the pricing page is how you trade one surprise bill for another.

The harder lesson: how to evaluate a hosted compute category

Fly's arc is worth stating plainly, because the wrong moral ("avoid Fly") wastes the lesson. Fly built the most technically interesting hosted primitives of its era — Firecracker microVMs with a developer-facing Machine API, global anycast, sub-second deploys — then found its growth in CPU agent sandboxes, raised $25M to chase exactly that, and cut the GPU line its own staff described as a tiny user base. This is a strategy working as designed. Categories that are not the strategy get cut at healthy companies too.

So the checklist for adopting any hosted platform's new compute category — GPUs today, whatever is announced next year — has three questions:

  1. Is this category the vendor's business, or its experiment? Fly's business is agent computers; GPUs were an experiment with a small user base and a quiet deprecation thread. Experiments get shut down on product-review cadence, not on bankruptcy cadence. Favor categories the vendor's largest customers already depend on — that is where the $25M goes.
  2. What does the contract actually cover? Deprecation emails and docs notes are courtesies, not SLAs. If a category matters to you, get the sunset terms in writing (notice period, migration assistance) or architect as if notice is the 90 days you just watched Fly's GPU users get. Personal orgs reportedly could not even enable new GPU access months before the shutdown — the off-ramp narrows before the road closes.
  3. What is your exit cost, priced today? The teams that migrated calmly were the ones whose images were portable and whose orchestration was thin. The teams that panicked had Fly-native GPU config woven through their deploy pipeline. Before adopting a category, price the exit the way this post priced the migration: destination options, utilization sensitivity, and the week of glue work. If you cannot name the destination, you are not adopting a feature — you are taking on unpriced risk.

Owning the machine underneath a workload does not make you immune to change — hardware ages, providers reprice, Hetzner runs out of stock. But it changes the failure mode from "category deleted on someone else's roadmap" to "box needs replacing on a timeline you can see." That is the structural difference, and it is the whole argument: ephemeral compute primitives are rented conveniences, and rented conveniences get returned.

What comes next

The GPU market Fly is leaving is more liquid than the one it entered. Hourly markets are deeper, spot pricing is keener, and owned Blackwell-class boxes put 96 GB of VRAM on a fixed monthly bill that undercuts every hosted on-demand rate Fly ever published. Nobody migrating off Fly GPUs in 2026 lacks for destinations — they lack only the week to do the move and the honest utilization math to pick correctly.

Do the math first, pick by duty cycle, and write down your next exit before you need it. The next quiet docs update is already being drafted somewhere.

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.

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex