Skip to main content

Cloudflare Containers Went GA on 128MB-Workers Money: What Per-10ms Billing Actually Costs a Real Backend

8 min readDora NodaDora Noda
Share
On this page

Cloudflare Containers left beta for general availability on April 13, 2026, and the pitch is seductive: run FFmpeg, a real Linux toolchain, or an entire containerized backend on the same edge network that already runs your Workers — on top of a $5/month Workers Paid subscription, billed every 10ms you're actually running. That sounds like it should undercut everything. It doesn't, and the reason is specific: "active" billing only applies to the CPU line. Run the numbers on a real, persistent backend and the memory meter alone can land north of $30/month before a single CPU cycle is counted — against a flat $5.93/month for an owned box with more cores and no meter running at all.

The billing model, exactly

Containers require the Workers Paid plan ($5 USD/month), which bundles a monthly allowance and bills three resources separately once you exceed it, in 10ms increments while the container is awake:

ResourceIncluded (Workers Paid)Overage rate
CPU375 vCPU-minutes/month$0.000020 / vCPU-second
Memory25 GiB-hours/month$0.0000025 / GiB-second
Disk200 GB-hours/month$0.00000007 / GB-second

Six instance sizes are available, from lite (1/16 vCPU, 256 MiB) up to standard-4 (4 vCPU, 12 GiB). A charge window opens the moment a request hits the container or it's started manually, and closes when the instance goes to sleep after an idle timeout.

The nuance that decides whether this is cheap or expensive: CPU billing is genuinely active-only — Cloudflare only meters cycles the process actually consumes, not wall-clock time the container is merely awake. Memory and disk are not active-only. They bill on the instance's provisioned capacity for every second the container stays awake, whether or not it's doing anything. For a bursty job that sleeps most of the day, that distinction barely matters. For a persistent, multi-service backend that never sleeps — not the bursty, scale-to-zero job Containers is priced for — it means the memory line runs at full provisioned size, 24/7, for the entire month, regardless of load.

Worked example: a persistent backend that never sleeps

Take standard-1 (1/2 vCPU, 4 GiB memory, 8 GB disk) — the closest Containers tier to a small always-on VPS — and keep it awake for a full month (730 hours, 2,628,000 seconds):

Memory (bills full wall-clock regardless of CPU load): 4 GiB × 730 h = 2,920 GiB-hours, minus the 25 GiB-hour allowance = 2,895 GiB-hours billable → $26.06/month

Disk (same full-wall-clock treatment): 8 GB × 730 h = 5,840 GB-hours, minus 200 included = 5,640 GB-hours billable → $1.42/month

CPU (the only active-only line) — three utilization scenarios, since this is the one variable that actually moves:

CPU utilizationBillable vCPU-secondsCPU costTotal (mem + disk + CPU + $5 base)
100% (maxed)1,291,500$25.83$58.31/mo
20% (a real but unloaded backend)240,300$4.81$37.29/mo
5% (mostly idle, still awake)43,200$0.86$33.34/mo

The floor doesn't move much: even at 5% CPU utilization — a backend doing almost nothing — memory and disk alone cost $27.48/month before the base fee. "Active CPU" pricing is real and it's not marketing: it saves you the $25/month difference between the 100% and 5% rows. But it can't rescue a persistent workload from the memory and disk lines, because those were never metered on activity in the first place.

What the same footprint costs owned outright

Hetzner's CX23 — 2 vCPU, 4 GiB RAM, 40 GB NVMe — currently runs €5.49/month post-Hetzner's June 15, 2026 repricing (roughly $5.93 at current exchange rates). That's more vCPU than the Containers standard-1 tier (2 full vCPUs vs. half of one), the same RAM, five times the disk, and a flat price that doesn't move whether the box sits at 5% or 100% CPU for the entire month.

Cloudflare Containers standard-1, always-onHetzner CX23, owned
vCPU0.52
RAM4 GiB4 GiB
Disk8 GB40 GB
Monthly cost$33.34 – $58.31 (load-dependent)$5.93 (flat)

That's a 5.6x-to-9.8x gap for a workload with worse specs on the metered side. Nothing about that comparison is contrived — it's the same instance-size tier Cloudflare itself recommends as the entry point above basic, priced at whatever CPU load a real backend happens to carry.

Where Containers genuinely wins

The comparison above assumes a container that's awake the entire month, which is exactly the case Containers' billing model is not built to reward. Flip the duty cycle: a workload that's genuinely bursty — a webhook processor, a cron-triggered batch job, an on-demand media transcode — active 2 hours a day and asleep the other 22.

Same standard-1 instance, 60 active hours/month instead of 730, at a moderate 50% CPU load while running:

  • Memory: 4 GiB × 60 h = 240 GiB-hours, minus 25 included = 215 billable → $1.94
  • Disk: 8 GB × 60 h = 480 GB-hours, minus 200 included = 280 billable → $0.07
  • CPU: 0.5 vCPU × 50% × 60 h = 54,000 vCPU-seconds, minus 22,500 included = 31,500 billable → $0.63
  • Total: $2.64 + $5 base = $7.64/month

That's cheaper than provisioning a dedicated CX23 for a workload that's idle 92% of the time — because the CX23's €5.49 is a flat rent whether you use it for 2 hours or all 730, while Containers' bill shrinks with the duty cycle down to near-zero. Add global edge placement and zero patching/OS-ops burden, and this is the honest case for Containers: sleeps most of the time, wakes for short bursts, doesn't need to live near the rest of your always-on stack.

Where "just use Workers" stops, and what Containers still doesn't replace

Containers exist because Workers' V8 isolate model caps you at roughly 128MB of memory and pure-JS/Wasm execution — no FFmpeg, no arbitrary Linux binaries, no long-lived language runtime you didn't write for the isolate sandbox. That's a real ceiling, and Containers genuinely raises it: real containers, real CPU allowances up to 4 vCPU, disks up to 20 GB, on the same network that already terminates your TLS and routes your Worker requests. Before GA, hitting that 128MB wall meant leaving Cloudflare's edge entirely — standing up a second deployment on Fly.io (billed per-second, full wall-clock, for every machine left running), Render, or a raw EC2 box just to host the one piece that didn't fit in an isolate. Containers close that specific gap: the FFmpeg job, the cron task, the AI sandbox now has somewhere to live without adding a second vendor and a second bill to reconcile.

What GA doesn't change is which billing model fits which shape of workload, and it doesn't turn Containers into a general PaaS replacement for a workload that's supposed to run continuously. Fly.io's per-second-of-wall-clock pricing and Cloudflare's active-CPU-plus-wall-clock-memory pricing are two different answers to the same problem — metering a resource that's supposed to be provisioned continuously — and neither one is "free while idle" for a process that doesn't go to sleep. The billing model's own design is a tell: Cloudflare built this meter for workloads that spend most of their time asleep, and it prices persistent processes accordingly. A self-hosted platform running on owned hardware doesn't have that asymmetry to navigate at all, because there's no per-resource meter underneath a persistent backend to begin with — the box costs the same €5.49 whether it's pegged at 100% or coasting at 5%, and there's no math to redo when the duty cycle changes.

That's the actual dividing line for a real deploy decision in 2026: reach for edge Containers when the job is short, bursty, and benefits from running close to the request; run persistent, always-on services — the databases, APIs, and background workers that never sleep — on infrastructure priced for being on, not for being active.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on Cluster-API-managed machines you own, with no per-resource meter running underneath a service that's supposed to stay up. Star the repo on GitHub or deploy your first always-on service today.

Sources

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