Cloudflare rebuilds Containers for on-demand agent sandboxes with 6x faster startup

Cloudflare has rebuilt its Containers service around the way AI agents consume compute: a sandbox is created while a task is already running, exists for exactly as long as the job needs, and is configured by the agent's own code rather than by a deployment pipeline. According to the Cloudflare blog, the rework introduces a scheduling policy that lets applications pick each sandbox's image and instance type at runtime, cuts container startup by more than six times, and brings filesystem snapshots to public beta.

Runtime decisions move into code

Containers was previously organized around application deployments: an image and a compute allocation were fixed at deploy time and applied across the whole application, with configuration managed per application rather than per instance. Agents break that model, Cloudflare argues, because a workspace is created on demand in the middle of a task and may live for a few minutes, sleep between requests, or be restored days later, with the image, resources, tools and starting filesystem all determined by the task at hand.

Under the new durable_object scheduling policy, image and instance type become arguments the code passes when the sandbox starts. Before, every image-and-instance combination required its own Containers application and Durable Object namespace provisioned ahead of time with wrangler deploy, so running a small Node.js sandbox alongside a large Python build sandbox meant two applications plus routing logic in a Worker. Cloudflare frames the replacement as essentially an if statement inside a Durable Object: one class can start differently sized Node and Python environments side by side, and adding a new environment becomes a code change rather than another deployment.

The design leans on a trait Cloudflare says has always defined the product: every container instance is attached to its own Durable Object, a persistent, programmable controller running next to it that manages its lifecycle and outbound traffic. More capabilities are being moved into the native ctx.container API so the Durable Object can drive its container without a wrapper class in between, and the same model is being carried into Sandbox SDK 1.0.

Faster starts and snapshot support

Speed is central to the redesign, since agents launch sandboxes while a user is already waiting on a result. In an independent ComputeSDK benchmark cited in the post, median startup dropped from just over four seconds to 648 milliseconds. In Cloudflare's own preliminary burst tests, hundreds of thousands of containers were created in seconds. Filesystem snapshots, now in public beta, allow a workspace to be saved and later restored, which covers long-running tasks where the files an agent produces need to survive between sessions.

Rollouts become application logic

Deferring image selection to start time also removes rollout configuration entirely. A container keeps the image it launched with until the code stops it; the next time that Durable Object starts a container, it uses whatever image the code chooses. Rollout strategy therefore collapses into a few lines next to the rest of the application logic: canary a new toolchain to a slice of new sandboxes by hashing the Durable Object ID, pin active projects to their current image so an agent never has its environment swapped mid-task, migrate a workspace at a natural checkpoint such as the next session or after a snapshot, and roll back by changing which image future starts select — all without pushing configuration or waiting for running instances to drain.

Adoption and workloads

Cloudflare points to existing demand for this pattern: Base44 gives each user-built app an isolated development environment where its AI can run commands and install dependencies, and Kilo Code uses containers for cloud-agent sessions, alongside integrations with Cursor Cloud Agents, Devin Outposts, the OpenAI Agents API and Claude Managed Agents. Different agent workloads stress different needs — coding agents want repositories, package managers, compilers and development servers; evaluation harnesses want sandboxes that begin from a known state; reinforcement learning systems want to create, grade and reset large numbers of environments quickly.

Why it matters

The shift mirrors a broader change in how agent workloads treat infrastructure: compute is no longer a standing deployment but an ephemeral, task-shaped resource provisioned at request time. Moving image and instance selection into code turns what used to be an operations problem — separate applications, namespaces and rollout policies — into ordinary application logic, while sub-second startup makes per-task sandbox creation cheap enough that agents no longer need to pool or pre-warm environments. For teams building on Cloudflare, Containers now slots in as the full Linux workspace alongside Workers, Dynamic Workers and Durable Objects, and the rework is a clear signal of where agent infrastructure is heading: the runtime environment itself becomes just another decision the code makes.