Dora NodaGoogle's Cloud Run team picked an interesting week to ship Blackwell GPU support. On April 14–15, 2026, Worker Pools — Cloud Run's primitive for long-running, non-request-driven workloads — reached General Availability, and NVIDIA RTX PRO 6000 Blackwell GPUs became available alongside it. A few months later, Fly.io confirmed the opposite bet: every GPU Machine on its platform goes dark for good on July 31, 2026. One hyperscaler is doubling down on GPU-backed serverless; one boutique PaaS is walking away from GPUs entirely.
Here's the number that matters before you pick a side: run the required minimum Worker Pool configuration for a Blackwell GPU 24/7 for a month, and the mandatory CPU-and-memory reservation alone — before Google even bills you a cent for the GPU itself — costs more than Hetzner's entire comparable GPU box, GPU included. That's not a rough guess. It's arithmetic straight off Google's own published rate card.
What actually shipped, and the rule that makes it comparable to owned hardware
Worker Pools exist for the workloads Cloud Run's classic request-driven model was never built for: instances that pull from a queue, run a background job, or hold a model warm for streaming inference — work that doesn't wait for an inbound HTTP request to justify running. Google's announcement pairs that primitive with the RTX PRO 6000 Blackwell GPU: 96GB of VRAM, up to 44 vCPU and 176GB of RAM per instance, currently available in us-central1 and europe-west4. To attach one, Google's docs require a minimum of 20 vCPU and 80GiB of memory — that floor isn't optional.
Two mechanical details turn this from a feature announcement into a real cost question:
- GPU worker pools cannot autoscale. There's no scaling to zero between jobs the way a request-driven Cloud Run service does.
- You're billed for the entire instance lifecycle, including idle time. Google's documentation is explicit: "You are charged for the GPU even if the GPU is not running any process, and as long as the worker pool GPU instance is running."
Put those two rules together and a Blackwell Worker Pool behaves exactly like an always-on box you rent by the hour, not like the scale-to-zero Cloud Run that made its name on billing you only while a request was in flight. That's precisely the property that makes it fair to compare against an owned GPU server instead of against Cloud Run's own request-based pricing.
The floor number, worked
Cloud Run's published Tier 1 rates for always-allocated CPU and memory are $0.0000240 per vCPU-second and $0.0000025 per GiB-second. Apply those to the mandatory Blackwell minimum — 20 vCPU, 80GiB — running continuously, and the GPU line item hasn't even entered the picture yet:
| Resource | Rate | Quantity | Cost/hour |
|---|---|---|---|
| vCPU | $0.0000240/vCPU-sec | 20 vCPU | $1.73 |
| Memory | $0.0000025/GiB-sec | 80 GiB | $0.72 |
| CPU + memory floor | $2.45/hr |
Run that 24/7 for a 730-hour month and the reservation alone comes to $1,787/month — and that's before Google adds a single dollar for the Blackwell GPU, which it doesn't publish a per-second rate for on the same public pricing page it uses for its other GPU tier.
Compare that floor to what Hetzner charges for its closest owned equivalent. The GEX130 dedicated server — RTX 6000 Ada, 48GB VRAM, a step down from Blackwell's 96GB but the largest single-GPU box Hetzner currently sells — runs €838/month (about $955 at July 2026's ~1.14 EUR/USD rate), GPU, CPU, RAM, and storage all included, plus a one-time €79 setup fee.
The mandatory reservation Google bills you just to hold the Blackwell slot open costs roughly 1.9x more than Hetzner's entire GPU server — a server that includes the GPU Google hasn't even charged you for yet. Add any nonzero per-second Blackwell rate on top of Cloud Run's $1,787 floor and the gap only widens.
The complete number, where the GPU rate is actually public
Google does publish a GPU rate for its other Worker Pool option — the NVIDIA L4, 24GB of VRAM, requiring a minimum of 4 vCPU / 16GiB (8 vCPU / 32GiB recommended). At $0.0001867 per second without zonal redundancy, that's about $0.67/hour, and it lets us run the full comparison end to end, GPU line included, using numbers Google actually discloses:
| Config | CPU + memory | GPU | Total/hour | Total/month (730h) |
|---|---|---|---|---|
| L4, minimum specs (4 vCPU / 16GiB) | $0.49/hr | $0.67/hr | $1.16/hr | $848 |
| L4, recommended specs (8 vCPU / 32GiB) | $0.98/hr | $0.67/hr | $1.65/hr | $1,205 |
Hetzner's GEX44 — RTX 4000 SFF Ada, 20GB VRAM, a reasonably comparable single-GPU inference box — runs €184/month (about $210), plus a €79 one-time setup fee. Even at the bare-minimum Cloud Run spec, an always-on L4 Worker Pool costs about 4x what the equivalent owned Hetzner box costs. At the recommended spec, it's closer to 5.7x.
Two independent worked examples, two different GPU tiers, both landing in the same 4–6x range — this isn't a single cherry-picked data point.
That range is also the floor, not the ceiling. Cloud Run defaults to zonal redundancy on GPU worker pools — better failover, at a cost — and disabling it is an opt-in step, not the default. With zonal redundancy left on, the same L4 GPU line jumps from $0.0001867/sec to about $0.0002909/sec (roughly $1.05/hour instead of $0.67), pushing the recommended-spec L4 pool to about $1,480/month against Hetzner's $210. A team that never touches that setting pays a wider gap than the numbers above show, not a narrower one.
Where "narrows the gap" is real, and where it isn't
There's a real structural shift buried in these numbers, and it's worth naming precisely because it cuts against the framing you'd expect. For years, the honest argument against comparing Cloud Run to owned hardware was that they weren't playing the same game — Cloud Run's whole pitch was billing only for active request time, while an owned box billed flat whether it sat idle or not. Worker Pools' no-autoscale, billed-when-idle rule ends that argument. A GPU Worker Pool is now, mechanically, an always-on rented box — the same category of thing as a Hetzner server. Google closed the "we don't even compete on the same axis" excuse.
What it didn't close is the price gap on that axis. Once the comparison is apples to apples — always-on reserved compute versus always-on reserved compute — Cloud Run still costs 4 to 6x what the owned equivalent costs, on Google's own published numbers, using the cheaper of its two GPU tiers where we can actually see the GPU rate. Narrowing the framing gap and narrowing the price gap turned out to be two different things.
It's also worth noting Google didn't have to make this choice. Fly.io Sprites, launched the same year, bet the opposite direction for AI sandbox workloads: $0.07/CPU-hour and $0.04375/GB-hour with zero charge while idle — a 4-hour Claude Code session runs about $0.44 specifically because idle time between bursts of activity costs nothing. Sprites and GPU Worker Pools solve adjacent problems — ephemeral CPU sandboxes versus persistent GPU inference — but they represent a real industry split on how to price the moments a workload isn't doing anything. Worker Pools moved toward Hetzner's model, not away from it.
One honest caveat belongs in the Blackwell comparison specifically: Hetzner doesn't sell a Blackwell-class dedicated card today, so the GEX130 pairing is the closest owned hardware gets, not a like-for-like match. That asymmetry cuts in favor of the argument here, not against it — the $1,787/month floor is being compared to a weaker card than the one Google is renting out, and Cloud Run still can't come close on price. A true Blackwell-to-Blackwell comparison would need a rented EU alternative like Scaleway's B300 tier, which starts north of $8/hour per GPU — worse for the rental side, not better.
What this actually means if you're choosing today
None of this makes Worker Pools a bad product — it makes it a specific-purpose one. It's the right call when a GPU job is genuinely short-lived, when you need a region Hetzner doesn't reach, when procurement lead time on owned hardware is the actual constraint, or when the ops overhead of running your own fleet outweighs a few hundred dollars a month for a small workload. Where it stops making sense is the workload this feature is explicitly built to serve: an inference endpoint or agent sandbox that needs to stay warm continuously — precisely the case where "billed even while idle" turns from a footnote into the entire bill, and where an owned box amortized over weeks of runtime wins by 4-6x on the numbers above.
For a platform that already runs its fleet on owned Hetzner hardware behind Cluster API, this is the argument in its cleanest form yet: the hyperscaler closed the "we're a different kind of billing model" gap and still lost the unit-economics fight once the two sides were finally measured the same way.
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.
