A Durable Workspace for Agent Work
Cloudflare Computer is a preview system for giving an agent a persistent working environment inside a Durable Object. This opening focuses on the relationship that makes the project intelligible: a Durable Object owns a SQLite-backed Workspace, while different execution backends use that Workspace with different levels of speed, Linux compatibility, isolation, and recovery. The practical question is not simply whether an agent can run code, but which kind of execution should surround one durable center.
That distinction matters because agent work is rarely one operation. An agent may receive a repository, inspect several files, make a small edit, run a test, keep an intermediate result, and return a generated artifact. The work needs a place where files remain visible across calls and can be inspected or revised. It also needs an execution environment, but the environment suitable for a quick text transformation is not necessarily the one suitable for a native compiler or a package manager. Cloudflare Computer treats those as related problems, not as one problem with one universal answer.
The agent’s problem is not lack of compute
A useful working directory gives an agent continuity. It can hold source material, notes, generated files, and state that would be awkward to carry through every model interaction. It also creates a boundary that people and tools can inspect: a file can be read, edited, searched, tested, or shared without reconstructing the entire history of a conversation.
But an ordinary temporary directory is a poor foundation for durable agent work. It belongs to a process or a machine, and either may disappear when the request ends or the runtime is replaced. Cloudflare Computer moves the center of gravity into the Durable Object. Its Workspace is backed by the object’s SQLite storage, so committed filesystem state belongs to the object rather than to one particular command process.
The project is explicit about its maturity. @cloudflare/computer is preview-only, its APIs are unstable, and the repository says it is not suitable for production use at this time. That warning is not a footnote to be removed once the architecture looks attractive. It changes the kind of judgment the system supports today. The repository can show how the design works and where it is useful; it cannot turn a preview into a production guarantee.
The Workspace may also exist without an execution backend. In that form it is a filesystem service: an application can persist and inspect files in the Durable Object without starting a shell or a container. This is an important clue about the design. Execution is valuable, but it is not the definition of the Workspace. Durable state comes first.
One Workspace, different execution realities
The simplest mental model is a three-part relationship. The Durable Object owns the authoritative SQLite-backed filesystem. The Workspace exposes that state to application code and agent tools. An execution backend supplies a place where commands or modules can run against it.
With a container backend, the relationship has an additional layer. The container runs computerd, which exposes the Workspace tree through a FUSE mount. A command inside the container can therefore use ordinary Linux paths and tools while the Durable Object remains the durable owner of the corresponding state. The container is not merely a remote terminal, and it is not the source of truth: it is a live execution-side mirror connected to the Workspace.
The Worker backends use a different arrangement. The Worker shell runs the just-bash interpreter in a Dynamic Worker and forwards filesystem operations to the host Workspace over Workers RPC. The Worker JavaScript backend evaluates a module in a fresh Dynamic Worker and likewise reaches host-owned capabilities through a bridge. Neither needs a second filesystem store or a container synchronization round trip. The same durable SQLite store remains at the center, but the path from code to that store is shorter.
This arrangement explains why the project can offer multiple backends under stable identifiers. The backends are not competing owners of the files. They are different ways to spend execution resources around one Workspace. It also explains why the one-to-one Durable Object/container relationship matters: the container mirror, its revision state, and its capnweb session have one obvious counterpart. The design is easier to reason about because the durable object is not casually sharing one mirror among unrelated sessions.
The asymmetry is just as important as the picture. A container-side write can be newer than the DO-side copy while a command is running. It becomes part of the authoritative Workspace only when the post-command pull or an explicit synchronization operation applies it. If the container process dies before that happens, the container-only write may be lost. “The Workspace is durable” therefore does not mean “every process-local state is durable at every instant.” It means the committed state owned by the Durable Object has a durable home, while other copies must cross a defined boundary before they share that guarantee.
What changes when the environment changes
The container backend buys breadth. It is intended for work that needs a real Linux userland, native binaries, package managers, or process behavior that an interpreter inside a Worker cannot reproduce. That breadth comes with a container lifecycle, a mirrored filesystem, a synchronization protocol, and the overhead of presenting durable state through FUSE. The container is the broadest execution option, not the default definition of all agent work.
The Worker shell makes the opposite trade. It starts without a container and is well suited to reading, searching, filtering, and transforming text with just-bash commands. Because its filesystem calls return to the host Workspace, it avoids the second-store problem. But it is not full Linux: a command available on a normal machine may simply not exist in the just-bash environment. The fast path is useful precisely because it declines to simulate every property of a machine.
Worker JavaScript changes the source language as well as the environment. The input to workspace.runtime.exec() can be an ECMAScript module rather than a shell command, and a callable module can accept structured input and return a structured value. Its filesystem and other trusted capabilities remain host-mediated rather than becoming arbitrary access to the Durable Object’s environment. This makes it a better fit for bounded programmatic operations than for pretending that a general-purpose server process has appeared inside the Worker.
The public runtime surface unifies how an application asks for execution, not what the execution means. The selected backend determines whether the source is shell syntax or module source, what lifecycle can be retained, and how much authority or environment is available. A single method name is therefore a routing convenience, not a promise that all backends have the same capabilities.
That is why backend selection belongs close to the workload. A short text search may not justify a container. A native build may not fit a Worker shell. A structured transformation with a narrow file scope may be clearer in Worker JavaScript than as a shell pipeline. The useful question is conditional: what must this operation do, and which backend supplies exactly that capability without adding an unnecessary state copy or authority?
The judgment hidden inside “durable”
The word “durable” often compresses several separate questions:
- Who owns the committed state?
- Which copy does the next execution read?
- When does a remote write become part of the authoritative tree?
- What can be replayed after a transport failure?
- Which process, stream, or external effect is outside the filesystem’s durability boundary?
Cloudflare Computer’s architecture gives a clear first answer: the Durable Object’s SQLite-backed Workspace is the stable center. It does not give the same answer to every other question. A container mirror has to synchronize. A Worker shell shares the host store directly but gives up Linux breadth. A module runtime can be bounded and structured, but it is not a long-lived native process. The meaning of a successful operation depends on which path carried it out.
This also makes the project more than a list of APIs. Its central design problem is how to let an agent work with files across changing execution contexts without confusing convenience with ownership. The filesystem, the runtime router, and the container bridge are valuable because they preserve different parts of one relationship: durable state stays in the Durable Object while execution can be selected, replaced, or constrained around it.
The repository’s broad performance guidance points in the same direction. The system is aimed at agent-scale working sets and metadata-heavy activity, not at being a drop-in replacement for a high-throughput local disk or a shared data-processing filesystem. Runtime breadth, storage size, startup time, synchronization cost, and recovery expectations all belong in the same decision. There is no honest answer that considers only whether a command can technically run.
The next fact to establish is what the Workspace actually persists. Once paths, metadata, and file bytes are separated, the later synchronization behavior becomes much less mysterious: the system is not copying an abstract “disk,” but maintaining a durable tree whose pieces have distinct owners, identities, and costs.