Cloudflare's Solution: A "Personal Computer" for Your Agent

The idea: don't hand the Agent a clunky container; give it an abstracted "computer"—a file system stored in the cloud, plus a few execution environments that can operate on those files. This "computer" rests on three pillars.

1. Two Types of "Workers" Divide the Labor

That logic leads to Cloudflare's architectural roadmap. On the left, earlier this year: Agent, config secrets, and tools all in one container. In the middle, today: the loop layer has moved into an isolate, config and tools stay in the container. On the right, the goal: config and tools also move into the isolate, leaving only the heavy, non-negotiable tasks in the container.

Three-column evolution: BEFORE shows everything in a container; TODAY moves the loop layer into an isolate; NEXT moves config secrets and tools in as well, leaving only heavy tasks in the container. The right column is Cloudflare's plan for the next step, not the current state. Source: Cloudflare

No Linux in the Isolate. How Does It Work?

This is the easiest layer to overlook, and arguably the most valuable. The shell in the isolate runs thanks to something called just-bash.

just-bash is an open-source project from Vercel Labs that reimplements bash syntax and roughly 80 Unix commands in pure JavaScript. grep (searching for keywords in files), sed (batch editing text), awk, jq, sort, find, tar, diff, sqlite3 — each one is a JavaScript function, not a binary program. Pipes, redirection, &&, variables, globbing, if, for, while, and custom functions are all implemented too.

That's exactly why it fits in an isolate: no processes, no forks, no kernel—just JavaScript functions passing strings.

The trade-off is a hard boundary. Cloudflare's package source shows the default shell environment disables three just-bash capabilities: Python, JavaScript execution, and networking. The first two aren't even a choice—they rely on node:worker_threads, a module unsupported in Cloudflare's runtime, so they can't be installed. Disabling networking means curl simply doesn't exist in the isolate.

So how does git clone succeed? The isolate's shell has no network access, so git is a fake command. It delegates to the host-side Durable Object, which makes the actual request and writes the fetched files straight into the shared file system. The isolate never touches the network.

The Agent Chooses Which Environment to Use

For each command, the Agent weighs the boundary:

Frontier models handle this well, falling back to the container only when needed. The tool descriptions fed to the model explicitly state that the container side has "a full Linux userspace: npm, node, package managers, test frameworks, and real binaries on the $PATH," allowing it to choose accordingly.

Here's a real trace. A user asked the Agent to update dependencies for the cloudflare/computer repo. Next to each command in the UI, a tag indicates where it ran:

A real conversation trace. git clone is tagged ISOLATE·GIT, ls is tagged ISOLATE, read took 0 ms, webfetch 216 ms, apply_patch 0 ms. In the entire sequence, only npm install is tagged CONTAINER, installing 665 packages and taking 56 seconds. Source: Cloudflare

In that entire sequence, only the package installation truly needed Linux, and it alone consumed 56 seconds. Everything else was millisecond-fast.

2. The Shared File System

Files themselves live in the SQLite database that comes with the Durable Object—that's the single source of truth. Whether the Agent operates from the isolate or the container, it sees this one version. No copying back and forth, no re-initialization.

But each side reaches it very differently.

FUSE mount: a mechanism that lets regular programs treat "things that aren't really disks" as if they were disk directories. Programs in the container think they're reading a normal file, but every read/write is actually forwarded to the remote Durable Object.

Why chunk and hash? So the Durable Object only needs to sync the chunks that actually changed, and identical content is automatically deduplicated. The trade-off shows up directly in throughput.

Here's the full structure:

The big picture: both the virtual file system and the execution runtimes live on the same Durable Object. Files can be ingested from external sources like cloud storage, code repos, or archives. Source: Cloudflare

This diagram highlights the asymmetry best: the container side has its own copy of the file system, synced via push/pull with the source of truth. The isolate side has only a thin adapter layer, reading/writing the source directly via a binding. The right side of the diagram labels "a small computed binary," which, based on the repository, should be the computerd daemon—likely a typo in the original diagram. Source: Cloudflare

The official tutorial's example best illustrates how this division of labor saves work: you POST a dish name, the Agent finds the recipe, writes a card.md on the host side, then runs pandoc card.md -o card.pdf in a container to convert it to PDF, and finally uploads it to R2, giving you a link that expires in a day. Writing markdown is plain file work, done on the host without spinning up a container. pandoc is a real binary, so it must go into a container. The container sees the same /workspace via the mount, so it reads the file just created, and the resulting PDF can be written back.

