Cloudflare Containers Agent Sandbox Architecture Diagram: Durable Object Scheduling Policy

On September 30, 2026, Cloudflare described a rearchitecture of Containers for agent sandboxes. This Cloudflare Containers durable_object scheduling architecture diagram is a news diagram of that post and the matching changelog, not a service-level guarantee. A Durable Object picks the container image and instance size when the sandbox starts, and filesystem snapshots (public beta) pause and resume the workspace. The post also publishes one startup benchmark. This diagram does not treat that table as a speedup factor. Facts follow the Cloudflare blog and the September 30 changelog.

What this Cloudflare Containers durable_object scheduling architecture diagram shows

The Durable Object is the controller that already sits next to every Container. Under the new durable_object scheduling policy, that object chooses image and instance at start time through ctx.container.start, instead of locking both at wrangler deploy. From the running container, a snapshot is saved into Durable Object storage, and a later start passes containerSnapshot. A faded deploy-time application path (one image, one instance type, one namespace) sits beside that runtime choice. The policy and filesystem snapshots are public beta, which is how Cloudflare labels them, not generally available service levels.

The problem this architecture is solving

Cloudflare says Containers used to be organized around application deployments: you chose image and compute at deploy time and rolled that configuration out centrally. An agent workspace is different. It is created while the agent is working, the task picks image, resources, tools, and starting filesystem, and it may live for minutes, sleep, or return days later. Coding agents need repos and toolchains. Evals need a known starting state. Longer tasks need the files the agent already produced. Putting a global control-plane lookup on the path to the first command is what the post says the new scheduler removes.

Main components and trust boundaries

Every Container stays attached to its own Durable Object: the post’s persistent controller for lifecycle and outbound traffic. The container is the Linux workspace. The Durable Object keeps identity, state, policy, and lifecycle, so the agent can live on either side of that line. The post points at Anthropic’s “decoupling the brain from the hands” pattern for that split. Dynamic Workers are a lighter option beside it, not a substitute for the container.

The policy is opt-in. Wrangler sets scheduling_policy to durable_object and names images, exposed as ctx.container.images. start takes that image, an instance size, and enableInternet. Blog samples use standard-1 and standard-2; the changelog sample uses standard-2 with internet disabled. Those are examples, not a fixed catalog. A container keeps the image it started with until your code stops it. The changelog says these instances do not participate in application-wide image rollouts. Pinning an image in storage or canarying on the Durable Object id are code patterns in the blog, not a managed rollout product. cloudflare/debian-trixie is Debian Trixie Slim plus Node.js 24.20.0 LTS, startable without a named image. The blog’s sample entrypoint is /bin/sleep infinity, then exec() configures the guest. Cloudflare says it can pre-place that image because it controls it. That is not a cold-start measurement for your Dockerfile.

Request or data path, step by step

A task hits the Durable Object. The sample returns if ctx.container.running is already true. Otherwise it picks image and instance and calls start. Capacity is sought on the same machine first, then in the same location, preferring a host that already has the image or snapshot. The runtime restores a prepared virtual machine, reuses network and filesystem setup, and skips services the first command does not need. The old path, which the post contrasts, asked a global control plane to resolve config and placement, then booted a VM from scratch.

The same post includes ComputeSDK’s Burst TTI Benchmark: 100 concurrent sandboxes, time-to-interactive from the client. The median on the new path is 648 milliseconds, against 4.049 seconds on the previous path. That is one published benchmark, not a service-level objective, and this diagram does not label a speedup factor. Cloudflare also reports a preliminary burst test of 100,000 containers in 5.387 seconds across six locations. They mark it preliminary. It is not a quota.

snapshotContainer returns a snapshot the sample stores on the Durable Object. A later start passes containerSnapshot. Snapshots are immutable and reusable, so many containers can fork one checkpoint. The post names two uses: resume one workspace, or share a baseline for evals. Linux compute can stop while the object still holds the snapshot.

The diagram: labeled boxes and failure or isolation edges

Boxes: Worker or agent, Durable Object, ctx.container.start(image, instance), isolated Linux, snapshot in Durable Object storage, restore into start. Deploy-time config sits off the hot path. The isolation edge is the container. Outbound policy stays on the Durable Object. The container can sleep or crash while the object keeps state. A snapshot restores files, not a live process. The old global control plane is not on this start path.

What the source does not claim

Both sources are a September 30, 2026 announcement. The scheduling policy is public beta, and filesystem snapshots are public beta. Neither source calls them generally available. Base44 and Kilo Code are customer quotes in the blog, not independent benchmarks. Named integrations are listed without a diagram you could copy. The Container class and legacy Sandbox class are maintained through December 31, 2026; deployments keep running after that, but those classes get no further updates. Sandbox SDK 1.0 is utilities inside your Durable Object, not a base class. The 648 millisecond median and the burst figure are the tests above, not a latency or scale commitment.

FAQ

What does the durable_object scheduling policy change?

The September 30, 2026 changelog says the policy lets a Durable Object select the container image and instance size at runtime instead of one centrally managed configuration for the application. Wrangler declares the named images. ctx.container.start receives that image reference and an instance size. Those instances have independent lifecycles and do not participate in application-wide image rollouts.

Are the new scheduling policy and filesystem snapshots generally available?

No. The blog says the durable_object scheduling policy is available in public beta, and it calls filesystem snapshots public beta. Neither the blog nor the changelog calls them generally available. The Container class and the legacy Sandbox class are maintained through December 31, 2026, and existing deployments keep running after that date, but those classes will not get updates.

Does a filesystem snapshot restore a running process?

The blog describes snapshots as a way to save the workspace filesystem and start a later container from that snapshot. They are immutable and reusable. The post does not say a snapshot keeps a live process, memory, or an in-flight command. Compute can stop while the Durable Object still stores the snapshot reference.

Conclusion

The September 30, 2026 change, as published, is a Worker or agent, a Durable Object controller, ctx.container.start with image and instance chosen at runtime, an isolated Linux container, and a public-beta filesystem snapshot for pause and resume. Deploy-time configuration stays off to the side. No speed multiplier is shown. The Cloudflare blog and the changelog are the sources. More architecture diagrams are on the ByteDiagram blog.