Skip to content

CONCEPT Cited by 1 source

Isolate vs microVM for agent sandbox

Definition

A design-axis trade-off for the substrate that runs an agent's execution sandbox — file ops, command exec, code execution, web browsing — distinguishing between:

  • microVM (e.g. Firecracker / Cloudflare Containers) — hardware-virtualisation boundary; full Linux kernel; arbitrary binaries; seconds to boot, hundreds of MB minimum memory.
  • V8 isolate (e.g. Cloudflare Dynamic Workers + Codemode) — sub-process JS sandbox in a shared V8 host; milliseconds to boot, a few MB of memory, JS-only by default (with WebAssembly extension), no Linux kernel.

The axis matters once an agent is the sandbox's primary tenant because every session boots a sandbox: at fleet scale — "each of your customers should be able to run many agents simultaneously; each of your employees should have tens of agents running at once" — the boot-time-and-memory difference between the two tiers becomes a 100×-or-greater scale and cost difference.

Canonical disclosure

The trade-off was crystallised in Cloudflare's Claude Managed Agents launch post (2026-05-19), quoted directly:

"What if your agent backend booted in a few milliseconds, and you didn't have to pay for the resources of a full VM when running the agent? The industry needs a lightweight primitive for sandboxing as we adopt agents at scale, and we're building just that."

"As models get better, we expect more and more workflows to be managed by agents. Each of your customers should be able to run many agents simultaneously; each of your employees should have tens of agents running at once. If we're constantly running a full microVM per agent, we'll be unnecessarily burning a ton of resources and money to enable this scale."

"If you want to handle bursts of tens of thousands of concurrent agents or more, running with isolates will allow you to scale in a way that no VM-based solution allows."

(Source: sources/2026-05-19-cloudflare-announcing-claude-managed-agents-on-cloudflare.)

The two ends of the axis

Dimension microVM (e.g. Containers) V8 isolate (e.g. Dynamic Workers + Codemode)
Startup seconds milliseconds
Min memory hundreds of MB a few MB
Filesystem full Linux virtual workspace (Sandbox SDK HTTP API)
Languages anything (binaries OK) JS / WebAssembly
External processes arbitrary none (no fork / exec)
Capability boundary shared-kernel + cgroup / seccomp capability-based (globalOutbound: null; explicit bindings)
Per-request economics high (full VM lifetime) per-request mint and discard cheaply
Scale envelope thousands per host tens of thousands of concurrent

When to pick which

The 2026-05-19 disclosure gives explicit operator guidance:

  • microVM tier for "agents acting as a developer, building full applications and running Linux-based tools" — i.e. when the agent legitimately needs a real OS, real binaries, real filesystem, real package manager.
  • V8 isolate tier for "a faster, cheaper, and more scalable alternative" — agents that mostly run JS, fetch data, call tools, compose responses, where Linux is unnecessary.

Crucially this is not a competition — both tiers ship in the same Cloudflare-Claude-Managed-Agents integration, and the operator picks the backend type at agent setup. The forced binary "microVM or nothing" of first-generation agent products is replaced by a per-agent tier selector.

Composition with adjacent concepts

  • Composes with concepts/agent-brain-hands-decoupling — the trade-off only becomes operator-choosable once the agent's hands run on operator-controlled compute.
  • Composes with concepts/capability-based-sandbox — Dynamic Workers' isolate tier ships with no ambient authority by default (globalOutbound: null), making the capability model the security boundary rather than network / process isolation.
  • Composes with concepts/cold-start — the millisecond boot of a V8 isolate effectively eliminates the cold-start cost that has historically been the dominant tax on per-request compute.
  • Composes with concepts/durable-vs-ephemeral-sandbox — microVMs more naturally support durable sandbox semantics (longer-lived state, full FS); isolates are more naturally ephemeral (per-request mint and discard) but Cloudflare's control plane provides external state persistence regardless of tier.

Sibling concept

The wiki already has concepts/hardware-isolated-microvm-on-kubernetes canonicalising the "compose Kubernetes scheduling + microVM isolation" composition (e.g. Atlassian Fireworks). That concept resolves the isolation boundary axis under the assumption that microVMs are the right unit. The current concept resolves a higher-altitude question — should the unit be a microVM at all, or a lighter isolate? — and pins the answer at "depends on workload shape, pick at agent-setup time."

Seen in

Last updated · 542 distilled / 1,571 read