Fly.io Is Killing GPUs on August 1: What Two Retreats in Three Years Say About Renting vs Owning Your Accelerators

Fly.io will make every GPU Machine unavailable after August 1, 2026. If you deployed an A10, L40S, or A100 on Fly in the last two years — the scale-to-zero Machines that made inference easy without owning a box — you have weeks, not quarters, to move it somewhere a vendor can't deprecate on a roadmap slide.

That sentence is the overdue migration notice this post pays off. Below is the concrete accounting you need: what disappears on which date, what each replacement costs for the same workload at continuous and bursty utilization, and why a self-hosted GPU node pool provisioned through Cluster API is a durable primitive rather than a rentable SKU.

The sunset at a glance​

Fly's own Resource Pricing page labels these tiers "GPU-enabled Fly Machines (Deprecated)," and the GPU docs carry the hard cutoff: unavailable after August 1, 2026. The free-tier removal on Oct 7, 2024 and billed volume snapshots since Jan 1, 2026 were earlier chapters of the same narrowing — this chapter removes an entire hardware class.

Second time counts. In early 2024 Fly expanded GPU access ("GPUs on Fly.io are available to everyone" — Simon Willison, Feb 2024), then by late 2024 publicly retracted GPU ambitions as the architecture fit inference poorly. Cutting L40S to $1.25/hr in mid-2024 (Fly blog) was the reprieve between retreats; the current $0.70/hr L40S is the same SKU, now deprecated. Two retreats from GPUs in three years is a product signal, not a pricing action.

Migration preview. For one always-on L40S (720 hr/mo), Fly billed ~$504/mo. The same L40S-class capacity is $115–$498/mo on marketplace GPU clouds and €889/mo flat on an owned Hetzner RTX PRO 6000 box — or ~€184/mo at the entry GPU tier. The cheapest rented option wins at 10% utilization; the owned box wins once utilization crosses ~55–70%. Full table in Section 3.

1. What Fly is actually killing​

A Fly GPU Machine was a Fly Machine with an attached NVIDIA GPU that billed per-second while running and stopped when it scaled to zero. That fit bursty inference (handle a request, sleep) and small-model fine-tuning, which is why the A10 became Fly's most popular GPU by its own account. The platform did the hard parts: no driver install, no CUDA pinning, a fly.toml with gpu = "l40s" and an image that already knew how to talk to the card.

What changes on August 1 is binary: the Machine type ceases to provision. There is no legacy pool and no bring-your-own-host escape hatch. Your Dockerfile still builds; fly deploy --gpu has nowhere to land. Data on volumes and snapshots remains yours to export, but the compute that gave it meaning is gone.

This is not a repricing you can absorb. A price hike is re-forecasting; a product sunset forces a migration — new credentials, new drivers, new autoscaling semantics — on a vendor-set clock. The notice lives in the pricing table itself, not a blog footnote. If your workload is still on Fly GPUs on August 2, it does not run.

2. Zero open roles is a vital sign​

On July 29, 2026, three boards agreed:

• Fly.io — 0 open roles. Both the YC jobs page and Himalayas showed zero, consistent with HireTechLadies.
• Render — 22 open roles and Railway — 18 on the same date via their careers pages.

Hiring is capacity planning for a PaaS. A platform that still advertises broad hiring showing zero requisitions while two direct competitors each carry a full board is choosing a smaller surface area.

Stack that with eighteen months of narrowing:

• Oct 7, 2024 — Free allowances removed, replaced by a 2-hour / 7-day trial.
• Jan 1, 2026 — Volume snapshots become billable.
• Early 2026 — Two new billing line items appear without a sticker-price increase.
• Aug 1, 2026 — An entire hardware class retires.

None alone is fatal. Together they read as a team deliberately shrinking what it operates. That is rational focus — but for a tenant it means: Fly's future is CPU Machines, not accelerators. Plan accordingly.

3. Where the workload lands: rent vs own​

Take one concrete workload: one L40S-class inference worker serving a 7–13B model, at 720 hr/mo always-on vs 72 hr/mo bursty (10% util). Rented options bill per-second with scale-to-zero; owned bare-metal bills flat monthly.

Always-on (720 hr/mo)​

Bursty (72 GPU-hr, 10% util) — where renting wins​

How to read it:

• Bursty / spiky / dev — rented per-second clouds win. A flat box idle 90% of the day is idle spend. Fly's scale-to-zero was exemplary here; RunPod and Lambda preserve the shape.
• Always-on at >55–70% util — flat bare-metal crosses below rented. At 100%, even a premium €889 Blackwell box is within 1.5–2× a mid-tier rented L40S, and the entry €184 tier is cheaper than renting.
• Batch fine-tuning — a few hours of 8×H100 then nothing: rented spot (RunPod Community $0.75–$1.29/hr) is cheapest per experiment; owned wins only if you fine-tune weekly on the same iron.

