Fly.io Kills GPUs on August 1, 2026: Where Do Your Agent Sandboxes Go Now?

Fly.io GPUs are fully deprecated as of July 31, 2026. If you wired a GPU-backed Fly Machine into an AI-agent sandbox or a fine-tuning pipeline, that hardware disappears in three weeks, and Fly isn't shy about why: "developers don't want GPUs. They don't even want AI/ML models. They want LLMs." A product Fly launched with real conviction two years ago is being walked back because the company decided its own customers never actually wanted it.

That admission is worth sitting with, but it isn't the useful part of this story if you're the one holding a workload that has to move. The useful part is: where does it go, and what does it actually cost to get there? Below is the migration math — RunPod, Modal, and a self-hosted Hetzner GPU box compared across the duty cycles that actually show up in agent-sandbox and fine-tuning workloads — before we get into why Fly made this call in the first place.

The Migration Math, Up Front​

Two shapes of GPU workload get displaced by this deprecation, and they don't price out the same way.

Sustained, duty-cycle inference — a GPU sitting behind an agent's tool calls, answering requests some fraction of every hour — is the shape that actually determines whether renting or owning wins. The table below prices a single GPU across four duty cycles, comparing RunPod's on-demand rate, Modal's per-second serverless rate, and the flat monthly cost of owning the hardware outright on a Hetzner dedicated GPU server.

Two card classes matter here, because Fly's own GPU lineup split the same way: L40S was, in Fly's words, the only tier that saw "meaningful adoption," while A100-class cards served the smaller population of teams doing heavier inference or fine-tuning. Hetzner doesn't sell an exact L40S or A100 equivalent — its GPU dedicated-server line runs an RTX 4000 SFF Ada (20GB, €184/month, the GEX44) at the small end and an RTX PRO 6000 Blackwell Max-Q (96GB, €889/month, the GEX131) at the large end. Neither is a spec-for-spec match, and that mismatch is itself part of the honest answer below.

Small-card class (L40S-shaped workloads: 7B–14B local inference, agent tool-call sidecars) — GEX44 (~$200/month flat, incl. currency conversion) vs. renting an L40S:

The crossover against RunPod lands around 28% duty cycle; against Modal, around 14%. Below those thresholds, renting wins outright — and you get a bigger, faster card on top of it. Above them, the flat-rate box wins even though it's the weaker GPU. If your agent sandboxes only spin up a local model occasionally, don't buy hardware; if they're calling it most of the working day, the €184/month box pays for itself inside a month.

Large-card class (A100-shaped workloads: 70B+ inference, fine-tuning) — GEX131 (~$968/month flat) vs. renting an A100 80GB:

Here the crossover sits much higher — ~89% duty cycle against RunPod, ~63% against Modal — because RunPod's A100 rate is unusually competitive against Hetzner's biggest card. Unless your GPU is running nearly around the clock, renting an A100 beats owning a GEX131 outright. This is the honest, less flattering half of the self-hosting argument: bigger cards have to work a lot harder to justify ownership than smaller ones do.

Fine-tuning is a different shape entirely — bounded, occasional jobs, not sustained duty cycle. A representative 12-hour LoRA fine-tune of a 7B–13B model on a single A100 80GB costs $18 on RunPod or $25 on Modal — a one-off charge, no infrastructure to maintain afterward. Running that same job on an owned GEX131 that exists only for occasional fine-tuning runs is a bad trade: $968/month fixed cost against a handful of $18 jobs doesn't clear. Owned GPU capacity only makes sense for fine-tuning when the box is already earning its keep on sustained inference duty and the fine-tuning run is marginal, near-zero-cost extra work on hardware you were paying for anyway — never as the reason to stand the box up in the first place.

What Fly Actually Said​

Fly's rationale, laid out in its own "We Were Wrong About GPUs" post, is more specific than "GPUs didn't sell." The company built GPU Machines — Docker containers with mapped Nvidia GPUs, run through Intel Cloud Hypervisor to preserve the same millisecond-boot experience as its CPU fleet — and found it satisfied neither end of the market it needed. Serious ML teams wanted large H100 clusters Fly's single-GPU-per-Machine model couldn't offer; lightweight ML developers might have used Nvidia's MIG technology to slice a card into smaller pieces, but Fly's virtualization approach couldn't support it. Only L40S, the mid-tier card, found real adoption — and that wasn't enough to keep the product line.

The company's own framing is that this validates its broader philosophy: build for the 10,000-plus developers who want a generically useful primitive, not a specialized niche, and a mismatch like this one shows up early rather than after years of sunk investment. Whether or not you buy the framing, the practical fact stands regardless: a product a well-funded infrastructure vendor launched with a public blog post and shipped for two years is now gone with about four months' notice from announcement to full deprecation.

