Cloudflare Containers pricing shifted on November 21, 2025: CPU is now billed on active usage instead of provisioned capacity. If you’ve been sizing for peaks and cruising at 15–40% CPU most of the day, you’re about to save real money. If you run hot at 70–95% CPU, the new math can be neutral or even higher. Let’s break down what changed, how to estimate the impact, and a concrete plan to optimize before month end. (developers.cloudflare.com)
What exactly changed in Cloudflare Containers pricing?
As of Nov 21, CPU for Containers and Sandboxes is billed per vCPU-second actually consumed, not the vCPU attached to your instance type. Cloudflare’s own example: a 1 vCPU standard-2 instance running for an hour used to cost $0.072 for CPU; at 20% utilization it now costs $0.0144—an 80% drop. Memory and disk pricing didn’t change and remain tied to provisioned resources while the container is active. (developers.cloudflare.com)
The current published CPU rate is $0.00002 per vCPU-second, with included monthly usage on the Workers Paid plan. Memory is listed at $0.0000025 per GiB-second and disk at $0.00000007 per GB-second, plus included allotments (25 GiB-hours memory, 375 vCPU-minutes CPU, 200 GB-hours disk) before overages apply. (developers.cloudflare.com)
Who wins and who loses with active CPU billing?
Here’s the thing: utilization now matters more than instance label. If your median CPU sits under ~50% and you chose a bigger instance to handle bursty peaks, you likely see double-digit savings. Conversely, sustained high-CPU workloads (streaming transforms, constant encoding, tight loops) will pay closer to their actual CPU use with less benefit from overprovisioning.
Memory-heavy but CPU-light services—think cache warmers, queue pollers, or API gateways that spend most time waiting—should benefit. Compute-bound agents, crawlers, and inference workers that saturate cores won’t.
Cloudflare Containers pricing: the new math you should use
To estimate this month’s bill, use a simple model:
- CPU: vCPU-seconds consumed × $0.00002, after 375 vCPU-minutes included on Workers Paid. (developers.cloudflare.com)
- Memory: provisioned GiB × active seconds × $0.0000025, after 25 GiB-hours included. (developers.cloudflare.com)
- Disk: provisioned GB × active seconds × $0.00000007, after 200 GB-hours included. (developers.cloudflare.com)
- Network egress: $0.025/GB in NA/EU, $0.05 in Oceania/Korea/Taiwan, $0.04 elsewhere (first 1 TB or 500 GB included, per region tier). (developers.cloudflare.com)
Important nuance: CPU is true usage; memory and disk still effectively meter by the size you choose while the instance is awake. Right-sizing memory is just as important as ever. (developers.cloudflare.com)
“Will my bill go down automatically?”
Often, yes—if you’ve been underutilizing CPU. Cloudflare’s published example shows an 80% drop at 20% mean CPU for a 1 vCPU instance. But if your services saturate the CPU, the delta could be small. Model a week of traffic with your real CPU duty cycle from logs to avoid surprises. (developers.cloudflare.com)
The practical playbook: 7 steps to capture savings
1) Establish a baseline from last week
Pull CPU duty cycle from your app metrics per container: p50, p90, p99. Then estimate vCPU-seconds: meanCPU × vCPU_per_instance × active_seconds × instance_count. Compare the result to your previous provisioned-per-hour heuristic. Use Cloudflare’s current rates and included allotments when you model. (developers.cloudflare.com)
2) Right-size memory aggressively
Because memory is billed by provisioned capacity while active, oversizing has a direct linear cost. Triage instance types (lite, basic, standard-1/2/3/4) and test lower-memory variants under peak load; memory pressure is easier to surface and cap than runaway CPU spend. (developers.cloudflare.com)
3) Embrace autosleep for bursty services
Charges start when a request hits or you manually start, and stop when the instance sleeps. Favor short idle timeouts for workloads with sporadic traffic. This reduces both memory/disk active time and the window for CPU accrual. (developers.cloudflare.com)
4) Tune concurrency and fan-out to match the new incentives
Cloudflare raised concurrent limits in late September (more memory, vCPU, and disk across live instances). Use this headroom to run more smaller instances that wake on demand, rather than a few big always-awake ones. That spreads load, tightens sleep windows, and trims memory charges. (developers.cloudflare.com)
5) Audit egress paths
Egress is still where stealth costs hide. If your containers talk to clouds outside NA/EU, model the $0.04–$0.05/GB tiers and consider collapsing traffic into regions with better included allotments. Pair this with smarter caching and batched writes to trim GBs. (developers.cloudflare.com)
6) Don’t forget Workers and Durable Objects on the invoice
Each container request still rides a Worker and a Durable Object. Track the CPU time in Workers (Standard model) and DO activity—especially for long-lived instances and chatty state. If you’re building on Workers for Platforms, set per-invocation CPU limits to cap blast radius. (developers.cloudflare.com)
7) Review adjacent services with their own meters
If your stack uses Browser Rendering (for puppeteer-style work) or Queues, include their specific pricing: $0.09 per browser-hour beyond the free tier, plus $2 per extra concurrent browser on bindings; Queues charge per 64 KB operation. Line those up next to your container model so an optimization in one layer doesn’t spike another. (developers.cloudflare.com)
Common traps and how to avoid them
Trap 1: Assuming “usage-based CPU” means you can ignore instance type. You can’t. Instance type still sets memory/disk sizing (and therefore cost while active). Right-size memory first, then let CPU float. (developers.cloudflare.com)
Trap 2: Leaving idle services awake. With CPU now “fair,” the biggest waste is paying memory/disk by the second while nothing happens. Tighten idle timeouts and verify they actually trigger under production traffic patterns. (developers.cloudflare.com)
Trap 3: Ignoring egress differentials. The NA/EU $0.025/GB tier plus included allotments can materially offset CPU savings if you pull data from higher-cost regions or chat across clouds all day. Revisit network paths. (developers.cloudflare.com)
Trap 4: Forgetting the Worker and DO line items. A heavy Durable Object can rack up active time even when the container is efficient. Keep those in your model and alert on drift. (developers.cloudflare.com)
How to forecast the next 30 days (a quick framework)
Use this simple worksheet for each service:
- Traffic: expected requests/day and average request duration.
- CPU: average CPU% per request × vCPU of instance × seconds active.
- Memory: instance GiB × active seconds; test the next smaller instance under load.
- Disk: instance GB × active seconds; confirm you actually need that local disk size.
- Egress: GB/day by region tier × published rates and included allotments. (developers.cloudflare.com)
- Platform: Workers CPU ms and Durable Objects active time; set CPU caps if you use Workers for Platforms. (developers.cloudflare.com)
Then add a 10–15% buffer for variability and compare to last month. If the delta exceeds 20%, stage a change in a canary project and re-baseline in 48 hours.
People also ask
Does this change affect my Cloudflare Workers bill?
Indirectly. Containers run behind Workers; you’ll still see Workers CPU time and requests on the bill. The pricing model for Workers itself didn’t change this month—monitor the Standard usage model and included CPU ms. (developers.cloudflare.com)
What about Sandboxes—do they follow the same rules?
Yes. Sandboxes adopt the same CPU-usage billing model and refer you to Containers pricing for the underlying rates. Memory and disk behave like Containers. (developers.cloudflare.com)
Will Cloudflare change anything else I should watch?
Two that matter for planners: (1) higher concurrent instance limits announced in late September unlock new scaling patterns; and (2) Browser Rendering moved to paid as of August 20, 2025, with its own duration/concurrency meters. If you stitch these into your platform, include them in forecasts. (developers.cloudflare.com)
Let’s get practical: a 30-minute optimization checklist
- Pull last 7 days of CPU duty cycle and recompute estimated vCPU-seconds per service.
- Drop one instance size for memory where p95 usage has 20–30% headroom.
- Enable or shorten autosleep timeouts for bursty services; verify with synthetic traffic. (developers.cloudflare.com)
- Reshard to more, smaller instances to tighten sleep windows now that concurrency limits are higher. (developers.cloudflare.com)
- Map egress by region; move chatty east–west flows into NA/EU where feasible. (developers.cloudflare.com)
- Set CPU caps for user Workers if you’re on Workers for Platforms; add alerts on DO active time. (developers.cloudflare.com)
Strategic implications for teams and budgets
Active CPU billing flips an old deployment habit on its head. Instead of “pick an instance big enough and forget it,” you’re rewarded for fine-grained scaling, fast sleep, and keeping CPUs idle when work isn’t present. Between the included monthly CPU/minutes and the lower per-second CPU rate, a lot of teams will see 15–40% savings from three moves: right-size memory, shorten idle windows, and split monolith containers into smaller, event-driven pieces that wake only when needed. (developers.cloudflare.com)
Zooming out, this change also makes multi-stage pipelines cheaper when most stages are not CPU-bound—fetch, validate, route, enrich—so long as stages sleep immediately after. Combine that with higher concurrency ceilings and you can chase latency goals without paying for idle. (developers.cloudflare.com)
Related reading and tools
We covered how to analyze Cloudflare’s older model and hidden line items in our deep dive on Cloudflare Containers pricing. If you’re reviewing budgets across your toolchain, compare this move with other recent billing shifts—see GitHub Actions billing changes—and consider network design changes that reduce egress, like the techniques in our NAT Gateway cost guide. If you’d like help auditing your setup or building a right-sizing plan, our services team does quick-turn cloud cost reviews.
What to do next (this week)
- Today: baseline CPU duty cycle per service; flag anything under 40% average.
- Tomorrow: stage memory right-sizing and idle timeout changes; canary release.
- 48 hours: verify autosleep works; check p95 latency and error budgets.
- End of week: re-run cost model with real traffic; lock in instance sizes and concurrency.
- Next week: add alerts for DO active time and Workers CPU ms; review egress paths. (developers.cloudflare.com)
Bottom line
Cloudflare’s shift to usage-based CPU unlocks savings for teams that size for peaks but live below 50% CPU. The winners will take a few hours this week to right-size memory, enforce sleep, and rework concurrency. Do the math once, automate the guardrails, and you’ll keep the savings compounding—without trading away latency or reliability.
