Cloudflare rebuilds Containers for agents: startup is 6x faster

Cloudflare has reworked the Containers infrastructure for the load that AI agents generate: sandboxes appear on demand, one per task, and must be ready instantly. In the independent ComputeSDK benchmark, median startup time fell from 4.049 seconds to 648 milliseconds (6.2x faster). In the company's own trial test, a single account launched 100,000 containers in 5.387 seconds across six locations. Alongside this, Cloudflare released image and resource selection directly from code, plus filesystem snapshots in public beta.

Code picks the image and hardware, not the deployment

Previously, Containers were built around the application: the image and compute resources were set at deploy time and rolled out centrally. That is awkward for an agent sandbox. It needs different tools, resource sizes, and starter files depending on the task, and it may live for minutes, sleep between requests, or be restored several days later.

The old model required a separate application for every combination of image and instance type, with its own Durable Objects namespace and routing in a Worker. A small Node.js sandbox and a large Python build environment meant two deployments. The new `durable_object` scheduling policy turns this into an `if` condition: the wrangler configuration declares the available images (for example, node and python), and at startup the Durable Object passes `ctx.container.start()` the image, the instance type (say, standard-1 or standard-2), and an internet-access flag. A new environment now comes from a code change, not a new deployment.

The same applies to rolling out updates. Grace periods, percentage splits, and configuration API calls go away: a container keeps running on the image it started with until the code stops it, and the next launch uses whichever image the code selects. This makes possible a canary rollout to 5% of new sandboxes based on a hash of the Durable Object ID, pinning active projects to their current image, migrating at a checkpoint, and rolling back by simply changing the image for future launches.

Why the first command runs faster

Previously, a container launch went through a global control plane: it parsed the application configuration, looked for capacity, and coordinated placement. Now demand originates at the Durable Object level. The infrastructure first looks for room on the same machine, then widens the search within the location, and prioritizes hosts where the image or snapshot is already stored locally.

Cloudflare also trimmed the work after a container lands on a host. Instead of booting a virtual machine from scratch, the runtime restores a pre-prepared unassigned VM, reuses network and filesystem setup, batches repeated operations, and does not wait for services that the first command doesn't need. Results of the Burst TTI benchmark (100 concurrent sandboxes, measured on the client side):

• median: 4.049 s → 648 ms (6.2x faster); • 95th percentile: 5.839 s → 910 ms (6.4x); • 99th percentile: 6.717 s → 1129 ms (5.9x).

Separately, Cloudflare released the `cloudflare/debian-trixie` image with Debian Trixie Slim and Node.js 24.20.0 LTS. An agent can start a Linux sandbox without a Dockerfile, a build, or an image push, then use `exec()` to clone a repository and install packages. Because Cloudflare controls the image itself, it distributes it to suitable hosts in advance, so nothing is downloaded or unpacked at launch.

Snapshots: save the workspace and come back to it

Even a fast start doesn't eliminate setup: cloning, installing dependencies, and configuring the toolchain often take longer than launching the container itself. For this, native filesystem snapshots have entered public beta. The `snapshotContainer()` method saves the workspace, and `start()` with the `containerSnapshot` parameter restores it.

Snapshots are immutable and reusable, so they work in two scenarios. First, a single workspace continues across sessions. A coding agent saves the repository, dependencies, build caches, and edits when the user leaves, and brings them back the next day. Second, a shared checkpoint for many sandboxes. This is handy for agent evaluation, where one task is run with different system prompts, skills, models, or agent versions while everything else must stay the same. A single snapshot launches many isolated environments with an identical base and removes environment drift from the results. Chaining works too: an agent starts from debian-trixie, configures the environment via `exec()`, and saves the result as a snapshot.

Who this is for

The use cases the platform was rebuilt for: coding agents with repositories, package managers, compilers, and dev servers; evals with a known starting state; reinforcement learning systems that create, evaluate, and reset large numbers of environments; and long-running tasks that need to persist files.

Base44 (an isolated development environment with live preview for each app) and Kilo Code (a separate environment for each cloud agent session) already build their products on Containers. Integrations exist with Cursor Cloud Agents, Devin Outposts, OpenAI Agents API, and Claude Managed Agents. The model is also being carried over to Sandbox SDK 1.0, and the native `ctx.container` API is gaining more capabilities so that a Durable Object can manage a container without a wrapper class.

The practical takeaway for teams building agent products: if you maintain separate applications for each stack, you can collapse them into a single Durable Object class that picks the image at runtime. For evals and RL, it makes sense to build a reference snapshot and launch parallel runs from it. For long-lived sessions, the pairing of "snapshot on pause, restore on return" fits well. The 100,000-container figure is preliminary, so it's better to test real load against your own profile.