Skip to content

Back to the catalog

Cloudflare Computer
github.comrepo

Cloudflare Computer

Cloudflare Computer is a preview virtual filesystem living inside a Durable Object, with authoritative state in SQLite exposed through three pluggable execution backends: a full Linux container mounted via FUSE and capnweb RPC, an isolated shell (just-bash) running in a Dynamic Worker, and isolated JavaScript modules in a fresh Dynamic Worker with scoped fs/git/artifacts access. It's designed as sandboxing infrastructure for AI agents, with examples demonstrating per-backend egress policy controls (none/all/custom) and MCP-based code execution tools, making it relevant to securely isolating and constraining agent/LLM code execution.

TL;DR Cloudflare's preview Durable Object-backed sandbox with pluggable isolation backends (container, Worker shell, Worker JS) and per-backend egress policies for running untrusted/agent-generated code.
Open original ↗
Document

What it is

Cloudflare Computer is explicitly a PREVIEW ONLY release — the README states APIs are unstable, the design is subject to change, and it is "NOT suitable for production use at this time." It is fit for experiments, exploration, and prototypes. The docs/ specification is forward-looking intent, not a description of the shipped code. The existing summary presents the three-backend sandboxing architecture as if it were deployable infrastructure; the page's own status disclaimer is the fact an engineer deciding whether to act needs first.

Preconditions / Affected

The @cloudflare/computer top-level package is marked "Work in progress." The release artifact for the container daemon is a Docker image, not an npm package (packages/computer-computerd-linux-x64 is a private Docker image context for the prebuilt computerd linux-x64 binary). Building on this means installing @cloudflare/computer and following its README for the entrypoint map.

Performance

computerd's FUSE mount beats real disk on metadata-heavy work and trails it on large sequential I/O. This is the load-shape tradeoff that decides whether the container backend fits a given agent workload — metadata-churning filesystem operations favor it, large streaming reads/writes do not. The page does not print the numbers inline; docs/19_performance.md holds the full fs-bench figures, a comparison against a cloudflare/sandbox-sdk npm install, and reproduction steps.

What to do

  • Treat as a prototype dependency only; do not put it on a production path.
  • If evaluating the container backend, pull the fs-bench numbers from docs/19_performance.md and match against your workload's I/O shape before committing.
  • Note the contribution model: bug reports, fix proposals, feature requests, and design proposals go through issues/discussions — unsolicited pull requests are not accepted.

Caveats

The performance claim is directional as stated on this page; the actual benchmark magnitudes live in the linked doc, not the text analyzed here. "Beats" and "trails" are the page's own words without figures attached.

Technologies named here

Techniques named here

  • Sandboxed execution isolation
  • Egress policy control

Related in AI Security