What Actually Breaks for Agent-Sandbox Builders​

The deprecation is narrower than "Fly is exiting AI infrastructure" — and worth being precise about, because the blast radius depends on which Fly product you're actually running. Fly Sprites, the company's stateful, persistent sandbox product purpose-built for AI agents, never had GPU access to begin with; GPU support lived on raw Fly Machines, a separate product line. Sprites give an agent a durable filesystem, fast checkpoints, and MCP-native tooling — but if an agent needed to call a local model, that meant provisioning a standalone GPU Machine alongside the sandbox fleet and wiring the two together over the network.

That's the specific pattern this deprecation breaks: a fine-tuning job that ran as its own GPU Machine, or a local-inference sidecar a CPU-only Sprite called over HTTP for latency-sensitive tool calls (routing a code-review agent's diff through a locally hosted model instead of round-tripping to a hosted API, say). If your agent sandboxing is entirely CPU-bound Sprites or Fly Machines with no GPU attached, this deprecation doesn't touch you. If you provisioned even one GPU Machine to sit behind your agent fleet, you have three weeks to have moved that workload somewhere else.

The Sharper Risk Isn't the Price — It's Who Controls the Line Item​

The pricing tables above answer "where do I move this workload today," but they understate the actual lesson, which isn't about dollars per hour. Fly launched GPU Machines with a public blog post in early 2024 and killed the entire line two years later, on roughly four months' notice from the deprecation announcement to the hard cutoff. RunPod and Modal are exactly as exposed to the same failure mode — they're rented compute from a vendor whose roadmap you don't control, and nothing stops either from making the same call on their own GPU tiers whenever the unit economics stop working for them.

That's the actual case for treating owned GPU capacity as a durable platform primitive rather than a rentable line item: not that it's always cheaper (the tables above show plainly that it often isn't, especially on larger cards at low utilization), but that a vendor can't sunset hardware you already own. This is where a Cluster-API-based platform's existing machinery matters more than it looks like it should. Cluster API Provider Hetzner already supports Hetzner's dedicated (Robot) servers through HetznerBareMetalHost/HetznerBareMetalMachine resources, alongside its more common Hetzner Cloud VM path — and a GEX44 or GEX131 is just another dedicated server on that same API. Onboarding a GPU node into a Cluster-API fleet isn't a specialized feature bex or any CAPH-based platform has to build; it's the existing bare-metal provisioning path pointed at a box with a GPU in it.

The honest limit is worth stating plainly: this is CAPH's general dedicated-server path, not a purpose-built GPU node pool with autoscaling. A rented A100 on RunPod can scale to zero between jobs; an owned GEX131 in your fleet can't shrink below the one dedicated server it is. That's exactly why the duty-cycle math above matters more than a blanket "own your infrastructure" argument — a GPU node earns its place in an owned fleet only once its actual utilization clears the threshold the tables show, not because ownership is categorically better.

The Actual Decision​

Migrating off Fly GPUs by July 31 comes down to one question the tables above already answer: what's the duty cycle? Occasional fine-tuning jobs and bursty, low-utilization inference belong on RunPod or Modal — metered, no infrastructure to run, and cheaper than owning at anything under roughly a third of a month's hours for a small card or nearly all of it for a large one. Inference that's actually running most of the working day belongs on hardware you own, where the vendor who sunset your GPU line two years into a product bet can't do it to you a second time.

The pattern here isn't new — this list has already tracked Render slashing included egress and Vercel restructuring metered limits — but a company killing an entire compute product line four months after telling customers not to worry is a sharper version of the same risk. A CPU node pool can absorb that kind of vendor churn by shrugging and re-provisioning; a GPU node pool that only exists as someone else's rented SKU can't.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, provisioned through Cluster API's existing Hetzner Cloud and dedicated-server paths. If you're migrating GPU-backed agent workloads off Fly, the same owned-infrastructure math applies to the rest of your stack. Star the repo on GitHub or deploy your first app today.

Sources​

• We Were Wrong About GPUs — The Fly Blog
• GPU migration — "Fly.io GPUs will be deprecated as of July 31, 2026" — Fly.io Community
• Fly GPUs · Fly Docs
• Sprites (Fly.io) — Ry Walker Research
• The AI Agent Sandbox Wars: E2B vs Daytona vs Modal vs Fly Machines Compared
• GPU Cloud Pricing | Per-Second H100, A100, RTX — RunPod
• L40S GPU Rental | Specs and Pricing — RunPod
• A100 SXM GPU Cloud — RunPod
• Plan Pricing — Modal
• GPU acceleration — Modal Docs
• Hetzner GEX44 dedicated GPU server
• Hetzner GEX131 dedicated GPU server
• Cluster API Provider Hetzner (CAPH) — GitHub
• What is the Cluster API Provider Hetzner — CAPH Docs