The Boundary Map: Choosing Where Cloudflare Computer Fits

Cloudflare Computer fits best when an agent needs a durable working set and several carefully chosen ways to operate on it—not when the goal is to replace every local disk, process supervisor, or collaboration system. The final judgment rests on one relationship: a Durable Object owns the authoritative SQLite-backed Workspace, while Worker and container runtimes add different kinds of computation around that state. This conclusion connects workload shape, backend choice, coordination, authority, lifecycle, and performance so an adopter can decide what the system can responsibly support today.

The strongest accurate description is therefore narrower than “a computer in the cloud.” Cloudflare Computer is a durability-aware execution substrate for agent work. It makes files persistent and inspectable inside a Durable Object, then offers a fast text runtime, a structured module runtime, or a full container environment when the task needs one. The design is valuable because it separates those concerns. The same separation also creates boundaries that an adoption decision must not hide.

The center of fit is durable agent work

An agent-scale working set has a recognizable shape. It contains source files, notes, configuration, intermediate results, repository metadata, and generated outputs. The agent repeatedly inspects a small part of the tree, makes targeted edits, runs checks, and hands off a result. The important operations are often metadata-heavy: resolving paths, listing directories, finding files, grepping text, checking status, and updating a limited number of files.

That shape aligns with Cloudflare Computer’s strongest design choices. The Workspace gives the Durable Object a durable namespace and a SQLite-backed store. Files are represented as metadata plus fixed content chunks, so repeated content and unchanged chunks can be reused. Reads and writes can stream, and the model-facing tools can page through a tree or continue a long file read without transferring everything at once. A container can use the same tree through FUSE when a native tool is genuinely necessary.

The system is particularly well suited to an agent that needs continuity without a permanently running full machine. A conversation can end while the Workspace retains the files the agent created. A later operation can inspect a diff, continue from a saved artifact, or run a different backend against the same state. The Durable Object is not merely a database hidden behind a shell; it is the stable place where the agent’s working context becomes inspectable and reusable.

That does not make every filesystem workload a good fit. The content-addressed chunk path hashes and stages fixed 512 KiB windows. The same work that enables selective synchronization and deduplication adds overhead to large sequential reads and writes. A design optimized for an agent repeatedly touching many small, meaningful files should not be evaluated as though it were a high-throughput data plane.

The repository’s performance report makes that distinction concrete. In its fs-bench measurements, computerd performed well relative to an ext4 disk baseline on several metadata-oriented operations, including directory traversal, stat, removal, Git initialization, and shallow clone. The report also shows the opposite result for large sequential I/O: reading, writing, or copying a 64 MiB file through the FUSE path was far slower than tmpfs and slower than the container’s ext4 disk. The reason is architectural, not mysterious: each changed window is hashed into the content-addressed store, and FUSE adds another boundary around the operation.

A full package installation is an even more revealing test. The reported cloudflare/sandbox-sdk install took 124.7 seconds on the computerd FUSE mount, compared with 63.9 seconds on ext4 and 34.3 seconds on tmpfs. That does not prove that every installation will have the same ratio, but it does establish the direction of the trade. Heavy dependency installs and large extraction workloads can make the FUSE and chunking costs visible enough to dominate the convenience of a durable mirror.

The right question is consequently not “Is Cloudflare Computer fast?” It is “Which part of this workload is the system being asked to optimize?” For repeated metadata work and incremental agent edits, the durable Workspace model may be the main value. For sustained sequential bytes, native disk or an object-storage pipeline may be the more appropriate center of gravity.

Choose the smallest capable execution path

The runtime choice should follow the operation’s actual requirement. A restrained agent can use the dedicated Workspace tools for reading, listing, searching, editing, and writing. It can try the Worker shell for supported text commands. It can use Worker JavaScript for structured module logic with bounded host capabilities. It can escalate to a container when the task requires real Linux behavior.

The Worker shell is the default candidate for text-oriented work. It runs just-bash in a Dynamic Worker and calls the host Workspace directly, so it does not create a second filesystem store or require a container synchronization round trip.