The honest take: no single row tells you the answer. The variable that drives cost is utilization. A sane platform lets you own the steady-state fleet and burst spikes to a metered neighbor — the same pattern this blog's burst-provisioning entry traced for build nodes.

One hidden line: egress and snapshots. A rented cloud that meters egress or snapshot storage can add $50–$200/mo quietly. A Hetzner box includes 20TB traffic; Garage/MinIO on it has no egress meter at all. The table above is compute-only.

4. Why owning the node pool is structurally different​

Renting a GPU is renting a SKU. Owning a GPU node pool is owning a primitive.

A rented SKU — Fly's L40S Machine, RunPod's pod, Lambda's instance — exists as long as the vendor's roadmap says so. The vendor can reprice it, throttle availability (the 2024 retraction), or remove it (Aug 1, 2026). Your app's fate becomes a procurement decision you don't control. A workload supported on July 31 is undeployable on Aug 2 because the catalog entry was deleted.

An owned pool provisioned through Cluster API Provider Hetzner (CAPH) has no catalog to delete. Machines are Machine objects in your management cluster; the GPU is a node.kubernetes.io/gpu label and a nvidia.com/gpu resource. Adding an RTX PRO 6000 is a line in a manifest, not a ticket to a vendor's GPU team.

# bex.yml — excerpt: add a GPU pool beside your CPU fleet
fleet:
  provider: hetzner
  region: nbg1
pools:
  - name: cpu-workers
    kind: cpx31
    replicas: 3
  - name: gpu-inference
    kind: gex131        # RTX PRO 6000 Blackwell, 96GB — €889/mo flat
    replicas: 1
    taints: ["nvidia.com/gpu:NoSchedule"]
    labels:
      workload: inference

Scale that pool to zero replicas when a model retires; the provider bills the machine while it exists, not a per-second meter. You lose per-second granularity and gain sunset immunity — no vendor can discontinue a machine already yours. You also take on drivers (CUDA, nvidia-device-plugin, MIG slicing) and capacity planning — Hetzner restricted new server creation on June 26, 2026 when DRAM scarcity bit. Those are operability costs you can budget; a product removal is a risk you cannot.

This is the same seam a single-box PaaS like Dokku or Coolify hits at the CPU layer — fine for one machine, no story for the second — replaying at the accelerator layer. A PaaS on Kubernetes via Cluster API doesn't have that ceiling.

5. The before–August–1 checklist​

Treat this as a two-week sprint if you still run on Fly GPUs.

1. Inventory. fly machines list --app <app> for every app; note gpu fields, volumes, snapshot ages, autoscale config.
2. Export. fly image show + volume snapshots to S3 you control (R2/B2/Garage). Pin the image digest; after Aug 1 you cannot re-dump a running GPU Machine.
3. Pick the lane. Always-on (>60% util) → owned bare-metal (Hetzner/Scaleway). Bursty/batch → rented (RunPod/Lambda). Mixed → both, with placement labels.
4. Re-target deploy. Swap fly.toml's [gpu] block for a Kubernetes Deployment with resources.limits: { nvidia.com/gpu: 1 } and nodeSelector: { workload: inference }. Same image, different scheduler.
5. Cut over before July 31. Mirror traffic to both stacks for a day; DNS cutover on July 31 leaves Aug 1 as buffer, not deadline day. Keep the Fly export 30 days as rollback.

After Aug 1 the checklist is one line: Fly GPU Machines will not start.

The accelerator you own can't be deprecated​

PaaS economics is often framed as rent vs buy on price. Fly's second GPU retreat in three years reframes it as rent vs own on durability. A metered L40S at $0.70/hr was cheap — then it was gone. A rented H100 at $1.89/hr is cheap today and reprices when DRAM does. An owned RTX PRO 6000 at €889/mo is boring every month, which is precisely what production inference needs: it will still be there when the next vendor email is about a product that no longer exists.

That is the durable-primitive argument for a self-hosted PaaS GPU pool. Not that bare metal is always cheaper (it isn't — see the bursty row), not that it is zero-ops, but that it is yours. A vendor can sunset a SKU; it cannot sunset a Machine you provisioned through your own Cluster API management cluster. The distinction outlives any pricing table.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. A GPU node pool is just another pool in bex.yml. Star the repo on GitHub or deploy your first app today.