Updated: 2026-07-07

In 2017, when Cloudflare launched Workers, the pitch was almost a curiosity: run small pieces of JavaScript in the same nodes serving CDNs, with minimal latency and no servers to manage. Eight years later, that curiosity has turned into an application platform with database, object storage, queues, pub/sub, AI inference, and enterprise integrations. The question is no longer "what is this for?" but "where does it fit in my architecture?" And that question deserves a nuanced answer.

Key takeaways

  • The basic architecture hasn’t changed: V8 isolates, global deployment in seconds, cold start < 5 ms, billed per request and CPU ms.

  • D1 (distributed SQLite) left beta; R2 (S3-compatible storage with no egress fees) displaced S3 in many deployments; Durable Objects is the most powerful stateful primitive in the catalog.

  • Workers AI lets you run Llama, Mistral, Stable Diffusion and embedding models directly from a Worker, without managing GPUs.

  • The 128 MB memory limit per Worker is the ceiling most complex applications hit first.

  • The useful question isn’t whether Workers beats Lambda, but how much weight edge logic carries in your architecture.

What it offers today

The basic architecture hasn’t changed: each Worker is a function running in V8 isolates, deployed globally in seconds, cold-starting in under 5 ms, billed per request and CPU ms. That’s still the core of the product, and it’s why Workers beats Lambda in every case where cold-start latency matters.

What has changed is everything around the Worker:

  • D1 (distributed SQLite with regional replication) has left beta and is usable in production for moderate workloads.

  • R2 (S3-compatible storage with no egress fees) has displaced S3 in many deployments where outbound traffic outweighs storage.

  • Durable Objects, the strangest primitive in the catalog, is today the basis on which collaborative edits, chat rooms, and distributed-state coordinators are built.

  • Queues, Pub/Sub, and Workflows complete the puzzle for event-oriented architectures.

Workers AI is the most recent addition and probably the most commercially relevant. It lets you run a wide selection of open models (Llama, Mistral, Stable Diffusion, embedding models) directly from a Worker, with no GPU infrastructure to manage. Latency is reasonable, and the per-token pricing model is more predictable than providers that bill by GPU-hour. This connects with the local-model ecosystem covered in Llama 3.2 at the edge.

Where it fits well

The flagship case is still any workload where "close to the user" matters. API gateways, personalization logic, edge A/B testing, header rewriting, route-specific bot protection: Workers is almost unbeatable here. Latency from anywhere on the planet to a nearby Worker is tens of milliseconds, and pay-per-use billing avoids the classic problem of idle servers sitting in secondary regions.

The second case where it stands out is complete applications that fit in a Worker’s CPU and memory budget (128 MB, configurable CPU time up to 5 minutes on paid plans since March 2025). For small or mid-sized SaaS, with D1 as the database and R2 as storage, you can cover almost the whole stack without touching any other infrastructure.

The third case, which has grown a lot over the last year, is running simple AI pipelines. A Worker receives a request, calls Workers AI to generate embeddings or complete a prompt, queries Vectorize (Cloudflare’s vector database), and returns the result. The whole pipeline lives in Cloudflare’s network, with no egress. For lightweight RAG systems, this topology is hard to beat on cost and simplicity. Evaluating the quality of these RAG pipelines is the central subject of evaluating RAG systems.

Where it still doesn’t fit

Despite the growing catalog, there are cases where Workers isn’t the right pick:

  • Large in-memory state (more than 128 MB) doesn’t fit. You can split it across multiple Workers or lean on Durable Objects, but anything that needs one big, persistent process is going to struggle.

  • Libraries in languages other than JavaScript/TypeScript still have limitations. The runtime supports Rust and Python through WASM and Pyodide respectively, but the available library ecosystem is thin.

  • Relational databases with high global consistency requirements are also delicate. D1 works well for mid-sized apps, but eventual consistency across regions means it’s not a direct replacement for a multi-region Postgres with synchronous replication.

Pricing and the fine print

Cloudflare has been tuning its pricing model over the last year. The free plan remains generous for experimenting. Where it pays to pay attention is the features with separate pricing:

  • Workers AI bills per token or inference, through a "Neurons" system that unifies pricing across models (official pricing[1]).

  • R2 charges for operations even without egress (R2 pricing[2]).

  • D1 charges for rows read/written, and Cloudflare began strictly enforcing free-tier limits on February 10, 2025.

All reasonable in isolation, but you need to do the math rather than assume a single flat rate. The arrival of the Enterprise plan, with contracts and dedicated support, plus integration into corporate marketplaces (AWS Marketplace, Azure), is a clear sign Cloudflare is now having enterprise conversations it didn’t have access to before.

How to think about the decision

The useful question when evaluating Workers isn’t "is it better than Lambda?" but "how much weight does edge logic carry in my architecture?" If the answer is a lot (high-traffic public APIs, authentication logic, region-specific routes), Workers wins comfortably. If the answer is little (apps with heavy central backend processing and little edge logic), the operational cost of splitting your architecture probably doesn’t pay off.

The incremental path that strikes me as most sensible is starting with a single Worker in front of your current stack, to handle lightweight auth, cache, or rewrites. From there, move pieces to the edge as it makes technical and economic sense. Avoid redesigning everything from scratch in Workers: the platform is powerful, but its mental model is different from a traditional server’s.

What’s next

What Cloudflare signaled at its 2025 Birthday Week, where it marked its fifteenth anniversary (official wrap-up[3]), suggests the focus for the rest of the year is twofold: keep investing in Workers AI (more models, better prices, lower latency) and push Durable Objects as the go-to primitive for stateful apps. If both bets pay off, Workers will compete head-on with the Lambda+DynamoDB combo for any workload that doesn’t demand massive centralized processing.

Conclusion

Eight years after its quiet debut, Workers has stopped being a niche tool. It’s still the most elegant option for edge logic, and it’s earned the right to be on the shortlist for complete applications. It’s one of the few platforms where technical innovation and business model have evolved coherently, and that explains why teams that try Workers rarely go back.

This article is also available in Spanish: Cloudflare Workers en 2025: del edge a la empresa.

Sources

  1. official pricing
  2. R2 pricing
  3. official wrap-up
  4. Cloudflare Docs, Limits: Workers memory, CPU time and subrequests
  5. Cloudflare Changelog, Run Workers for up to 5 minutes of CPU time
  6. Cloudflare, Birthday Week 2025: updates and announcements
  7. SD Times, Cloudflare announces GA releases for D1, Hyperdrive, and Workers Analytics Engine