Pricing for Cloudflare Workers
How pricing changes as you scale: upgrade triggers, cost cliffs, and plan structure (not a live price list).
Freshness & verification
Pricing behavior (not a price list)
These points describe when users typically pay more and what usage patterns trigger upgrades.
Actions that trigger upgrades
- You need more complex state/queue orchestration and stronger operational ownership
- Runtime limits block required libraries or workloads
- You need tighter cost/egress modeling as traffic scales
What gets expensive first
- Edge state choices (KV/queues/durable state) shape architecture and lock-in
- Observability must cover tail latency across regions/POPs
- Networking/egress patterns can change cost mechanics
- Edge vs region data locality decisions become visible under load
Plans and variants (structural only)
Grouped by type to show structure, not to rank or recommend SKUs.
- Request-path compute - middleware lane - Best when your workload is synchronous HTTP and latency-sensitive across geographies.
- State add-ons - choose your state model - Decide early whether you need durable state, KV/cache patterns, or queue-backed workflows.
- Official site/docs: https://developers.cloudflare.com/workers/
- Enterprise controls - multi-team rollout - Governance is about account structure, logging/audit, and allowed runtime capabilities.
Compare pricing trade-offs head-to-head
Use these comparisons when you are down to two finalists and need a clearer trade-off view.
Next step: constraints + what breaks first
Pricing tells you the cost cliffs; constraints tell you what forces a redesign.
Sources & verification
Pricing and behavioral information comes from public documentation and structured research. When information is incomplete or volatile, we prefer to say so rather than guess.
Something outdated or wrong? Pricing, features, and product scope change. If you spot an error or have a source that updates this page, send us a correction. We prioritize vendor-verified updates and linkable sources.