Cloudflare rebuilds Containers for agent sandboxes, with 6x faster starts

Built for sandboxes created on demand

Cloudflare says agents do not deploy sandboxes ahead of time. They create them for each task, expect them to be ready immediately, and need to pause and resume them. Until now, Cloudflare Containers was organized around application deployments, where an image and compute resources are chosen at deploy time and rolled out across the application.

An agent workspace works differently, the company argues. The task determines its image, resources, tools and starting filesystem, and the workspace might exist for a few minutes, sleep between requests or be restored days later. Cloudflare cites Base44 (app-building workspaces) and Kilo Code (cloud-agent sessions) as examples of this pattern, and mentions integrations with Cursor Cloud Agents, Devin Outposts, the OpenAI Agents API and Claude Managed Agents.

Different workloads ask different things of a workspace. Coding agents need repositories, package managers, compilers, test runners and development servers. Evals need sandboxes that begin from a known state. Reinforcement learning systems need to create, grade and reset large numbers of environments. Longer tasks need to keep the files an agent produces so work can continue later.

Image and instance type chosen in code

Every Cloudflare Container has always been attached to its own Durable Object, which gives the environment a stable identity and lets application code control when it starts, sleeps and stops. Previously, though, the image and the amount of compute were fixed at deploy time. Each combination of image and instance type was a separate Containers application with its own Durable Object namespace, set up with wrangler deploy.

Under the old approach, one agent needing a small Node.js sandbox and another needing a large Python sandbox for builds meant two applications, two namespaces and routing logic in a Worker. The new durable_object scheduling policy changes this. Developers declare the images a Durable Object can choose from, each available as this.ctx.container.images.<name>, and pass the image and instance type as arguments when the sandbox starts. According to Cloudflare, adding a new environment becomes a code change rather than a new deployment.

Rollouts also move into code. With this policy there is no rollout configuration: a Container keeps running the image it started with until the code stops it, and the next start uses whatever image the code selects. Cloudflare lists several strategies this allows:

• Canary a new toolchain on 5% of new sandboxes by hashing the Durable Object ID.
• Pin active projects to their current image so an agent's environment is never swapped mid-task.
• Migrate a workspace at a natural checkpoint, such as the next session or after a snapshot.
• Roll back by changing which image future starts choose, with no config push and no waiting for a drain.

A shorter path to the first command

Previously, starting a Container required Cloudflare's global control plane to resolve the application configuration, find capacity and coordinate placement. Cloudflare says that put deployment machinery in the path of an agent's first command.

With the new policy, demand begins at the Durable Object. The infrastructure looks for capacity on the same machine first, then widens the search within the same location. It also favors hosts that already hold the Container's image or snapshot in local storage, so nothing needs to be downloaded first.

Work after the Container reaches a host was cut as well. Instead of booting a new virtual machine from scratch, the runtime restores a prepared virtual machine that is not yet assigned. It reuses networking and filesystem setup, batches repeated operations and no longer waits on services the first command does not need.

In ComputeSDK's independent benchmark, median startup fell from just over four seconds to 648 milliseconds, according to Cloudflare. The company also says its own preliminary burst testing successfully created hundreds of thousands of containers in seconds.

What it means for developers

Cloudflare is also bringing more capabilities to the native ctx.container API, so a Durable Object can control its Container without a wrapper class, and is carrying this model into Sandbox SDK 1.0. The company positions Containers as a complement to Workers, Dynamic Workers and Durable Objects when agents need a full Linux workspace.

For teams building agent products, the practical change is that environment choice, sizing and rollout policy now sit in the same code that handles each task, while snapshots in public beta allow workspaces to be saved and restored. Customers quoted by Cloudflare, Base44 and Kilo Code, say they use Containers to give each app or agent session an isolated environment on demand.