Cloudflare Containers, rebuilt to scale agent sandboxes
- ID
- 30286
- Status
- summarized
- Published
- 30 Sep 2026, 8:58 PM
- Fetched
- 30 Sep 2026, 9:59 PM
- Provider
- Cloudflare Blog
- Category
- infrastructure
- Original URL
- https://blog.cloudflare.com/faster-agent-sandboxes/
- Source URL
- https://blog.cloudflare.com/rss/
Summary
- Score
- 6.5
- Created
- 30 Sep 2026, 10:00 PM
- Tags
- Audience
- developersvibe_codersai_agent_userssaas_founders
What happened
Cloudflare rearchitected Cloudflare Containers around agent workloads: application code can now pick each sandbox's image and instance type at runtime rather than at deploy time, startup is claimed 6x faster, and filesystem snapshots entered public beta. In ComputeSDK's independent benchmark, median container startup dropped from just over four seconds to 648 milliseconds; Cloudflare's own preliminary burst test created hundreds of thousands of containers in seconds. Every container still gets its own Durable Object, the ctx.container API now controls a container without a wrapper class, and the model carries into Sandbox SDK 1.0.
Why it matters
If you run agent sandboxes — self-hosted or on a competitor — the 4s-to-648ms median startup number is the one to test against your own cold-start budget, because per-task image selection means you no longer pre-bake one image for a whole deployment. Filesystem snapshots in public beta are the piece that makes pause-and-resume viable, but it's beta, so treat it as a design option rather than a guarantee. The post names no pricing, region, or Malaysia-specific detail, so anyone building here still has to verify cost and latency from where their users are.
Discussion angle
The 648ms figure comes from ComputeSDK's independent benchmark while the '6x faster' and 'hundreds of thousands of containers in seconds' claims are Cloudflare's own preliminary tests — worth discussing which numbers you'd trust for capacity planning, and whether per-task image selection actually beats keeping a warm pool.