Build1 publisher2 min readPublished
Cloudflare moves Container image and size choices from deploy time into application code
Cloudflare rebuilt Containers so code picks each sandbox's image and instance type at runtime, with median startup cut to 648ms in a ComputeSDK benchmark. A fresh Linux workspace per agent task becomes quick enough to wait for, on a figure Cloudflare itself reports.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Filesystem snapshots are in public beta, so an agent's workspace can be saved and restored later.
- Cloudflare's own preliminary burst tests created hundreds of thousands of containers in seconds.
- Cloudflare says the same on-demand pattern shows up in its integrations with Cursor Cloud Agents, Devin Outposts, the OpenAI Agents API and Claude Managed Agents.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Teams that ship one large image to cover every task can now choose a narrower image per task inside the Durable Object, and have to decide whether maintaining that split is worth it.
- capability Eval and reinforcement-learning jobs that must start many environments from a known state, then grade and reset them, get a native save-and-restore path while snapshots are in beta.
- cost Image and size choices leave the central deploy-time rollout, so testing and rolling back a bad image becomes work inside per-task application code.
Until this release, a Cloudflare Container was configured per application. The image and compute resources were chosen at deploy time, rolled out across the application and managed centrally [2]. Cloudflare argues that agent workspaces break that model. The task decides the image, resources, tools and starting filesystem, and the workspace may last a few minutes, sleep between requests, or be restored days later [3].
The rebuild reuses a part Containers already had. Every Container gets its own Durable Object, a persistent controller running next to it that manages its lifecycle and outbound traffic [4]. That object already gave each environment a stable identity and let application code decide when it started, slept and stopped [5]. Under the new policy it also picks the image and the instance type [1]. I think that is the right home for the choice. The object serving the task already knows what the task is. Cloudflare is also extending the native ctx.container API so the Durable Object can control its Container without a wrapper class in between, and it is carrying that model into Sandbox SDK 1.0 [6].
The startup figure needs more care. According to Cloudflare, ComputeSDK's independent benchmark measured median startup falling from just over four seconds to 648 milliseconds [7]. That is a speedup of about 6.2 times, or roughly 3.35 seconds saved per start [1]. It matches Cloudflare's own claim of more than 6x [8]. Cloudflare credits a redesigned runtime that gives a faster path to a running Container [9].
The post reports only the median. It does not describe the image or instance type ComputeSDK used. For the number to hold for another team, that team's images would have to look like the ones tested, and its latency budget would have to be set on the median, not the slow tail. Heavy images are the case to check. By Cloudflare's own list, coding agents need repositories, package managers, compilers, test runners and development servers [10].
Two customers quoted in the post describe the same pattern of one sandbox per session. "At Kilo Code, every cloud-agent session needs its own workspace and environment, with the right repository, tools, and user configuration," said Emilie Schario, Kilo Code's co-founder [13]. Dolev Epshtein, a software engineer on app infrastructure at Base44, said: "Cloudflare Containers gives each app an isolated development environment where our AI can execute commands, install dependencies, and bring changes to life in a live preview." [14]
What to watch
- ComputeSDK publishing the image, instance type and tail latencies behind the 648ms median.
- Filesystem snapshots leaving public beta, and any limits that come with general availability.
- How quickly Sandbox SDK 1.0 users move off the wrapper class onto native ctx.container control.