Cloudflare rebuilds Containers for agent sandboxes

Cloudflare has rearchitected Containers around the way agents actually use sandboxes: created on demand for a single task, expected to be ready immediately, then paused, saved and resumed. Median startup has fallen from just over four seconds to 648 milliseconds, the image and instance size for a sandbox are now chosen by application code at runtime, and native filesystem snapshots have entered public beta.

Configuration moves into the code

Containers were organised around application deployments, so an image and its compute resources were fixed at deploy time and every combination needed its own application, its own Durable Object namespace and its own wrangler deploy. A new durable_object scheduling policy turns those choices into arguments passed when the sandbox starts, so a single Durable Object class can run a small Node.js workspace and a large Python one side by side. A rollout becomes a few lines of code: canary a toolchain on a percentage of new sandboxes by hashing the Durable Object ID, pin an active project to the image it started with, or migrate a workspace at its next snapshot.

Faster first commands

The old path sent every start through Cloudflare's global control plane, which resolved the application configuration, found capacity and coordinated placement. Demand now begins at the Durable Object, which looks for capacity on its own machine first, widens the search within the same location if it has to, and favours hosts that already hold the sandbox's image or snapshot in local storage. The runtime also restores a prepared virtual machine rather than booting a new one, reuses networking and filesystem setup, and stops waiting on services the first command does not need.

ComputeSDK's independent Burst TTI benchmark, which launches 100 sandboxes concurrently and measures time to interactive from the client, records a median of 648 milliseconds against 4.049 seconds on the previous path, a 6.2x improvement. The 95th percentile falls from 5.839 seconds to 910 milliseconds, and the 99th from 6.717 seconds to 1.129 seconds. In Cloudflare's own preliminary burst test, one account started 100,000 Containers in 5.387 seconds across six locations.

A ready-made Linux image, and snapshots

A faster scheduler leaves image preparation as the largest remaining wait, so Cloudflare has published cloudflare/debian-trixie, a system image carrying Debian Trixie Slim and Node.js 24.20.0 LTS. An agent can start a Linux sandbox from it without writing a Dockerfile, building an image or pushing it to Cloudflare, then clone a repository and install packages with exec(). Filesystem snapshots are immutable and reusable, so a coding agent can save its repository, dependencies, build caches and edits when a session pauses and restore them the following day, while an evaluation harness can fork one prepared baseline into many identical environments in which only the variable under test changes.

The Container class is on the way out

Cloudflare is making the Durable Object explicit. The durable_object policy, the faster startup path, runtime image and instance selection and snapshots exist only on ctx.container. The Container class and the legacy Sandbox class are being maintained through 31 December 2026, after which existing deployments keep running without further updates. Sandbox SDK 1.0 becomes a set of helpers that work inside your own Durable Object class rather than a base class to inherit, and @cloudflare/computer combines Dynamic Workers and Containers with a synchronised filesystem for teams that want a higher-level abstraction.

Our opinion

Startups measured in milliseconds matter less for the number than for what they remove: the reason to keep a pool of warm idle machines, and the bill that comes with that pool. The real argument here is architectural. Put the agent's memory and credentials in the Durable Object, put the untrusted shell in the Container, and let the two be stopped independently, which is a cleaner answer to where an agent lives than either extreme. It also explains why a company that once hid its Durable Objects behind a friendly wrapper is now handing them straight to developers. The migration deadline deserves a raised eyebrow, though: eighteen months of maintenance for a class that thousands of deployments inherit is a short runway, and no updates after 31 December 2026 is a polite way of saying rewrite it.