Cloudflare Computer Makes the Filesystem the Durable Layer for AI Agents

The simplest way to give an AI agent a computer is to give it a container and let the container own everything: the shell, the filesystem, the installed tools and the working state. Cloudflare Computer is built around a different separation. The files are meant to survive; the execution environment is not.

Cloudflare released @cloudflare/computer as an open-source preview in early August. The package gives a Durable Object a SQLite-backed virtual filesystem and a common execution surface that can target a full Linux container, a lightweight Worker shell, or an isolated JavaScript runtime. The same workspace can therefore persist while the compute used to act on it changes.

That makes the project more interesting than its tagline suggests. Cloudflare is not only trying to give agents “a computer.” It is testing whether an agent’s durable unit should be the workspace rather than the machine currently running commands against it.

The computer is split into state and execution

In Cloudflare Computer, Workspace.fs is backed by the Durable Object’s own SQLite storage. Files written through the workspace API remain durable across Durable Object restarts. Execution sits beside that filesystem rather than defining it.

This distinction matters because an agent’s working state often has a much longer useful life than any individual process. A coding agent may create notes, modify files, clone repositories, produce artifacts and return to the same task hours later. If that state belongs to a container’s local disk, container lifecycle and agent lifecycle become tightly coupled.

Cloudflare instead makes the Durable Object the authoritative store. When the container backend is used, the container gets an in-memory virtual filesystem exposed through FUSE. That mirror is process-lifetime state: it disappears if the container restarts. The Durable Object’s SQLite store survives, and the synchronization protocol can rebuild the container-side view from that durable source.

The architecture therefore treats a machine as something that can be reconstructed around persistent state, rather than treating the machine itself as the persistence boundary.

One workspace can choose among three kinds of compute

The current package ships three execution backends. The container backend provides a full Linux userland with real binaries, package managers, Node and network access. The Worker shell runs shell commands through just-bash inside a Dynamic Worker. The Worker JavaScript backend evaluates ECMAScript modules in a fresh Dynamic Worker with structured inputs and results.

All three are reached through the same workspace.runtime.exec() entry point. The selected backend changes what the source means — a shell command for the container and Worker shell, a JavaScript module for the JavaScript backend — but the workspace remains the shared state boundary.

That creates a useful scheduling question for an agent system: what is the cheapest execution environment that can safely complete this step? Reading or editing a file does not require booting a Linux environment. Lightweight parsing or data manipulation may fit an isolate. Installing native dependencies or running an arbitrary toolchain may justify a container.

Cloudflare’s own launch description frames the project around that choice, dynamically moving between efficient isolates and full Linux containers so workloads can use the appropriate compute primitive. The architectural bet is that a long-running agent should not have to choose one execution model forever simply because its files live there.

Disposable compute changes what “resume” means

Long-running agents make failure and resumption normal rather than exceptional. Processes are killed, isolates are evicted, containers restart, deployments roll forward and network sessions break. If the agent’s important state is durable independently of those events, recovery can focus on reconnecting execution rather than recreating the entire working environment from memory or conversation history.

Cloudflare’s lifecycle documentation is explicit about the asymmetry. A Durable Object incarnation can disappear while its committed SQLite storage remains. A container can restart and lose its in-memory mirror while the Durable Object retains the workspace. If both processes die, the durable store is still the piece designed to survive.

The project also persists synchronization watermarks so the two sides can reconcile what has been pushed or fetched. That matters because “persistent filesystem plus replaceable container” is only useful if reconnecting does not silently lose or duplicate state.

There is a harder boundary around command execution. Filesystem synchronization can be designed to be idempotent, but shell commands may have side effects that are unsafe to replay. Cloudflare’s current lifecycle logic distinguishes failures that can be retried from ambiguous command dispatches where the system cannot know whether execution already began. That is an important reminder that durable state does not automatically make arbitrary agent actions durable.

The filesystem abstraction has a real performance cost

Separating durable state from the container also means the container is not simply writing to a normal local disk. The container backend mounts the workspace through FUSE and synchronizes it with the Durable Object. Cloudflare’s own benchmark shows that the tradeoff depends heavily on workload shape.

In the published benchmark, metadata-heavy operations such as directory traversal, stat, remove and some Git operations can match or beat the container’s ext4 disk. Large sequential reads and writes are much worse. A full npm install of Cloudflare’s sandbox SDK took 124.7 seconds through the computerd mount versus 63.9 seconds on the container’s ext4 disk in the same benchmark.

The package documentation consequently recommends agent-scale workspaces rather than full monorepos and lists roughly 10 GB as the workspace limit. That narrows the strongest use case: a persistent working directory for agent tasks, not a transparent replacement for every high-throughput filesystem workload.

This is not a production-ready agent operating system

Cloudflare is unusually direct about the project’s maturity. The repository and package documentation label Computer as preview-only, say its APIs are unstable and explicitly state that it is not suitable for production use yet.

Some lifecycle work is unfinished as well. The project’s lifecycle specification says the Durable Object does not yet use the hibernatable WebSocket path described in its forward-looking design, which means part of the intended idle-lifecycle story is still future work. The specification itself warns readers to distinguish design intent from shipped behavior.

Those limitations are not peripheral. They define what Cloudflare Computer is today: an architectural preview showing how state, execution and recovery might be separated, rather than a finished general-purpose runtime that developers can safely drop under production agents.

The durable unit of an agent may be getting smaller

The broader agent stack is steadily being decomposed. Models can be swapped behind a harness. Capabilities can be exposed through shared protocols. Cloudflare Computer pushes the same separation into infrastructure: persistent workspace state does not have to belong to the process or container currently executing the task.

That can make compute more disposable in two senses. An agent can recover from a failed environment without treating the environment as its identity, and it can choose a lighter runtime when the task does not justify a full machine. The container becomes one tool available to the workspace rather than the workspace itself.

Cloudflare still has to prove that the synchronization complexity, FUSE overhead and lifecycle machinery are worth that abstraction in real agent systems. But the project identifies a useful boundary: an agent may need durable memory and files for far longer than it needs any particular computer.

If that boundary holds, the infrastructure question changes. Instead of asking how to keep an agent’s container alive indefinitely, developers can ask what state actually needs to survive — and then treat the machine that acts on it as replaceable.