Cloudflare Containers now start agent sandboxes in 648 milliseconds and let code pick the image at runtime

A coding agent that opens a fresh Linux workspace for every task used to wait more than four seconds for it. Cloudflare said on 30 September it has rebuilt Containers around that wait and cut it to a median of 648 milliseconds, and now lets the application code choose each sandbox's image and instance type when the task starts instead of at deploy time.

The changes are announced in a post by Thomas Gauvin, Rushil Mehra, Gabi Villalonga Simón and Thomas Lefebvre on the Cloudflare blog. There are three parts: a new durable_object scheduling policy, a faster start path, and filesystem snapshots in public beta so a workspace can be saved and returned to later.

The measured speed-up

Cloudflare cites ComputeSDK's independent Burst TTI Benchmark, which launches 100 sandboxes at once and measures time to interactive from the client. Median start fell from 4.049 seconds under the previous path to 648 milliseconds, a 6.2x change. At the 95th percentile the drop was 5.839 seconds to 910 milliseconds, and at the 99th percentile 6.717 seconds to 1.129 seconds. Cloudflare says its own preliminary burst test started 100,000 Containers from one account in 5.387 seconds across six locations.

Two design changes get the numbers there. The scheduler now looks for capacity on the same machine as the Durable Object first, and favours hosts that already have the image or snapshot on disk. The runtime restores a prepared virtual machine that has not yet been assigned, reuses networking and filesystem setup, and skips services the first command does not need.

Choosing the image from application code

Before, each combination of image and instance type was its own Containers application. Two sandboxes with different toolchains meant two applications, two Durable Object namespaces, and routing logic in the Worker to send each task to the right one.

With the new scheduling policy the image and instance type are arguments a Durable Object passes when it starts a Container. Cloudflare's example declares a node and a python image in wrangler.jsonc, then picks one at request time based on the task and chooses a standard-1 or standard-2 instance based on whether the workload is a build. Adding a new environment is a code change, not a new deployment. Rollouts move into that code too: a Container keeps its current image until the code stops it, and the next start uses whatever image the code picks.

A prepared image and saved workspaces

Preparing the image is now a larger share of the remaining wait, so Cloudflare has published cloudflare/debian-trixie, a ready system image with Debian Trixie Slim and Node.js 24.20.0 LTS. Because Cloudflare controls it, the image can be distributed to eligible hosts before requests arrive, so an agent starting a fresh Linux sandbox does not wait for the base image to download and unpack.

Filesystem snapshots enter public beta in the same release, so a workspace can be saved after setup and restored later. Cited customers include Base44 for app-building workspaces and Kilo Code for cloud-agent sessions, and Cloudflare names its own product integrations with Cursor Cloud Agents, Devin Outposts, the OpenAI Agents API and Claude Managed Agents.

The benchmark is Cloudflare's chosen third-party number and the burst figures are its own preliminary tests, so the honest read is what a team can measure against its own workload. What has changed is that the choice a team was making at deploy time now belongs to the request that needs the sandbox, and the wait for the first command is short enough to run many small tasks in parallel where start cost used to price that out.

Source

• Cloudflare Containers, rebuilt to scale agent sandboxes, Cloudflare blog, 30 September 2026.