Cloudflare has introduced an early preview of @cloudflare/computer, an open-source runtime designed to give AI agents a persistent workspace while directing different tasks to different execution environments.
Cloudflare Computer separates an agent’s persistent files from the environment used to execute each task. The files remain in a shared workspace, allowing lighter operations to run in an isolate while work that requires Linux utilities, package managers, or native binaries is sent to a connected container.
Cloudflare announced the package on August 3 as an early preview. Its current documentation describes unstable APIs and says the software is intended for experiments and prototypes, not production deployments. General availability, final pricing, regional availability, and production service limits have not been announced.
What Cloudflare Computer Actually Provides
The center of Cloudflare Computer is a Workspace that can be created on a Durable Object. According to the project’s official repository, the authoritative filesystem state is stored in SQLite inside that Durable Object. Files can therefore persist across restarts instead of belonging only to a short-lived execution process.
Persistent storage allows an agent to continue multi-step work even when the environment running a particular task stops or changes. The workspace becomes the stable layer, while execution is attached when a task requires it.
Cloudflare’s current repository lists three backends:
- A container backend with a full Linux userland and access to native binaries.
- An isolate shell backend that runs just-bash in a Dynamic Worker.
- An isolate JavaScript backend that runs an ECMAScript module in a fresh Dynamic Worker.
All three use the workspace as the common source of files. Developers can also construct a workspace without an execution backend when they only need filesystem operations.
The package includes AI SDK-compatible tools for reading, writing, editing, listing, and executing against workspace files. Cloudflare says these operations can be gated, audited, and observed, giving developers a record of the agent’s actions and control over what it may change.
How Work Moves Between Isolates and Containers
The runtime exposes a common execution entry point, while the selected backend determines how the command runs. An isolate can handle work that fits a lightweight JavaScript environment, such as manipulating files or running supported shell logic. The container option is reserved for operations the isolate cannot complete, such as installing an npm dependency, launching a test suite, or calling a native executable.
Inside the container, a FUSE layer, short for Filesystem in Userspace, makes the workspace’s stored files available to running processes. Changes made inside the container are synchronized back to the authoritative workspace. The isolate shell reaches the workspace through Workers RPC, while the isolate JavaScript backend receives workspace-backed filesystem access.
This architecture does not eliminate containers. It makes them one execution option rather than the permanent home of the complete agent. A bug-triage agent, for example, could store a report and repository in the workspace, use an isolate for basic inspection, and invoke a container only for a build or test that needs a full Linux toolchain.
Cloudflare’s announcement groups the available choices into two broad categories: isolates and containers, while the latest repository documentation separates isolate execution into shell and JavaScript backends. The announcement also refers to browser environments, but developers should not read that reference as confirmation that a browser backend is production-ready. The repository’s current shipping list names the two isolate backends and the container backend.
Why Cloudflare Is Challenging the Container-Only Model
Cloudflare argues that assigning a container to every agent will consume more CPU capacity than large-scale agent services can sustain. It presents isolates as a faster and less resource-intensive option for horizontally distributed work, with containers available for heavier tasks.
That scaling argument remains a company position, not an independently demonstrated result for Cloudflare Computer. The company says frontier models in its testing selected the appropriate runtime effectively, and it has set a goal for agents to need a container for less than 10% of their work. Cloudflare has not published independent benchmarks in the announcement showing cost, latency, task success, or resource use against container-only agent systems.
The architecture may offer practical benefits regardless of whether Cloudflare’s broader predictions about computing demand prove accurate. Separating durable state from execution can reduce the need to keep a heavy environment alive between tasks. It can also give developers a consistent file layer while allowing each operation to use an environment suited to its requirements.
Cloudflare is positioning its network as an execution and security layer for newer workloads. A separate example is its recent work on post-quantum authentication for origin servers. The technologies solve different problems, but both show the company moving more application state, policy, and infrastructure functions into its platform.
The Early Preview Has Practical Limits
The clearest reason for caution comes from the project’s own documentation. The repository says the APIs are unstable and the design can change. It also warns that technical specifications in the documentation are forward-looking and may describe intended behavior rather than what the code currently supports.
The package documentation identifies several current constraints. A workspace has an approximate 10GB maximum because it shares storage with the Durable Object. The container-side filesystem is held in memory, which makes very large directory trees a poor fit. FUSE access can also impose a measurable performance cost on input/output-heavy jobs such as large package installations or archive extraction.
Those limits suggest the preview is aimed at compact, task-focused agent workspaces rather than large monorepositories or sustained production workloads. Before testing the package, teams should define what the agent may change, which external services it can reach, how installed software is controlled, what activity is recorded, and how interrupted work can be restored. A shared filesystem makes coordination easier, but it does not remove the need to constrain what an autonomous agent can execute or modify.
What Developers Should Watch Next
Cloudflare Computer is available now for experimentation through the open-source repository and can be installed as the @cloudflare/computer package. That availability should not be confused with a generally available managed service or a production-readiness commitment.
The next meaningful signals will be a stable API, documented pricing, production limits, regional support, independent performance testing, and clearer status for browser-based execution. Developers considering the preview today should test it with a small, reversible workload and verify which capabilities exist in the current code rather than relying only on forward-looking specifications.
The package’s strongest immediate contribution is not the claim that agents no longer need containers. It is the attempt to make persistent files and multiple execution environments look like one workspace. Whether that abstraction can deliver Cloudflare’s promised efficiency at production scale remains the question the preview must answer.