The Cost of This Design: Faster for Small Files, Slower for Large Ones

Cloudflare ran a comparison between the FUSE mount and the container's own ext4 disk using a standard-2 container instance: 1 vCPU, 6 GiB RAM, 12 GB disk.

The results split into two categories. Tasks involving many small files are faster than a real disk; sequential read/write of large files is painfully slow.

Bar lengths are scaled by time multiplier. Green indicates faster than the container's real disk; orange indicates slower. A multiplier below 1 means faster.

The faster half has a clear cause: the file index lives in memory, so operations like "browse directory, check status, delete small files" skip the disk seek overhead. The slower half is also clearly caused by that long chunk-and-hash path above: every write requires re-hashing, which looks terrible on raw dd-style throughput.

3. Control & Security

Every step the Agent takes has a gate, an audit trail, and observability. Here's the breakdown:

There are two caveats worth knowing before you dive in.

First, the path check is not a security boundary. It isn't atomic "resolve to below root," so you can't use a single isolate's capability against another higher-privilege entity that might concurrently swap paths. To defend against such adversarial concurrency, you'd need a future transactional foundation, or simply use separate workspace identities for each side.

Second, "audit logging" is inconsistent across the three backends. The isolate JavaScript variant writes an execution ledger to the workspace database, retaining events and results until you explicitly clear them. However, the isolate shell version explicitly does not retain cross-request events and cannot resume by ID. For supervised process behavior, the official recommendation is to use the container path.

Also, if execution fails or is cancelled, file changes already written to disk are not rolled back.

How to Use It (Developer's Perspective)

Installation & Setup

The package itself is MIT-licensed, free, and open-source. You can install it with npm install @cloudflare/computer. The current version is 0.1.1, first published to npm on July 29.

Once installed, a workspace can be attached to any Durable Object. If you're using Cloudflare's own Agent framework, @cloudflare/think, the setup is even more concise. It comes with a set of AI SDK-compatible tools, providing Agents with basic tools like read, write, edit, ls, and exec, where exec takes a backend parameter—that's the selection line we discussed earlier.

Three Available Runtimes Out of the Box

Cloudflare's blog says two, but both the repo README and the npm package entry point list three:

The third is the embodiment of Code Mode thinking: instead of having the model type shell commands one by one, let it write code directly.

Pricing

The package is free, but running it for real will immediately hit the free tier's limits:

For local development, you'll also need Docker, because wrangler needs to build the container image locally. It comes with 8 runnable examples, one of which is a step-by-step tutorial starting from an empty directory—the same recipe-to-PDF example mentioned earlier.

Not Production-Ready Yet

For now, this is for experimentation, exploration, and prototyping. It's not suitable for production: the API is unstable and the design is subject to change. Even the design spec is forward-looking, describing intent rather than the current state of the code. Three hard limitations:

Value & Summary

In concrete scenarios, Cloudflare says they already have internal Agents completing entire workflows using only isolates: building, testing, and deploying JavaScript apps with modern toolchains, generating custom docs for each customer, and completing complex tasks in a browser. Previously, all of these required containers.

In one sentence: let Agents work in an ultra-lightweight, cost-saving mode most of the time, switching to a heavy-duty mode only for tough problems—making large-scale Agent operation both fast and cheap.

Today it's a 0.1.1 preview, not production-ready. But it lays out the "how much compute does an Agent actually need" math openly, including the ugly numbers.

Thanks to an open-source project called just-bash (by Vercel Labs), which reimplements bash syntax and about 80 Unix commands in pure JavaScript. grep (search for keywords), sed (batch edit text), jq, find, tar—each one is now a JavaScript function, not a program to launch. No processes, no kernel—just functions passing strings to each other. That's why it fits in an isolate, and also why it can't run npm or Python.

Files live in a Durable Object (a long-lived object on Cloudflare with its own SQLite database that survives restarts)—the single source of truth. Both the isolate and the container modify this one copy, but they reach it in completely different ways.

Cloudflare ran a comparison between the FUSE mount and the container's real disk. The results split into two categories. On the same mount point, browsing directories is faster than a real disk; copying a large file is 41x slower.

The dividing line is here: browsing directories, checking status, and deleting small files benefit from an in-memory file index that skips disk seek. Large-file sequential I/O, however, has to chunk and hash its way through, which cripples raw throughput. Cloudflare's argument is that the former is where real development actually spends its time.

The package is installable: npm install @cloudflare/computer. It's MIT-licensed, free, and open-source. Current version is 0.1.1. But the repo itself says PREVIEW ONLY.