Cloudflare Computer: Agent Environment for Workers

Understanding Cloudflare Computer

A virtual filesystem, Cloudflare Computer, functions within a Cloudflare Durable Object; its authoritative state is managed by SQLite, and a single pluggable surface, workspace.runtime, is provided for code execution. Currently, three backends are delivered: specifically, a containerized FUSE mount, a just-bash shell operating in a Dynamic Worker, and a JavaScript module runtime. This design ensures that an agent interacts with the identical workspace, regardless of the backend used to execute the code.

Core Capabilities

• ✓Every backend is driven through the same call — workspace.runtime.exec(source, { backend }) — with the backend ID picked per call deciding whether source is treated as a shell command or a JavaScript module.
• ✓The container backend projects the Durable Object's SQLite state into a sandbox as a real FUSE mount, synced back through a capnweb RPC channel — it hands the agent a complete Linux userland: actual binaries, actual network egress, not a sandboxed subset.
• ✓The isolate shell backend runs just-bash inside a Dynamic Worker and connects to the authoritative Workspace straight over Workers RPC — it skips the extra copy of state and the round trip needed to keep it in sync.
• ✓The isolate JavaScript backend evaluates an ECMAScript module in a fresh Dynamic Worker, passing structured inputs and results in and out, with relative imports that stay durable across runs and a Workspace-backed node:fs/promises standing in for the real filesystem module.
• ✓A Workspace can register several backends under stable IDs at once, and each one only connects the first time something actually calls it.
• ✓A Workspace can also be built with zero backends attached, which leaves callers with nothing but the filesystem — no execution surface at all.
• ✓Inside the isolate JavaScript backend, a trusted ws:git module and a trusted ws:artifacts module are available for source control and artifact work without shelling out.

Example Agent Workflows

• •Run an agent's shell commands and file writes through the container example, which mounts computerd inside a sandbox and exposes a write/read/exec HTTP surface backed by a Durable Object.
• •Swap the container for a Dynamic Worker running just-bash (the worker-shell example) when you want the same HTTP surface without provisioning a container at all.
• •Have an agent write a markdown file and then shell out to a real binary — the tutorial example writes a recipe card and runs pandoc on it inside the container to produce a PDF.
• •Give a chat agent a persistent working directory: the think example wires @cloudflare/think to a workspace so it's reachable from a terminal.
• •To compare backends head-to-head, think-compare-runtimes offers a web UI which executes the identical agent task concurrently on both the container and worker runtimes.
• •Have an agent scaffold a Worker project inside its own workspace and publish it as a clone-ready repo through the artifacts example.

Getting Started

The root README doesn't hand you a copy-paste install command. It tells you to install the @cloudflare/computer package and then follow that package's own README for the actual setup — the installation steps, the entrypoint map, and worked examples of the fs and runtime surfaces all live there, not in the top-level file. If you're trying to contribute rather than consume the package, CONTRIBUTING.md covers the public feedback path, and approved collaborators use COLLABORATORS.md for setup, build, and test instructions.

Running Agent Code

Every backend is driven through one call: workspace.runtime.exec(source, { backend }). The backend ID picked at call time decides how source gets interpreted — a shell command against the isolate-shell or container backend, or an ECMAScript module against the isolate-JavaScript backend. Backends aren't connected until the first exec call touches them, and a Workspace can register more than one backend under different IDs so an agent can move between, say, a fast in-Worker shell and a full container mid-task. Beyond exec, the top-level README doesn't document the rest of the method signatures — for that you're back to the @cloudflare/computer package README.

Alternative Approaches for Agent Workspaces

Common Questions

The problem it solves

An agent that can only call APIs can't do the things a real developer does without thinking about it — write a file, run a compiler, chain a shell pipeline, mount a temp directory. Building that from scratch on Cloudflare Workers usually means standing up your own container orchestration plus a separate sync layer to keep it consistent with whatever state your Worker already has. Cloudflare Computer folds that state into the Durable Object itself — SQLite is the source of truth — and lets you point three different execution backends at it without writing that sync layer yourself.

Who should try it — and who should skip

Try Cloudflare Computer if you're already building agent products on Cloudflare Workers and Durable Objects and want a shared workspace abstraction instead of hand-rolling container orchestration plus a sync layer yourself — the three-backend model (container, isolate shell, isolate JavaScript) covers most of what an agent needs to touch files and run code. Skip it if you need to ship something to production this quarter, if you're not already on Cloudflare's stack, or if you need a contribution path beyond filing issues — the project doesn't take unsolicited pull requests.