Cloudflare today released @cloudflare/computer, an MIT-licensed npm package that gives each agent a virtual filesystem stored in a Durable Object and three ways to run a task: JavaScript in a V8 isolate, a shell in an isolate, or a real Linux container over FUSE. The stated design goal is to keep container usage under 10% of tasks, since containers cost too much to hand one to every agent. The repo is marked PREVIEW ONLY with unstable APIs, so treat it as an architecture to study. The unaddressed question is isolation quality: the fast default path shares a runtime with the workload, which is a weaker boundary than the Firecracker microVMs that dedicated agent-sandbox vendors run.
Give every agent a container and the bill arrives before the agent does. That is the problem Matt Carey and Aron Carroll set out to solve in Cloudflare’s launch post for @cloudflare/computer, and the fix is to stop treating “a computer” and “a container” as the same purchase.
The package splits the two. An agent gets a persistent virtual filesystem, SQLite-backed and living inside a Durable Object, which it can read and write between tasks. Execution is a separate decision made per task. Most work lands in a V8 isolate, either as JavaScript or as a shell (the repo lists a just-bash isolate shell backend). Work that genuinely needs a Linux environment, npm, or a native binary gets a full container, with the virtual filesystem FUSE-mounted into it.
Three backends, one filesystem
Keeping state out of the compute is what makes the routing possible. The filesystem outlives any individual task, so an isolate can write a file that a container reads five minutes later, and neither has to be long-lived. Cloudflare also wires in git and cloud storage, and ships an AI SDK-compatible toolkit so a model can call the filesystem and execution primitives as tools.
The under-10% figure is a target Cloudflare set for itself, not a measured result it has published. It’s a cost claim dressed as an architecture: containers are the expensive path, so the runtime treats reaching for one as a failure of the cheap paths. If your agents mostly read files, edit text, and run small scripts, that ratio looks achievable. If they mostly install packages and run test suites, you’re paying container prices with extra routing logic in front.
Preview only, despite the pitch
The repo says PREVIEW ONLY, warns the APIs are unstable, and tells you plainly this isn’t for production. It had 374 stars at research time. So the post argues for a production agent architecture on top of a package its own maintainers won’t stand behind in production yet, which is worth holding in mind before you rewrite your agent stack around it. There’s a related cloudflare/workspace repo, though the exact relationship between the two is unclear from the outside.
None of this appeared from nowhere. Cloudflare announced Dynamic Workers, Artifacts, and Sandboxes GA in an April press release about expanding its agent cloud, roughly four months back. @cloudflare/computer is the opinionated runtime that ties those primitives together, which explains why a preview package can already have this much machinery in it.
The isolation tradeoff the post skips
Cloudflare’s argument is about scale and cost. The security question sits next to it, unanswered: how good a boundary is a V8 isolate around code an LLM just wrote?
Emir Beganović’s March 2026 post, Your Container Is Not a Sandbox, makes the general case. Containers, he argues, “are not a security boundary, they are a mechanism to control resource usage,” since the workload shares a host kernel of roughly 40 million lines of C exposing 450-plus syscalls. A kernel exploit inside a Firecracker microVM cannot reach the host kernel by construction. Shared-kernel approaches can’t offer that guarantee, and a V8 isolate shares a runtime with the code it’s running, which puts it on the same side of the line.
This is why E2B and Daytona build on Firecracker microVMs. Agent-generated code is untrusted code execution, and in that threat model “fast and cheap” and “hard boundary” pull against each other. Cloudflare picked the fast-and-cheap end for the majority of tasks it wants to keep out of containers. That’s a defensible engineering call at the price point they’re targeting, and it’s a real tradeoff rather than a free win. The launch post treats containers as the thing you escape for cost reasons, and skips the part where the fallback path is also the stronger one.
The honest read: if your agents run code you’d be comfortable running in a shared-runtime sandbox anyway (formatting, parsing, calling APIs, editing files you own), the isolate-first design is a good deal and the filesystem-outlives-compute model is the genuinely useful idea here. If your agents execute code from untrusted input or from a model you’re treating as adversarial, the boundary you actually want is the one Cloudflare routes away from.
What to take from it
Read @cloudflare/computer for the shape of the thing rather than the dependency. Decoupling agent state from agent compute, so that execution can be chosen per task, is the part other runtimes will copy. Cheap execution as the default with a heavy fallback is a sound pattern for anything running at Cloudflare’s scale.
Just don’t read a routing decision as a security architecture. The package tells you where each task runs; deciding which tasks are safe to run in an isolate is still on you, and the preview label means both answers may change before this is stable.
Sources: Cloudflare launch post • cloudflare/computer • Your Container Is Not a Sandbox • Cloudflare agent cloud release
Coverage: Hacker News discussion
Related on this blog: [QT] Agentic Mermaid: a clever inversion, built on an open fork • OpenAI’s Containment Problem Grows a Third Time in 10 Days • Ralph Is Five Lines of Bash. All the Bugs Are in the Improvements.