Cloudflare raises the stateful Dynamic Worker concurrency ceiling from four to ten

Cloudflare increased the concurrency limit for Dynamic Workers used from a Durable Object from four distinct in-flight workers to ten. A Durable Object shares one input/output context across all concurrent requests to that object, so the ten-worker limit applies collectively to that stateful supervisor. Multiple simultaneous requests to the same Dynamic Worker count as one distinct worker. The ordinary Worker-request limit remains four. Dynamic Workers are Cloudflare's low-level primitive for creating arbitrary Worker code at runtime and are explicitly positioned for AI-agent code execution, generated applications, custom automation and multi-tenant platforms.

For most Cloudflare Workers applications, this limit is irrelevant. For builders using a Durable Object as a stateful supervisor around Dynamic Workers, however, four distinct active sandboxes could become an architectural boundary quickly: additional workloads required queuing, consolidating work into fewer runtimes or sharding state across more supervisors. Raising the ceiling to ten increases the amount of parallel isolated code one stateful coordinator can manage by 2.5× without changing the application-level state model. It does not remove other limits such as subrequests, CPU or outgoing connections, so teams should treat it as targeted concurrency headroom rather than a universal scaling increase.

Cloudflare distinguishes Dynamic Workers started from an ordinary Worker request from those coordinated inside a Durable Object. A regular request still has a limit of four distinct Dynamic Workers with in-flight requests. A Durable Object shares its I/O context across concurrent requests, and that shared context can now have ten distinct Dynamic Workers in flight.

The limit counts distinct Dynamic Workers, not raw request count. Multiple in-flight requests to the same Dynamic Worker count as a single entry toward the ceiling. That makes the increase particularly useful for supervisors coordinating multiple isolated tenants, code bundles or agent runtimes rather than simply increasing traffic to one sandbox.

A platform that previously needed more than four simultaneously active runtime identities under one Durable Object could have to queue work or split supervision across additional objects. The ten-worker ceiling gives that stateful coordinator more parallelism before it reaches the same design pressure, which can simplify session ownership and shared-state logic for agent or generated-application platforms.

Cloudflare lets the supervising application define a Dynamic Worker's code, bindings, network access and custom CPU/subrequest limits. The higher concurrency ceiling does not broaden what each sandbox is allowed to do; it only increases how many distinct sandboxes a Durable Object can have active concurrently.

Dynamic Workers still execute inside the wider Workers/Durable Objects resource model. Subrequest limits, CPU limits, memory, network connections and application-level contention can become bottlenecks before the new ten-worker ceiling. Teams should load-test completed tasks rather than multiplying a four-worker throughput estimate by 2.5.