On August 3, 2026, in the middle of what Cloudflare branded "Agents Week," engineers Matt Carey and Aron Carroll shipped a preview of a project with an almost aggressively generic name: @cloudflare/computer. The tagline is "give your agent a computer 👾," which sounds like every other entrant in the increasingly crowded AI-agent-sandbox category. It has picked up roughly 7,700 stars since, which by GitHub-trending standards is respectable but not viral.
What makes it worth a second look isn't the star count. It's the architecture. Every other product in this space — E2B, Daytona, Modal sandboxes, Docker's own agent tooling — sells you a container or a VM: spin one up, run code inside it, tear it down. The container is the unit of state and the unit of compute, bundled together. Cloudflare's bet is that this bundling is the actual bottleneck, not GPU cycles or model quality. @cloudflare/computer splits the two apart: the filesystem is durable and authoritative, living in a Durable Object backed by SQLite, and the thing that executes code against that filesystem — a container, a JavaScript isolate, a shell isolate — is disposable and swappable per call. That's a genuinely different shape than "pip install and get a VM," and it's worth understanding why Cloudflare thinks it matters before you decide whether to build on it.
What it actually does
Strip away the branding and @cloudflare/computer is a workspace object that lives inside a Durable Object. That workspace holds one thing as ground truth: a virtual filesystem, persisted to SQLite. Everything else — containers, isolates, RPC channels — is a way of getting code to read and write that filesystem.
The public API surface is deliberately small. There's one execution entry point:
workspace.runtime.exec(source, { backend })
source is either a shell command or an ECMAScript module, and backend selects which of three registered execution surfaces handles it. A single workspace can register multiple backends under stable IDs and pick between them per call, which is the part that's actually novel here — you're not choosing a sandbox provider once at project setup, you're choosing an execution strategy per unit of work, against filesystem state that doesn't care which strategy you picked last time.
The three backends that ship in the preview:
-
Container. The SQLite-backed filesystem state gets projected into a sandboxed Cloudflare Container as a real FUSE mount. A sandbox-side daemon called
computerdmounts the state as a filesystem and syncs changes back over a Cap'n Web RPC channel — Cloudflare's own schema-free, object-capability RPC framework, built by the original author of Cap'n Proto. This backend gives you a full Linux userland: real binaries, a real package manager, real outbound network access. It's the heaviest option and the one closest to what E2B or Daytona give you by default. -
Isolate shell. Runs
just-bash— a bash implementation built by Vercel Labs, not Cloudflare — inside a Dynamic Worker. It talks to the authoritative workspace over Workers RPC directly, so there's no second filesystem to keep in sync and no daemon in the loop. It's a shell environment, but it never leaves the isolate. -
Isolate JavaScript. Runs an ECMAScript module in a fresh Dynamic Worker with structured input and output, durable relative imports, a Workspace-backed
node:fs/promisesshim, and two trusted modules,ws:gitandws:artifacts, for source control and build output respectively.
Backends connect lazily on first use, and the workspace itself is the only thing an agent needs to hold a reference to — it doesn't need to know in advance whether a given task is going to need a full Linux container or can get away with a sandboxed JS module. That routing decision can be made by the platform, or by the model itself, at the point of execution.
How it's actually built
The interesting engineering decision is where the source of truth lives. In a conventional sandbox product, the container's own filesystem is the state — when the container dies, unless you've explicitly snapshotted or synced it somewhere, the state is gone or has to be reconstructed from a base image plus a command log. @cloudflare/computer inverts that. The Durable Object's SQLite storage is authoritative; every execution backend is a view onto that storage, not the storage itself.
For the container backend this means a genuinely unusual data path: computerd, running inside the sandbox, mounts the SQLite-backed state as a real FUSE filesystem and syncs writes back over Cap'n Web RPC. The container gets to behave like it has a normal Linux filesystem — because from inside, it does — while the Durable Object never loses track of what's true. Kill the container, spin up a new one, remount, and you're back where you left off without replaying a command log.
For the isolate backends, there's no FUSE layer and no daemon at all, because there's no second filesystem to reconcile — the isolate runtime, in Cloudflare's terms a "Dynamic Worker," talks straight to the Workspace over Workers RPC, and the node:fs/promises calls a JS module backend makes are direct reads and writes against the durable state. This is the actual argument for splitting state from compute: for the large share of agent work that's really just "read some files, run some deterministic logic, write some files back" — the kind of thing Cloudflare's announcement specifically calls out as "ideal for file manipulation and data processing" — you never need to pay the cost of booting a container, mounting a filesystem, or holding open a persistent VM. You only reach for the container backend when a task genuinely needs native binaries, a package manager, or a complete userland, which per the project's own description is explicitly the exception case, not the default.
The registration model is worth walking through concretely, because it's what makes the "let the model pick" story plausible rather than theoretical. A workspace doesn't come with backends pre-wired; the calling code registers them under stable string IDs — something like workspace.registerBackend('container', containerConfig) alongside workspace.registerBackend('js-isolate', isolateConfig) — and from then on, any call site, including a tool definition handed to an LLM, can pass { backend: 'container' } or { backend: 'js-isolate' } as a parameter rather than a hardcoded architectural decision made at deploy time. That means an agent framework built on top of @cloudflare/computer can expose "run this in a full Linux environment" and "run this as a fast, sandboxed script" as two tool-call options the model itself chooses between per step, with both options reading and writing the same durable state. None of the container-first competitors have an equivalent second tier to offer as the cheap default — with E2B, Daytona, or Modal, "fast and cheap" and "full Linux" are the same tier, just with different boot-time optimizations layered on top.
There's a small but telling detail buried in the choice of just-bash for the isolate shell backend: it's a Vercel Labs project, not a Cloudflare one. Cloudflare didn't write its own bash-in-JS implementation for the fast path — it took a competitor's open source tool and wired it in. That's either a sign of a healthy open ecosystem around agent tooling, or a sign that even Cloudflare didn't think reimplementing a POSIX shell was worth the engineering time, depending on how cynical you want to be about it.
What actually changed here
Every serious competitor in this space is architected around the container (or microVM) as the atomic unit. E2B's pitch is fast-booting Firecracker microVMs you can spin up in the low hundreds of milliseconds; Daytona's is a similarly fast, ephemeral "dev environment as a sandbox" model; Modal's is serverless GPU/CPU containers with a Python-first SDK. All three treat the sandbox's own disk as the state, and all three have invested heavily in making the boot fast, because boot time is the tax you pay every time state and compute are welded together.
Cloudflare's framing, laid out explicitly in the announcement, is that this welding is itself the problem: "container-per-agent does not scale to the concurrent agent counts product teams are already designing for." That's a specific, falsifiable claim worth sitting with. If a product wants to run hundreds or thousands of concurrent lightweight agent tasks — most of which are file edits, greps, small scripts, and JSON munging rather than pip install-and-compile workloads — provisioning a fresh container (even a fast-booting Firecracker one) for every single one is real, avoidable overhead, both in latency and in the raw count of VMs a platform has to schedule. Cloudflare's answer is to make the default path an isolate that shares infrastructure the way ordinary Workers do, and treat the full container as an opt-in escape hatch rather than the baseline.
Whether that tradeoff holds up depends entirely on what your agents actually do. If your workload is "run arbitrary untrusted code with native dependencies," you're going to be in the container backend most of the time anyway, and the isolate options don't save you much. If your workload is "an agent that mostly reads and edits a repo, runs some validation, and occasionally shells out," the isolate-first model is a legitimately different cost and latency curve than what E2B, Daytona, or Modal offer today, because those platforms don't have an equivalent no-container tier for the same authoritative filesystem.
Why developers should actually care
Cost. The economics here follow directly from the architecture. Isolate execution shares Cloudflare's existing Workers/Dynamic Workers infrastructure — the same pool that runs ordinary edge functions — rather than provisioning a dedicated VM per session. For workloads dominated by file manipulation rather than native compute, that's a meaningfully cheaper default than a container-per-task model, assuming Cloudflare prices it that way at general availability (pricing for the isolate backends hadn't been finalized as of the preview).
Latency. A Dynamic Worker cold start is closer to the latency profile of an ordinary edge function than to a container boot, even a fast one. For an agent loop that's making many small, sequential tool calls — edit a file, run a check, edit again — shaving container-boot latency off the majority of those calls compounds fast, even if the occasional container-backed call still pays the full cost.
Lock-in. This is the part the announcement doesn't dwell on. The entire model is load-bearing on Durable Objects — Cloudflare's own strongly-consistent, single-instance-per-key compute primitive — and on Cap'n Web's RPC semantics. There is no version of this architecture that runs on another cloud. If you build an agent platform around @cloudflare/computer's workspace model, you are building it on Cloudflare, full stop. That's a meaningfully deeper commitment than picking E2B or Daytona, both of which you can self-host or swap out because they're "just" container orchestration in front of your own infrastructure choices.
Security. Splitting state from compute changes the threat model rather than simply shrinking it. A compromised container backend can still read and write the full authoritative filesystem via the FUSE mount and Cap'n Web channel — the isolation boundary protects the host, not the workspace's data. Multiple backends sharing one workspace also means a bug in the routing logic that picks which backend handles a given call is a bug that can hand untrusted isolate code the same filesystem access a trusted container path would have had. That's not a flaw specific to Cloudflare — any multi-backend execution model has this shape — but it's worth designing your permission boundaries around the workspace, not around any individual backend.
Maintainability and DX. The single-entry-point API (workspace.runtime.exec) is genuinely pleasant to reason about compared to juggling separate SDKs for "the sandbox" and "the storage," which is what you end up doing when you wire E2B or Daytona to an external database or object store yourself to get persistence across sessions. Here persistence is the default, not something you bolt on.
Practical use cases
The clearest fit is coding agents that spend most of their time in a repo: reading files, making edits, running linters or type checkers, occasionally shelling out to a build tool. That workload is exactly what the isolate backends are tuned for, and the durable filesystem means a long-running agent session can be paused and resumed — or handed off between isolate and container execution mid-task — without losing state, which is awkward to do with a container-only sandbox.
A second fit is any product that needs to run many short-lived, low-privilege agent actions concurrently — think a background job that fans out to dozens of small file-transform tasks — where booting a container per task, even a fast one, is disproportionate overhead relative to the work being done.
A weaker fit is anything that's fundamentally about running untrusted, compute-heavy, or native-dependency-laden code: data science notebooks, ML training jobs, anything needing GPUs. That's Modal's core use case, and @cloudflare/computer's container backend can technically do it, but it isn't where the architecture's advantages show up — you're paying full container cost with none of the isolate-path savings.
Picture a coding-agent product handling a batch of a few hundred pull-request review tasks. Most of them are "clone the diff context, run a linter, check for obviously dangerous patterns, write a comment" — pure file manipulation, no compilation, no native deps. A handful need to actually run the project's test suite, which means real binaries and a real package manager. On a container-only platform, all few hundred tasks pay full container-boot cost, because that's the only unit available. On @cloudflare/computer, the bulk of the batch runs on the JS-isolate backend against the same durable workspace state, and only the subset that needs npm test to actually execute escalates to the container backend — and it escalates against the same filesystem, mid-task, rather than needing a separate handoff step to move files from one system to another. That's the scenario the architecture is actually optimized for, and it's a genuinely awkward one to replicate on a container-first platform without building your own state-sync layer on top of it.
What the docs and the launch post don't dwell on
The project is explicitly a preview: the README states unstable APIs and calls it unsuitable for production, and the repository doesn't accept unsolicited pull requests, which tells you this is Cloudflare iterating in the open rather than inviting a community to co-build it yet. Treat every API surface described here as subject to change before general availability.
The FUSE-mount-plus-RPC-sync design for the container backend, while elegant, is also the part most likely to have edge cases that don't surface until you're running it at real scale — file-locking semantics, large-binary sync latency, and behavior under concurrent writes from multiple backends against the same workspace are exactly the kind of thing that tends to get discovered by early adopters rather than documented up front in a preview. There's no public benchmark yet comparing isolate cold-start latency or container FUSE-sync overhead against E2B's or Daytona's boot times, so "it's faster" is currently Cloudflare's framing, not an independently measured result.
And the lock-in point bears repeating because it's easy to gloss over in an announcement post: this is not a portable abstraction over "some container provider." It is a Cloudflare-native primitive, and adopting it early means betting that Cloudflare's Durable Objects and Dynamic Workers platform is where you want your agent infrastructure to live for the long haul.
How it stacks up
@cloudflare/computer |
E2B | Daytona | Modal | |
|---|---|---|---|---|
| Core unit | Durable, authoritative filesystem with swappable execution backends | Firecracker microVM sandbox | Ephemeral dev-environment sandbox | Serverless container |
| State model | Persistent by default (SQLite in a Durable Object) | Ephemeral unless explicitly snapshotted | Ephemeral unless explicitly persisted | Ephemeral, volumes optional |
| Fast path without a container | Yes — JS/shell isolates via Dynamic Workers | No | No | No |
| Full Linux userland option | Yes, via FUSE-mounted Cloudflare Container | Yes, primary model | Yes, primary model | Yes, primary model |
| GPU support | No | No | No | Yes |
| Portable across clouds | No — Durable Objects-native | Yes, self-hostable | Yes, self-hostable | No — Modal-native |
| Maturity | Public preview, unstable API | Production, widely adopted | Production | Production |
An independent read
The architecture is a legitimately different answer to a question the rest of the sandbox market hasn't seriously asked: does every agent action need a container? Cloudflare's answer — no, most don't, and the ones that do should be the exception you opt into rather than the default you pay for — is defensible and, if the isolate-path economics hold up at general availability pricing, could be a real cost and latency advantage for the specific shape of workload it targets.
But it's worth being skeptical of the framing that this replaces E2B, Daytona, or Modal outright. Those products are optimized for a different center of gravity: untrusted, compute-heavy, native-dependency execution, which is @cloudflare/computer's container backend at best and out of scope at worst — there's no GPU story here at all. What Cloudflare has actually built is a strong argument that state deserves to be a durable, platform-level primitive independent of whatever's executing against it, and a working preview of what that looks like when you own both the compute fabric (Workers) and a strongly-consistent storage primitive (Durable Objects) to build it on. That combination is genuinely hard for a container-orchestration-focused competitor to replicate without also owning an edge compute platform — which is exactly why E2B, Daytona, and Modal haven't built anything like it themselves.
Who should try it, wait, or skip it
Try it now if you're already building on Cloudflare Workers, your agent workload is dominated by file reads/edits/greps rather than heavy native compute, and you're comfortable running preview-grade infrastructure with an unstable API in a side project or internal tool.
Wait if you need production stability, GA pricing clarity, or independent benchmarks before committing engineering time — the preview label and "no unsolicited PRs" policy are Cloudflare explicitly telling you it isn't ready for that yet.
Skip it if your workload needs GPUs, needs to run outside Cloudflare's platform, or if avoiding single-vendor lock-in on your agent execution layer is a hard requirement — in that case E2B or Daytona, both self-hostable, are the safer long-term bet regardless of how compelling the isolate-first cost story turns out to be.
What's your read on splitting durable state from disposable compute for agent execution — is this the direction the rest of the sandbox market ends up copying, or is it a Cloudflare-specific trick that only works because they already own both the edge compute layer and the storage primitive underneath it?
Sources:
Top comments (0)