← Back to blog
AI Agents Automation

Cloudflare Containers: 648ms starts, and a one-way scheduling change

· 3 min read

On September 30, 2026, Cloudflare rebuilt Containers for agent sandboxes. The change that matters is not the headline millisecond. It is that image and instance size move out of Wrangler and into Durable Object code, and you cannot switch an existing Container application onto that policy.

648 milliseconds is a vendor-cited median. The migration is a new app and a new namespace.

What shipped

The durable_object scheduling policy is in public beta. On the default policy, every instance shares one image and one size, and Cloudflare rolls configuration changes across the application. On the new policy, ctx.container.start() picks the image and instance when the sandbox starts. Cloudflare’s docs say that is the fit for sandboxes and agent environments that need a different toolchain per task.

{
  "containers": [
    {
      "class_name": "AgentSandbox",
      "scheduling_policy": "durable_object",
      "images": {
        "node": { "dockerfile": "./images/node/Dockerfile" }
      }
    }
  ]
}

Named images show up as this.ctx.container.images.<name>. There is also a Cloudflare-managed image, cloudflare/debian-trixie, with Node.js 24.20.0 LTS on Debian Trixie slim, so a common sandbox does not need a Dockerfile first. New capabilities — this policy, the faster start path, runtime image selection, and filesystem snapshots — are available through ctx.container, not the older Container class.

Sandbox SDK 1.0 becomes helpers that sit inside your own Durable Object. Cloudflare says it will maintain the Container class and the legacy Sandbox class through December 31, 2026. Existing deployments keep running after that date. Those classes stop receiving updates.

The start-time number

Cloudflare cites ComputeSDK’s Burst TTI benchmark, which launches 100 sandboxes and measures time-to-interactive from the client. Their table:

  • Median: 4.049 seconds down to 648 milliseconds (6.2×).
  • p95: 5.839 seconds down to 910 milliseconds.
  • p99: 6.717 seconds down to 1,129 milliseconds.

Cloudflare attributes the drop to starting from a prepared, unassigned virtual machine, preferring hosts that already have the image, and skipping work the first command does not need. They also report a preliminary internal burst of 100,000 Containers in 5.387 seconds across six locations. That second figure is Cloudflare’s own test, not the ComputeSDK run. Measure your workload before you put 648ms in an SLO.

Snapshots save the disk

Filesystem snapshots are public beta, and only on the durable_object policy. snapshotContainer() captures the container filesystem. Cloudflare’s docs are explicit: a snapshot does not include memory or running processes, and it is tied to the image version it was created from.

Limits: maximum snapshot size is 20 GB. Retention is 30 days from creation or from the most recent restore. A restore refreshes that TTL. You cannot set a custom TTL yet.

That is a prepared workspace — repo, dependencies, files — not a paused process with RAM intact. If your agent needs an in-memory interpreter to survive a pause, this beta does not do that.

The migration is a cutover

The migration guide says you cannot change the scheduling policy of an existing Container application. You create a replacement application and a new Durable Object class and namespace. The old and new applications cannot share a namespace. A class that extends Container has to be rebuilt on the Durable Object Container API.

Monday

  • Pilot in a new namespace. Do not plan a rollback of scheduling_policy on the app you already have.
  • Time your own first command. The 648ms median is ComputeSDK’s Burst TTI number for this path.
  • Use snapshots for files you want back. Do not use them as process hibernation.
  • Keep the legacy class only as a runway through December 31, 2026, not as the API that gets the new features.

Sources

← Back to blog