Cloudflare Workers

What Cloudflare Workers actually is

Cloudflare Workers is a serverless execution platform: you write request handlers, deploy them, and they run at every one of Cloudflare's 330-plus data centers at once. There is no region to pick and no fleet to provision — a request from Osaka and a request from Rotterdam both hit the same code running locally to each of them. The runtime is V8 isolates rather than containers, which is the technical reason behind the product's most-cited property: isolates start in microseconds, so there is no cold-start penalty of the kind that shapes architecture on container-based serverless platforms. Workers opened to everyone on March 13, 2018, and in our view it remains the reference point for what edge compute pricing and ergonomics should look like.

The language story is broader than the JavaScript name suggests. JavaScript and TypeScript are first-class, Python reached general availability, and other languages — Rust, Go, C++ — compile to WebAssembly and run in the same isolate. The platform primitives around the runtime are what make it a platform rather than a function toy: Workers KV for global key-value reads, Durable Objects for stateful coordination with a SQL storage backend, D1 for serverless SQLite, R2 for object storage, Queues for message processing, Hyperdrive for connecting to existing Postgres, and static asset serving built into Workers themselves. Bindings wire these together declaratively in wrangler.toml, and the request path between them stays inside Cloudflare's network.

The billing model is the other defining choice: Workers bills CPU milliseconds, not request counts alone. A request that serves from cache or static assets is free; a request that runs 2 ms of logic costs almost nothing even at volume. That alignment — pay for compute actually consumed, not for requests received — is why the platform is cheap for read-heavy workloads and why the Free plan is viable for real traffic rather than a demo.

Pricing: what you really pay

The Workers Free plan costs $0 and includes 100,000 requests per day across all scripts, 10 milliseconds of CPU per invocation, up to 100 Worker scripts, and limited access to the storage products. Workers Paid costs $5 per month per account and includes 10 million requests and 30 million CPU milliseconds per month, then $0.30 per additional million requests and $0.02 per additional million CPU milliseconds. There are no bandwidth or egress charges at all. Requests that serve static assets are free and unlimited, which materially changes the math for sites that mix static and dynamic content.

Storage binds are metered separately and cheaply enough to model simply. Workers KV: 1 GB stored included with the paid plan's allowances of 10 million reads and 1 million writes per month, then $0.50 per GB-month for storage, $0.50 per million reads and $5.00 per million writes. D1 includes 5 GB of storage on the free tier and charges $0.75 per GB-month above it. Durable Objects price by requests and duration — 100,000 requests and 13,000 GB-seconds per day on the free tier, then $0.15 per million requests and $12.50 per million GB-seconds. Cloudflare's own pricing examples show a Worker serving 15 million requests at 7 ms each landing at roughly $8 per month total, and we find that example credible against the published unit rates.

Worked example worth internalizing: the free tier's 10 ms CPU ceiling is the real wall, not the request count. A 100,000-request-per-day allowance sounds small, but each request may burn 10 ms of CPU — enough for meaningful API middleware, auth checks and HTML assembly. What free-tier Workers cannot do is image processing, heavy JSON manipulation of large payloads, or anything CPU-bound. The $5 per month tier raises CPU to 5 minutes per invocation (default 30 seconds), which changes what kind of program fits.

Enterprise contracts use negotiated usage models and include the platform's SLA terms. For self-serve accounts the contractual uptime commitment follows Cloudflare's application plans — none on Free or Pro, 100 percent on Business with service credits — so production workloads that carry penalties should know what tier their account sits on.

Performance & infrastructure

The performance argument is structural. Because code runs at the same facility that terminates the user's connection, request handling latency for a global audience is bounded by the user's distance to Cloudflare, not to your origin region. No cold starts means tail latency behaves well under bursty traffic, which is where container serverless platforms degrade visibly. The runtime supports WebSockets, streaming responses, and cache APIs, so real-time and streaming patterns are possible without a persistent server.

