Agent sandbox startup: 648ms is a median, not a floor

Cloudflare rebuilt Containers for agent workloads on 30 September 2026, and agent sandbox startup dropped from a 4.049-second median to 648 milliseconds. Read the second half of that sentence before you quote the first: it is a median, it is time-to-interactive measured from the client during a burst of 100 concurrent sandboxes, and it only applies on a scheduling policy you have to opt into.

The 99th percentile is 1129ms. That is the number your users feel on a bad day, and it is the one almost no coverage of this launch printed.

What the agent sandbox startup figures actually measure

The benchmark is not Cloudflare's. It is ComputeSDK's independent Burst TTI Benchmark, which launches 100 sandboxes concurrently and measures time-to-interactive from the client. Cloudflare published the full distribution, which is more than most vendors do, and it deserves the credit:

Startup measurement	Previous scheduling path	New scheduling policy	Improvement
Median	4.049 seconds	648 milliseconds	6.2x faster
95th percentile	5.839 seconds	910 milliseconds	6.4x faster
99th percentile	6.717 seconds	1129 milliseconds	5.9x faster

Three qualifications travel with those figures. First, 648ms is a median: one sandbox in every hundred still takes over a second, and if your product fans out twenty sandboxes per task, you meet the tail on nearly every task. Second, this is not an isolated cold start measured on an idle platform — it is a 100-sandbox burst, which is a harder and more realistic test, and a fairer one. Third, it is one benchmark, by one third party, on one workload shape.

That a third party ran it is a point in Cloudflare's favour. A vendor quoting its own numbers is marketing; a vendor handing you p95 and p99 alongside the median is engineering. But a single external benchmark is still a single benchmark, and the figures only hold on the new path.

Cloudflare also ran its own preliminary burst test, in which a single account started 100,000 Containers in 5.387 seconds across six locations. That one is Cloudflare testing Cloudflare, and should be read as a capacity signal rather than a performance guarantee.

Where the speed came from: the Durable Object now does the scheduling

Previously, starting a Container meant the global control plane resolved application configuration, found capacity and coordinated placement — deployment machinery sitting in the path of an agent's first command. With the durable_object scheduling policy, demand starts at the Durable Object instead. The infrastructure looks for capacity on the same machine first, widens the search within the location, and favours hosts that already hold the image or snapshot locally so nothing has to be downloaded.

The second half of the win is on the host. Rather than booting a new virtual machine, the runtime restores a prepared one that has not been assigned yet, reusing networking and filesystem setup and skipping services the first command does not need. Neither change is exotic. Both are the same lesson we keep relearning in serverless architecture work: the fastest path is the one with the fewest coordinating parties on it.

Image and instance type are now runtime arguments rather than deploy-time configuration, so one Durable Object class can start a small Node.js sandbox and a large Python build sandbox side by side. Cloudflare also shipped cloudflare/debian-trixie, a ready-made agent image containing Debian Trixie Slim and Node.js 24.20.0 LTS, which it pre-distributes to eligible hosts so nobody waits on an unpack.

Six days earlier, Cloudflare disclosed a cross-tenant data leak in Containers

On 24 September 2026, Cloudflare published how it addressed a cross-tenant data exposure vulnerability in Containers. Oren Yomtov of Accomplish, reporting through Cloudflare's HackerOne programme, found that Containers ran device mapper thin provisioning with skip_block_zeroing enabled. A 4 KiB write into an unmapped thin block allocated a fresh 64 KiB physical block and overwrote only part of it, so the remaining 60 KiB could still hold data from a previous tenant's container.

Researchers recovered filesystem metadata, directory structures, database pages and application data, including 2,700 distinct foreign directory inodes and structurally complete SQLite databases across test placements. Cloudflare confirmed and merged fixes the day it was reported on 4 September, completed rollout by 7 September, saw the exploit stop working on 14 September, and finished clearing cached image snapshots on 19 September. It states it has no evidence customer data was compromised, and no evidence anyone else used the vector.

Put the two posts together and the picture is honest rather than alarming. Cloudflare disclosed a serious residual-data flaw in detail, fixed it in three days, then shipped a performance rebuild six days later. If you are running untrusted agent code — and that is what an agent sandbox is for — that disclosure is the more decision-relevant document of the two. It is the same lesson as the case where VM-level isolation held where container isolation did not: the boundary is only as good as the layer nobody audited.

Snapshots, the migration deadline, and what it costs to switch

Filesystem snapshots are in public beta and only work on the durable_object policy. Two limits matter in practice and are easy to miss: snapshots carry an implicit 30-day time-to-live, refreshed on each restore, with no custom TTL available yet; and a snapshot is tied to the image version it was taken from, so updating the image invalidates it.

The deprecation is the part teams will miss. Cloudflare will maintain the Container class and the legacy Sandbox class through 31 December 2026. Existing deployments keep running after that, but stop getting updates, and every new capability is native-only on ctx.container.

Switching is not a config flag. The scheduling policy is immutable on an application: to change it you create a new Container application, and deleting the old one deletes its instances. Moving means replacing every running instance. Plan it as a migration with a cutover, not an afternoon. The code change itself is small — extends Container becomes extends DurableObject, and you call this.ctx.container directly.

When this is the wrong move

If your containers are long-lived services on a single image and instance size, the default policy is still the right one, and you gain nothing from a per-instance scheduling model built for churn. The new path pays off when sandboxes are created per task, die quickly and need different environments — which is exactly the shape of work we see in agent platforms and in long-running agent sandboxes generally.

If you are still deciding how much of the environment an agent should be allowed to reach, startup time is the wrong first question. The allowlist comes before the stopwatch, and a 648ms sandbox with unrestricted outbound access is a faster way to have a bad afternoon. In the systems we build, the outbound policy and the credential handling get designed before anyone benchmarks the boot.

If you are on Containers today and not touching agent workloads, the only date you need is 31 December 2026. Put it in the calendar, confirm whether anything you run extends the Container or legacy Sandbox class, and move at a time you choose. Teams we work with on cloud and DevOps engineering lose more time to deprecations they discovered late than to the migrations themselves.