Cloudflare Computer is a virtual filesystem that lives inside a Durable Object. The Durable Object holds the authoritative state in SQLite and exposes one pluggable execution surface through workspace.runtime. Three backends ship today:

• Container projects the SQLite state into a sandbox container as a real FUSE mount. A sandbox-side daemon (computerd) mounts the state as a filesystem and syncs changes back over a capnweb RPC channel. Full Linux userland, real binaries, real network.
• Isolate shell runs just-bash in a Dynamic Worker. It reaches the authoritative Workspace over Workers RPC, so there is no second store or sync round trip.
• Isolate JavaScript runs an ECMAScript module in a fresh Dynamic Worker with structured input/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. workspace.runtime.exec(source, { backend }) is the single execution entry point; the selected backend defines whether source is a shell command or an ECMAScript module. Backends connect lazily on first use.

Workspace can also be constructed without a backend at all, giving callers the filesystem on its own.

• Node 22 or newer.
• npm. This repo uses npm workspaces.
• Linux with FUSE if you want to run packages/computerd end-to-end. Other packages build and test on macOS as well.
• Docker, optionally, for examples/container. The worker example needs no Docker.

git clone https://github.com/cloudflare/computer.git
cd computer
npm install
npm run build:all
npm test

To see the pieces working together, start with the examples:

• examples/container — runs computerd inside a container, mounts a workspace, and talks to a Durable Object over capnweb.
• examples/worker-shell — same HTTP surface as the container example, but the shell runs in a Dynamic Worker loaded through env.LOADER. No container.
• examples/think — an agent that uses the workspace as its working directory.
• examples/tutorial — the smallest version of that idea, built up step by step: one endpoint, one file, an agent that writes markdown on the host and runs pandoc on it in the container.

The repo is a small monorepo. Each package has its own README with package-specific status and usage notes.

• packages/dofs (@cloudflare/dofs) — Durable Object SQLite-backed virtual filesystem, sync protocol building blocks, and a @platformatic/vfs provider for Node.
• packages/rpc (@cloudflare/computer-rpc) — capnweb wire types and server/client helpers shared between the Durable Object and computerd.
• packages/computerd (@cloudflare/computerd) — the computerd daemon: a FUSE mount plus HTTP/WebSocket RPC server that runs inside the sandbox container.
• packages/computer (@cloudflare/computer) — the top-level Computer package consumed by Durable Objects. Work in progress.

Numbers from script/fs-bench.sh and a full npm install of cloudflare/sandbox-sdk (854 packages, 36,675 files), running examples/container on a Cloudflare Containers standard-2 instance (1 vCPU, 6 GiB memory, 12 GB disk). The computerd FUSE mount lives at /workspace; the comparison columns are an in-memory tmpfs at /tmp and the container's ext4 root disk at /var/tmp.

Ratios are computerd / baseline — lower is faster, values below 1.0 mean computerd beats the baseline.

computerd is ~2x slower than the container's ext4 disk for the full npm install, and ~3.6x slower than tmpfs. The disk comparison is the more realistic baseline for general usage.

The in-memory inode store beats real disk on metadata-heavy work: stat, rm, mkdir tree, find tree, git init, git clone, npm init. Those eight scenarios cover most of the day-to-day cost of tools like git status, module resolution, and incremental builds.

Large sequential file I/O. The computerd write path hashes each CHUNK_SIZE (512 KiB) chunk into a content-addressed blob store on every release; that's how the Durable Object can sync only the chunks that changed and deduplicate identical content. The cost lands on raw dd-style throughput numbers but rarely on real developer workloads, which is why npm init + tiny install matches the disk baseline despite pure read 64 MiB being 30x slower.

bash script/run-fs-bench.sh

or against a deployed computerd-container instance, upload script/fs-bench.sh and run it with MOUNT=/workspace BASE=/tmp.

• docs/ — design specification. Forward-looking; treat as intent.

See CONTRIBUTING.md for setup, formatting, testing, commit message, and pull request conventions.

If you're working in this repo as an agent, start with AGENTS.md and the skills under .agents/skills/.