Cloudflare Containers now 6x faster for agent workloads

What happened

Cloudflare announced major updates to Containers designed for agent workloads. The platform rearchitected its Containers infrastructure to support on-demand sandbox creation with runtime configuration, much faster startup times, and native filesystem snapshots in public beta. These changes allow agents to create, pause, and resume sandboxes for individual tasks without pre-deployment configuration.

What changed

The new durable_object scheduling policy removes the requirement to choose image and instance type at deploy time. Instead, code running in a Durable Object can select the image and compute resources when each sandbox starts. This eliminates the need for separate applications and deployments for different environments. Developers declare the available images in wrangler.jsonc and reference them by name in code, deciding which to use based on task requirements.

Startup performance improved substantially across all percentiles. According to ComputeSDK's independent Burst TTI Benchmark, which measures time-to-interactive from the client when launching 100 sandboxes concurrently, median startup fell from 4.049 seconds to 648 milliseconds. The 95th percentile improved from 5.839 to 910 milliseconds, and the 99th percentile from 6.717 to 1129 milliseconds. In internal burst testing, a single account started 100,000 containers in 5.387 seconds across six locations.

The infrastructure changes include a new scheduling approach that begins demand at the Durable Object level, searches for capacity on the same machine first, and favors hosts with the container image or snapshot already in local storage. The runtime was redesigned to restore a prepared virtual machine instead of booting from scratch, reusing networking and filesystem setup and deferring non-essential service startup.

Cloudflare introduced cloudflare/debian-trixie, a pre-built system image containing Debian Trixie Slim and Node.js 24.20.0 LTS. This allows agents to start a Linux sandbox immediately without creating, building, or pushing a custom Dockerfile. The platform distributes this image across eligible hosts before requests arrive, eliminating download and unpack delays.

{
"containers" : [
{
"class_name" : "AgentSandbox" ,
"scheduling_policy" : "durable_object" ,
"images" : {
"node" : { "dockerfile" : "./images/node/Dockerfile" },
"python" : { "dockerfile" : "./images/python/Dockerfile" }
}
}
],
"durable_objects" : {
"bindings" : [{ "name" : "SANDBOX" , "class_name" : "AgentSandbox" }]
}
}

Who it affects

These changes primarily benefit developers building agent applications that create sandboxes on demand for individual tasks. Agents that need isolated Linux workspaces—such as coding agents, evaluation systems, reinforcement learning environments, and cloud-agent sessions—can now provision and start containers faster and with more granular control. The improvements also apply to integrations with Cursor Cloud Agents, Devin Outposts, the OpenAI Agents API, and Claude Managed Agents, as well as platforms like Base44 and Kilo Code that provide agent-driven development or coding workspaces.

Why it matters

For agents, sandbox startup latency directly affects user experience. Every second of setup time is a second the user waits. By cutting startup from 4 seconds to 648 milliseconds, Cloudflare reduces idle time significantly. The runtime configuration model also simplifies infrastructure management. Previously, running different sandboxes with different images or compute sizes required multiple applications, namespaces, and deployments. Now, a single Durable Object class can start different environments based on code logic, making configuration changes as simple as updating application code rather than redeploying infrastructure.

Filesystem snapshots address another source of latency: workspace setup. For long-running or multi-session agent tasks, repeating environment setup (cloning repositories, installing dependencies, configuring toolchains) wastes time and can cause environment drift in evaluations. Snapshots let agents save prepared environments and reuse them across multiple sessions or tasks, maintaining consistency and reducing per-session overhead.

How to use it

To opt in, set the scheduling_policy to durable_object in wrangler.jsonc and declare the images your Durable Object can choose from. Within the Durable Object class, access the images via this.ctx.container.images.<name> and pass the selected image and instance type to this.ctx.container.start(). The durable_object scheduling policy gives the Durable Object direct control over rollouts: instead of pushing configuration changes, code can choose which image version to use on the next start. This enables canary rollouts by hashing the Durable Object ID, pinning active projects to their current image, or rolling back by changing which image future starts choose.

For agents that need a base Linux environment without a custom image, start a container with the cloudflare/debian-trixie system image and configure the environment at runtime using exec(). To save workspace state for later resumption, call this.ctx.container.snapshotContainer() with a name, store the snapshot, and pass containerSnapshot to this.ctx.container.start() on restore. Snapshots are immutable and reusable, so multiple containers can start independently from the same snapshot, which is useful for agent evaluations that need to compare results from different system prompts or models while keeping the environment fixed.

Source

AI-assisted, verified against the source. This post was drafted with AI from the primary source linked above and checked automatically against it. For anything you depend on, read the original.