Cloudflare Computer: A Durable Object Filesystem With Pluggable Execution Backends

The problem: agents need a filesystem that survives the request

An agent that writes a file, runs a command against it, and then reads the result needs three things to agree: where the bytes live, who can execute against them, and what happens when the process that did the writing is gone. Most setups split those three across separate services. Cloudflare Computer collapses them into one Durable Object. The README describes it as "a virtual filesystem that lives inside a Durable Object," with the Durable Object holding the authoritative state in SQLite and exposing one pluggable execution surface through workspace.runtime. The audience is narrow and specific: developers building agent or code-execution features on Cloudflare Workers who want the filesystem to be the durable part and the runtime to be swappable. It is not a general-purpose sandbox product, and the README states plainly that it is "NOT suitable for production use at this time."

One authoritative store, three execution surfaces

The architecture separates state from execution. SQLite inside the Durable Object is the single source of truth. Everything else is a projection of it. Three backends ship today, and they differ in how far the projection travels.

The Container backend projects the SQLite state into a sandbox container as a real FUSE mount. A sandbox-side daemon called computerd mounts the state as a filesystem and syncs changes back over a capnweb RPC channel. That path gives you a full Linux userland, real binaries and real network, at the cost of a sync round trip and a container to keep alive.

The Isolate shell backend runs just-bash in a Dynamic Worker. It reaches the authoritative Workspace over Workers RPC, so according to the README there is no second store or sync round trip. The Isolate JavaScript backend runs an ECMAScript module in a fresh Dynamic Worker with structured input and results, durable relative imports, configured libraries, Workspace-backed node:fs/promises, and trusted ws:git and ws:artifacts modules.

A Workspace may register multiple backends under stable IDs, and workspace.runtime.exec(source, { backend }) is the single execution entry point. The selected backend decides whether source is a shell command or an ECMAScript module. Backends connect lazily on first use. You can also construct a Workspace with no backend at all, which gives you the filesystem on its own. That last option is the most underrated part of the design: the filesystem is usable independently of any execution story you have not settled on yet.

Installing @cloudflare/computer and running your first exec

The top-level README does not carry installation steps. It points at the package README instead: "install @cloudflare/computer and follow that package's README, it has the installation steps, the entrypoint map, and worked examples of the fs and runtime surfaces." So the commands below come from the repository layout and the workspace scripts, and the package README is where you should look for the exact entrypoint names.

The repository is an npm workspace monorepo. Clone it and install at the root:

npm install

The root package.json declares a postinstall script that runs build:types across workspaces, so type generation happens as part of install. To build everything, including the computerd binary and the Docker image context:

npm run build:all

That expands to build, build:bin and build:docker in sequence. For a first real use, the repository ships runnable consumers rather than a minimal snippet. The worker-shell example exposes a write / read / exec HTTP surface with the shell running just-bash in a Dynamic Worker loaded through env.LOADER, and it needs no container:

cd examples/worker-shell
npm install
npm run dev

Once the dev server is up, the example's own README documents the HTTP surface you call to write a file and then exec against it. The container example exposes the same write / read / exec surface, but computerd runs inside the container and talks to the Durable Object over capnweb. If you want to see the same task run against two runtimes side by side, examples/think-compare-runtimes provides a web UI for exactly that comparison.

Where the design bites: preview status, sync cost, and the docs/ gap

The first limitation is stated by the project itself. The README carries a PREVIEW ONLY notice: APIs are unstable and the design is subject to change, and the package is suitable for experiments, exploration and prototypes rather than production. That is not boilerplate caution. Two releases, 0.2.0 and 0.2.1, landed six days apart in August 2026, which is consistent with an API still moving.

The second limitation is the split between the specification and the code. The README says the specification under docs/ is forward-looking and should be read "for intent, not as description of the code today." That means the most detailed document in the repository is not a reliable description of behaviour. If you plan against docs/, you are planning against a target that the code has not reached.

The third is the Container backend's shape. Projecting SQLite into a FUSE mount and syncing back over capnweb is a real round trip, and the README's own performance note says computerd's FUSE mount beats real disk on metadata-heavy work and trails it on large sequential I/O. So the container path is the wrong choice when your workload is bulk sequential reads and writes. The Isolate shell and Isolate JavaScript backends avoid the second store and the sync round trip entirely, which makes them the better fit for metadata-light or compute-light tasks, at the cost of a Linux userland that just-bash does not provide.

There is also a contribution constraint worth knowing before you invest: the project accepts bug reports, fix proposals, feature requests and design proposals through issues and discussions, but does not accept unsolicited pull requests. If your adoption plan depends on patching the runtime yourself and upstreaming it, that path is closed unless you become an approved collaborator.

How it compares to running a plain sandbox container

The obvious alternative is a sandbox container on its own, with the filesystem living inside the container and a volume or object store behind it. That approach is simpler to reason about: one process, one mount, no RPC channel between a Durable Object and a daemon. The difference in approach is where durability sits. In a plain sandbox, the container is the unit of state and the filesystem is an implementation detail of it. In Cloudflare Computer, the Durable Object SQLite store is the unit of state and the container is one of several ways to reach it. That matters when you want the same files to be readable by a shell, by an ECMAScript module, and by your Worker code without copying them between stores. It matters less when the container is the only execution surface you will ever need, because then you are paying for a sync protocol you do not use.

The README mentions a cloudflare/sandbox-sdk npm install comparison in docs/19_performance.md, which is the place to look if you are weighing the two on install-heavy workloads. The repository does not state the outcome of that comparison in the top-level README, so read the document itself before drawing a conclusion.

Maintenance, licensing, and what an upgrade costs you

The repository is not archived, and the last push was on 2026-08-17, the same day @cloudflare/[email protected] was released. That is recent enough that the codebase is moving, but the preview notice means movement is not the same as stability. Versioning is at 0.2.x, so semver gives you no compatibility promise across minor bumps. The repository uses Changesets, with a changeset script and a GitHub changelog plugin, so release notes are generated per package. That is the mechanism to watch when deciding whether an upgrade is safe: read the changeset for the packages you depend on rather than the root version.

Upgrade cost has a structural component too. The monorepo splits into @cloudflare/dofs, @cloudflare/computer-rpc, @cloudflare/computerd and @cloudflare/computer, and computerd is distributed as a Docker image context rather than an npm package. packages/computer-computerd-linux-x64 is described as a private Docker image context for the prebuilt computerd linux-x64 binary, and the README notes the image, not an npm package, is the release artifact. So the Container backend pins you to linux-x64 for the prebuilt binary, and upgrading computerd means pulling a new image rather than bumping a dependency version.

The licence is MIT, stated in the README and present as a LICENSE file at the repository root. MIT is permissive and imposes no copyleft obligation on your own code, but this is a description of the licence text, not legal advice. If you redistribute the computerd binary or the Docker image, check the terms attached to those artifacts separately, since the repository does not describe them in the README.

Editorial conclusion

Adopt Cloudflare Computer for prototypes where you want one durable workspace that several execution surfaces can read and write, and where you accept that APIs are unstable and the package is marked preview only. Do not adopt it for production workloads, and do not expect unsolicited pull requests to be merged. Before you build anything, read packages/computer/README.md for the entrypoint map, check docs/19_performance.md for the FUSE benchmark methodology, and confirm which release of @cloudflare/computer you are pinning, since 0.2.0 and 0.2.1 landed six days apart.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes