Cloudflare Workers in 2025: from edge to enterprise

Actualizado: 2026-05-03

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 “is it better than Lambda?” but “how much weight does edge logic carry in my 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.

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.

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.

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). For small or mid-sized SaaS, with D1 as the database and R2 as storage, you can cover almost the whole stack.

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.

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.
• Libraries in languages other than JavaScript/TypeScript still have limitations.
• 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

What deserves attention are the “advanced” features with separate prices: Workers AI bills per token or inference, R2 charges for operations even without egress, and D1 charges for rows read/written. All reasonable in isolation, but you need to do the math rather than assume a single flat rate.

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.

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.