The storage products are distributed in the same way: KV replicates globally with eventually consistent writes, Durable Objects give you a single point of coordination per object, D1 provides SQL with read replication via Hyperdrive. The design pattern the platform pushes you toward — reads from the edge, writes to a coordinating object — is genuinely effective and genuinely different from stateless-plus-database architectures. Teams new to it should prototype the state model before committing an application design to it.

Reliability follows Cloudflare's operational record: strong, publicly documented, with a concentration risk we flag in every Cloudflare review on this site. A Workers deployment has no origin to fail over to; if the platform is down, your application is down. Multi-provider redundancy for edge compute is possible in theory and rare in practice — the honest mitigation is knowing how to redeploy behind a different proxy if you ever need to.

Where it falls short

The limits are architectural, not just quotas. CPU time is metered per invocation (5 minutes maximum on paid, 15 for cron and queue consumers), which excludes long-running computation. The isolate model means no arbitrary binaries, no full POSIX environment, no long-lived background threads. Containers close part of that gap — Cloudflare now prices container usage in GiB-hours and vCPU-seconds — but that is a companion product rather than a widening of the Workers sandbox.

Vendor lock-in is the criticism we consider most legitimate. The APIs — Durable Objects, KV bindings, the wrangler deployment model, the service binding mesh between Workers — are Cloudflare-specific. Your request-handling logic is portable JavaScript; your state and topology are not. Weigh that honestly when the application outlives the enthusiasm of its first deployment.

The learning curve is real for teams whose serverless experience is Lambda-shaped. CPU-time billing instead of wall-clock billing, isolates instead of containers, eventual consistency in KV, coordination through Durable Objects: each is a small conceptual shift and together they are a new mental model. The documentation is strong — the limits and pricing pages are among the most explicit we have read — but nobody absorbs this in an afternoon.

Cost traps are narrower than on competing platforms but not absent: KV write operations at $5.00 per million make high-frequency small writes expensive, Durable Objects duration billing surprises people who hold state open, and cache-served requests still count against request allowances when Workers caching is enabled. Read the pricing page examples before guessing.

Who should pick this

Our pick in /category/serverless-platforms for latency-sensitive APIs, middleware, authentication layers, personalization and full-stack edge applications, and our default choice in /category/edge-computing for teams that want global distribution without running infrastructure. The free tier handles serious hobby and small-production workloads; $5 per month buys a production-shaped platform. For teams already on Cloudflare DNS or Pages, the bindings between products remove the glue code that usually costs the most engineering time.

We would not pick it for CPU-heavy workloads, long-running jobs, or teams that require deployment portability across clouds as a hard requirement. If that describes you, container-based serverless or a plain VPS stack reviewed elsewhere on this site is the better fit. For stateful patterns, read up on Durable Objects before designing around them — the model is powerful and unforgiving of stateless habits.

Key takeaways

• Request handlers run at 330+ data centers with no cold starts and no region selection.
• Free: 100,000 requests/day, 10 ms CPU per invocation. Paid: $5/month with 10M requests and 30M CPU ms included.
• Usage rates: $0.30 per million requests, $0.02 per million CPU milliseconds; no egress or bandwidth charges ever.
• Static asset requests are free; CPU-time billing rewards lean request handlers.
• Storage binds (KV $0.50/GB-month, D1 $0.75/GB-month above 5 GB, Durable Objects per request and duration) meter separately — model writes, not reads.
• Real lock-in is in Durable Objects and bindings, not in the JavaScript; sandbox excludes long-running and binary workloads.

Sources

• https://developers.cloudflare.com/workers/platform/pricing/
• https://developers.cloudflare.com/workers/platform/limits/
• https://www.cloudflare.com/pricing.md
• https://www.cloudflare.com/plans/developer-platform-pricing/
• https://www.cloudflare.com/en-gb/press/press-releases/2018/cloudflare-workers-opens-edge-computing-to-everyone
• https://www.cloudflare.com/plans/faq/
• https://www.cloudflare.com/network/