First Checkpoint: What Does “Durable” Really Mean?
Cloudflare Computer’s value depends on using the word “durable” precisely. The Durable Object’s SQLite-backed Workspace is durable in one sense, while a container mirror, a capnweb session, a running process, and a post-command synchronization step have different lifetimes. This checkpoint connects the ownership and synchronization models so a reader can classify state by where it lives and how it recovers, then use that classification to judge which execution backend belongs around the Workspace.
The important shift is from asking whether a task “finished” to asking which result finished. An agent can receive a successful command result while the files produced by that command are still waiting to reach the Durable Object. A transport can disappear while the DO’s committed data remains safe. Two containers can each complete their own writes while the shared path ultimately keeps only one version. These are not contradictions once the boundaries are visible.
Durability is a map of owners and checkpoints
There are four useful places to look when an agent runs against Cloudflare Computer:
| Location | What it contributes | What it does not guarantee |
|---|---|---|
| Durable Object SQLite | Authoritative committed filesystem state, revisions, sync watermarks, and Workspace metadata | That every running container or process has already seen the latest state |
| Container-side VFS | A local-looking filesystem for Linux commands, with FUSE and computerd |
Persistence across a container restart when the store is process-lifetime or unsynced |
| Capnweb WebSocket | A live transport for filesystem changes, objects, and execution events | Durability of its in-memory streams and tables after the socket dies |
| Command process and execution log | Process effects, output, timeout, signals, and bounded replay data | Rollback of filesystem or external effects that already happened |
The first row is the anchor. A committed write through the Workspace has a durable home in the Durable Object’s SQLite storage. The other rows describe ways to use, move, or observe that state. They do not replace the anchor.
A container-backed task passes through several checkpoints. The DO commits the files it already owns. A push applies those files to the container and returns an acknowledgment. The command then reads and changes the container-side view. A pull applies those changes to the DO and advances a cursor. If any step fails, the right recovery depends on which checkpoint was reached.
The diagram deliberately treats “container dirty” as a real state, not as an error. A live command is allowed to create a newer container-side view. The state becomes authoritative only when the pull applies it. If the process dies first, the DO can rebuild its mirror from what it already knows, but it cannot recover a container-only write that never crossed the boundary.