Why Every Cloud Is Racing to Build Sandboxes for AI Agents

In the space of a week, four separate cloud providers shipped or announced the same primitive: a disposable, isolated machine that exists for one agent task, pauses when the agent stops, and resumes exactly where it left off. Cloudflare rebuilt its container runtime around it, DigitalOcean opened MicroVMs in private preview, Microsoft reached general availability with Azure Container Apps Sandboxes, and Docker extended its sandbox from the laptop into managed cloud compute. The execution boundary for AI agents has quietly become the most contested layer in cloud infrastructure.

What each provider shipped

Cloudflare rearchitected Containers so that the scheduler no longer treats an application as the unit of configuration. Under the new durable_object scheduling policy, application code chooses each sandbox's image and instance type at runtime, with no rollout configuration in between. Median startup fell from just over four seconds to 648 milliseconds in ComputeSDK's independent benchmark, and filesystem snapshots entered public beta so a workspace can be saved and restored. According to Cloudflare's engineering post, every Container is attached to a Durable Object that now controls it directly through the native ctx.container API, a model carried into Sandbox SDK 1.0. The legacy Container and Sandbox classes will be maintained only through December 31, 2026.

DigitalOcean introduced MicroVMs in private preview: one lightweight virtual machine per session, built on Firecracker, with its own kernel and a hardware-virtualized boundary instead of a shared one. A MicroVM pauses automatically after a timeout and resumes on the next request with memory, files, and running processes intact. Checkpoints let teams boot a machine once, warm its runtime and dependencies, then start future machines from that state rather than rebuilding the environment every time. The same layer already powers DigitalOcean Managed Agents, and the company now offers it directly to teams building their own agent infrastructure.

Microsoft made Azure Container Apps Express generally available alongside the GA of Container Apps Sandboxes, the layer Express runs on. Sandboxes provision from prewarmed pools for subsecond startup, isolate each workload in a hardware-isolated microVM, burst to thousands of concurrent instances, and support suspend and resume that snapshots full state including memory and disk. InfoQ reports that the primitive may already underpin core Azure services including Foundry Hosted Agents, and that Microsoft exposes it directly as Microsoft.App/SandboxGroups for agent platforms and secure code-execution services.

Docker took the opposite route, working outward from the laptop. Cloud Sandboxes, announced September 24, run the same microVM as its local sandbox but on Docker-managed compute, with one command to move a running agent between the two. The stated driver is horizon length: tasks that run for "five, ten, or 21 hours" cannot live on a machine that sleeps when the lid closes.

The shift: from deployments to disposable workspaces

Every one of these announcements is a rejection of the application deployment as the unit of configuration. Cloudflare states the difference plainly: you used to pick an image and its resources at deploy time and roll that configuration out centrally, whereas an agent workspace is created on demand, its image and resources decided by the task, lasting minutes, sleeping between requests, perhaps restored days later.

That lifecycle forces four primitives into the platform: instant start, per-tenant isolation, state-preserving pause, and snapshot or checkpoint. Containers alone satisfy only the first. As DigitalOcean puts it, containers "share a kernel with their neighbors," which is more trust than you want to place in code an agent just wrote. Hence the convergence on virtual-machine-class isolation: Firecracker at DigitalOcean, a hardware-isolated microVM at Azure, and gVisor-based Pod Snapshots paired with GKE Agent Sandbox at Google.

The economics are equally blunt. An always-on server for a workload that is busy a few minutes per hour is mostly idle spend, and per-second billing that scales to zero is what makes a sandbox-per-task model viable at all. Microsoft frames Express as "developer-first and agent-first" for the same reason: AI-assisted workflows create and update applications faster than anyone can configure infrastructure by hand.

Where the claims still need testing

Isolation is a marketing claim until it is probed. InfoQ recorded open skepticism in developer discussion about Azure's "hardware-isolated" description, plus an unanswered question about whether the same capability reaches Azure Kubernetes Service. Vendor-published benchmarks deserve the same caution: Cloudflare's 648-millisecond median start comes from ComputeSDK's independent test, which is more independent evidence than most competitors have offered so far.

Two operational details deserve attention before adoption. First, suspend and resume are not equivalent across providers. Azure advertises full memory and disk state with subsecond restore, DigitalOcean preserves memory, files, and processes, and Cloudflare's filesystem snapshots are still in public beta. If your agent keeps context in memory, that difference is the whole ballgame. Second, native-only capability is a migration trap: Cloudflare's fastest path is available only through ctx.container, and its legacy classes carry an end-of-support date.

For teams already reasoning about agent runtime state, this sits next to the same problem durable execution frameworks are solving - where the boundary of a running agent actually lives. Where those tools keep workflow state, sandboxes keep the machine.

Builder impact

• Choose the isolation boundary from your threat model, not the feature list. If agents execute model-generated code, shared-kernel containers are the wrong default; microVM or gVisor-class isolation is the floor.
• Design for pause, not for uptime. State that survives only inside a running process is the new single point of failure. Persist anything you cannot afford to lose across a suspension.
• Stop reserving long-lived runners for agent work. Per-task sandboxes with scale-to-zero change the cost model for CI-style agents, preview environments, and per-user workspaces alike.
• Measure median startup, not cold-start marketing. At thousands of concurrent sandboxes, the gap between 648 milliseconds and four seconds compounds into queueing.
• Treat snapshots as data. Once memory and disk state is checkpointed, snapshot contents, retention, and access control belong in your security review.
• Watch for a portable abstraction. Every provider is selling the same three primitives, which is exactly the condition that produces either a standard or a lock-in fight.

What to watch

• DigitalOcean leaving private preview and publishing MicroVM pricing.
• Cloudflare promoting filesystem snapshots out of public beta and confirming the migration path off legacy classes before December 31.
• Whether Azure exposes sandboxes in AKS, which would decide how far the primitive reaches beyond Container Apps.
• Google extending GKE Pod Snapshots and GPU memory checkpoints beyond early regions.
• The first per-sandbox-second price war - and whether independent benchmarks follow Cloudflare's lead.