Cloudflare Computer Splits the Agent Computer Across Isolates and Containers

Cloudflare released Cloudflare Computer as an open-source preview on August 3, 2026, offering agents one persistent workspace across three execution backends. The conflict sits inside that design. Developers can route simple work through lightweight Workers isolates and reserve Linux containers for heavier jobs, but the project is explicitly not production-ready.

That distinction matters because agent infrastructure has been moving toward full, isolated machines. Cloudflare Computer tests a different assumption: an agent needs the capabilities of a computer, but every action does not require the same computer runtime. Its files can persist separately from the environment executing each command.

The result pressures providers that treat a sandbox, container, or microVM as the basic unit of an agent session. It also challenges Cloudflare’s existing Sandbox SDK to justify when developers need a dedicated container. The preview is less a finished product than a public argument about how agent computing should be divided.

Cloudflare Computer Separates Files From Execution

The central change is architectural: an agent’s workspace no longer belongs to one running container.

According to the project’s open-source repository, Cloudflare Computer stores its authoritative virtual filesystem inside a Durable Object. A Durable Object is a stateful Cloudflare component with private, persistent storage and a single coordination point.

SQLite holds that filesystem state. Execution happens elsewhere through a shared interface called workspace.runtime. The agent can read and modify the same files even when different backends perform its commands.

Three backends ship in the preview. The container backend provides a complete Linux userland with real binaries, package managers, and network access. A Worker shell backend runs shell-like commands through just-bash inside a Dynamic Worker. The third backend evaluates JavaScript modules inside fresh Dynamic Workers.

Developers can register more than one backend for a workspace. Each receives a stable identifier, while workspace.runtime.exec() becomes the common entry point. A caller can select a backend directly, or an agent framework can choose based on descriptions supplied by the developer.

That arrangement turns the filesystem into the stable center of the session. Compute becomes replaceable. A lightweight command can run in an isolate, while a package installation or native build can move to Linux without creating a separate logical workspace.

Cloudflare calls the package a persistent, SQLite-backed virtual filesystem with pluggable execution. Its package documentation describes a roughly 10 GB limit per workspace. The storage shares the limits of its Durable Object.

The package also works without any execution backend. An application can use only the durable filesystem, then add execution when its workflow requires it. That makes the storage model more than a supporting feature for a sandbox.

The public API resembles familiar Node.js filesystem operations. It includes functions for reading, writing, listing, removing, and searching files. Strings use UTF-8 by default, while binary data can move through byte arrays or streams.

Container access requires another layer. A daemon named computerd runs inside the sandbox and exposes the persistent workspace as a FUSE mount. FUSE lets a user-space process present files through a normal filesystem interface.

The daemon synchronizes changes with the authoritative Durable Object through an RPC channel. That gives Linux tools a conventional directory while keeping SQLite outside the container as the source of truth.

The isolate backends take a shorter route. Their filesystem operations call the same Durable Object over Workers RPC, so they avoid maintaining a second store. They also avoid the synchronization step required after container work.

This is what makes the announcement more than another code-execution service. Cloudflare Computer decomposes the familiar computer into persistent files, selectable execution, synchronization, and publishing helpers. The agent still sees one workspace, although the infrastructure underneath can change from command to command.

Why Agents No Longer Fit One Runtime

Agent workloads mix small file operations with occasional system-level work, making one fixed execution environment an inefficient default.

A coding agent rarely performs one uniform job. It may inspect a configuration file, search a repository, edit several lines, run tests, install a dependency, create an image, and publish an artifact. Those actions have different runtime requirements.

Reading a file does not require a complete Linux container. Neither does parsing text or evaluating a controlled JavaScript module. Native compilation, package installation, and operating-system tools usually do.

Traditional remote sandboxes package those needs together. The sandbox provides a filesystem, shell, processes, and network access within one environment. That model is easy to understand, but it ties persistence and execution to the same lifecycle.

Cloudflare’s earlier Sandbox SDK follows much of that model. The company made Sandboxes generally available on April 13, 2026, after first presenting them nine months earlier as command and filesystem environments.

By general availability, each Sandbox had become a development environment with a terminal, background processes, file watching, live preview URLs, egress controls, and snapshots. Cloudflare said standard accounts could run 15,000 concurrent lite instances, 6,000 basic instances, and more than 1,000 larger instances.

The company also shifted Sandboxes to active CPU billing, so idle waits do not consume paid CPU time. That change addressed one cost of long-running agent sessions. It did not erase the architectural difference between starting a container and running code in a lightweight isolate.

Cloudflare Computer turns that difference into a routing decision. Backends connect lazily, which means they initialize when work first reaches them. A workflow can begin with files and an isolate, then reach for Linux only when a command genuinely needs it.

The strategy mirrors Cloudflare’s broader position that agent workloads require several compute scales. Its Agents Week recap argued that some agents need complete operating systems while most tasks need lighter environments that start in milliseconds.

Cloudflare Computer gives that claim a concrete programming model. It does not ask developers to move files manually between unrelated services. The workspace provides continuity while the execution boundary changes.

For framework authors, that continuity is important. An agent can receive standard tools named read, write, edit, ls, and exec. The package offers adapters for AI SDK applications, while the developer describes what each backend can handle.

A model can then send fast text operations to an isolate and heavier commands to a container. This makes backend selection part of the agent’s tool policy. It also creates a new failure mode if those descriptions are unclear or the model chooses poorly.

The design is especially relevant for agents that pause frequently. Model inference, human approval, network requests, and external API calls create idle gaps. Keeping a complete environment active through every gap may provide convenience, but it is not the only way to preserve the agent’s work.

A durable filesystem lets the execution layer disappear without erasing session state. The next action can reopen the same files through another backend. This resembles a computer from the agent’s perspective, even though no single machine owns the full session.

That abstraction places pressure on container-first providers, but it does not eliminate their strongest argument. A complete isolated environment offers predictable tools, familiar debugging, and a consistent security boundary. Splitting a session across runtimes adds coordination and synchronization concerns.

It also places pressure on Cloudflare’s product boundaries. Developers must understand whether they need Sandbox SDK, Cloudflare Computer, Dynamic Workers, or a combination. A preview package can explore overlap, but a production platform eventually needs a simple answer.

The likely answer is workload-dependent. Cloudflare Computer favors agents that perform many small operations and occasionally require Linux. A container remains clearer when nearly every step depends on native tools, extensive local dependencies, or high-throughput disk access.

That is the real stakes question. The preview asks whether the unit developers should provision is a machine, or a workspace capable of borrowing different machines.

How Cloudflare Computer Routes One Workspace Across Three Backends

Cloudflare Computer gains flexibility by making runtime selection explicit, but every backend carries a different capability and synchronization profile.

The Worker shell backend is the lightest path for familiar commands. It uses just-bash, a TypeScript implementation of a Bash-like environment designed to run without spawning operating-system processes.

That backend can handle text-oriented shell work against the durable workspace. It does not need Docker or a Cloudflare Container. File operations return to the Durable Object, keeping the authoritative state in one place.

The Worker JavaScript backend handles ECMAScript modules instead of shell commands. Each execution runs inside a fresh Dynamic Worker and can accept structured input or return structured results. It supports workspace-backed file access and configured libraries.

Cloudflare also provides trusted modules for Git and Cloudflare Artifacts. Git operations can run through an isomorphic-git client directly against the virtual filesystem. They do not require a container or conventional Git binary.

The container backend covers the tasks isolates cannot. It supplies Linux, native binaries, Node.js, npm, networking, and other operating-system capabilities. The workspace appears inside it through the computerd FUSE mount.

This backend creates the hardest data problem. Cloudflare must project the SQLite-backed state into a container, allow conventional tools to modify it, and synchronize those changes afterward. The package maintains independent synchronization cursors for each registered backend.

If a command succeeds but the post-command pull fails, the execution result can report a pending synchronization state. Applications can configure retries with bounded exponential backoff. However, the library does not take ownership of the Durable Object’s alarm scheduling.

That detail reveals how much responsibility still belongs to the developer. A user sees one workspace, but the application must handle backend registration, retry scheduling, execution lifecycle, and unresolved synchronization.

The design also requires disciplined resource disposal. The RPC layer does not automatically collect remote stubs. Long-lived sessions that repeatedly acquire workspace or execution handles can accumulate them unless the application disposes of each handle.

Cloudflare documents debugging support for detecting those leaks. Still, this is preview-era infrastructure, not an invisible platform service. Developers experimenting with it need to understand the plumbing.

File publishing introduces another boundary. The package can upload a workspace file to R2 and return a presigned link. It can also connect a session to Cloudflare Artifacts, a Git-compatible storage service for code and build outputs.

One included tutorial demonstrates the intended division. An agent writes a Markdown recipe card in its workspace, then uses pandoc inside a container to create a PDF. Storage stays durable while a Linux tool handles the format conversion.

Another example sends image generation to Workers AI, writes the result into the workspace, and returns a shareable asset. A comparison interface runs the same task through container and Worker runtimes side by side.

Those examples point to a broader agent pattern. The workspace becomes a shared workbench, while different runtimes act like specialized tools. The agent does not need to treat every backend as a separate computer.

The mechanism can also support knowledge-intensive development. An engineering team might keep task files, generated reports, and test outputs in the workspace, then copy durable outcomes into a searchable knowledge base. The runtime remains temporary, while useful work becomes accessible beyond the agent session.

Yet the abstraction has limits. The container-side filesystem is held in memory, and Cloudflare recommends agent-sized workspaces rather than full monorepos. A roughly 10 GB ceiling is substantial for documents and small projects, but it does not make the service a general replacement for development disks.

The worker backends also require experimental Cloudflare features and a Worker Loader binding. The package itself requires the nodejs_compat compatibility flag. Those requirements reinforce its preview status.

The most important point in this Cloudflare Computer explained analysis is not that isolates replace containers. They do not. The mechanism lets an application decide when a container is worth its startup, capability, and synchronization costs.

That choice can happen at the application layer or through an agent framework. The model sees backend descriptions and can choose a destination. Developers therefore need policy controls, not only natural-language hints.

A production system would likely restrict which commands, files, networks, and credentials each backend can access. It would also need reliable records showing why a command reached a particular runtime. The current repository exposes observability hooks, but it does not settle the full governance problem.

Cloudflare Computer is most convincing when the work naturally divides. Search and edit in an isolate, compile in Linux, then publish through an artifact service. Its advantage becomes less clear when every action needs the container or when a task moves large files repeatedly.

Preview Warnings and Benchmarks Complicate the Pitch

The repository supplies unusually direct limits, including an explicit production warning and benchmarks showing a major penalty for large sequential file operations.

Cloudflare says the package is suitable for experiments, exploration, and prototypes. It says the APIs are unstable, the design can change, and the package is not suitable for production use.

That warning should frame every claim about what is Cloudflare Computer today. The repository contains working packages, examples, and hundreds of commits, but parts of its design documentation are forward-looking. Cloudflare tells readers to treat those specifications as intent rather than a description of current code.

Performance is the clearest tradeoff. The company benchmarked computerd on a standard container with one virtual CPU, 6 GiB of memory, and 12 GB of disk. It compared the FUSE workspace with an in-memory filesystem and the container’s ext4 disk.

The results favor the virtual filesystem for several metadata-heavy operations. Removing 1,000 files took about two-thirds of the ext4 time. Creating a nested directory tree took roughly three-quarters. Finding that tree also took roughly three-quarters.

A Git initialization and commit involving 100 files took 459.2 milliseconds on computerd, compared with 635.4 milliseconds on ext4. A shallow clone of a roughly 1 MB repository took 549.1 milliseconds, compared with 576.2 milliseconds on disk.

Large sequential operations produced the opposite result. Writing a 64 MiB file took 230.6 milliseconds on computerd, compared with 16.8 milliseconds on ext4. Copying the same amount took 1,037.2 milliseconds, compared with 39.8 milliseconds.

A pure 64 MiB read was about 30 times slower than the disk baseline. A pure copy was more than 41 times slower. Those gaps matter for archives, dependency trees, media, model files, and data-processing workloads.

Cloudflare’s filesystem benchmarks explain the mechanism behind the slowdown. The write path hashes 512 KiB chunks into a content-addressed blob store. That supports deduplication and syncing only changed chunks, but it adds work to raw throughput operations.

A complete installation of Cloudflare’s Sandbox SDK made the cost more concrete. The test covered 854 packages and 36,675 files. Installation took 124.7 seconds on the FUSE workspace, 63.9 seconds on ext4, and 34.3 seconds in memory.

Cloudflare characterizes ext4 as the more realistic general-use baseline. Against that baseline, the FUSE installation took roughly twice as long. Developers building dependency-heavy JavaScript projects will notice that difference.

The benchmarks do not invalidate the design. Many agent tasks involve metadata, small edits, searches, and incremental changes rather than sustained sequential I/O. The results instead define where backend routing matters.

A sensible workflow might keep source files in the persistent workspace while avoiding repeated extraction of large archives. It might cache dependencies elsewhere or choose tasks whose value outweighs synchronization overhead. Cloudflare has not yet established the best production patterns.

Security presents a second uncertainty. The repository describes execution surfaces and storage behavior, but it does not claim that all three backends provide identical isolation. A JavaScript isolate, a shell implemented in TypeScript, and a Linux container are fundamentally different execution environments.

The Worker shell gains speed partly because it is not a full operating system. That limits its compatibility, but it can also narrow what commands can do. The container provides broader capability and therefore demands stronger controls around network access, packages, and credentials.

Moving between those environments can create policy gaps. A command rejected in one backend might run in another. An agent might choose Linux because its description promises greater capability, even when the task does not require it.

The package includes observer hooks for workspace connection, synchronization, execution, and filesystem operations. Those hooks can feed Cloudflare tracing or another recorder. They are useful foundations, but production users will need authorization rules and auditable backend-selection policy.

Persistence introduces its own security questions. Files survive Durable Object restarts, which is the feature agents need for long tasks. Persistent workspaces can also retain sensitive prompts, source code, generated credentials, or downloaded data longer than intended.

Applications need deletion policies and tenant separation that match their risk. Read-only R2 mounts help protect reference data, but they do not answer every question about data retention or outbound access.

The GitHub response offers an adoption signal, not production evidence. The repository displayed about 3,100 stars and 141 forks on August 6. Those numbers show developer curiosity after the announcement, especially given its position on GitHub Trending.

They do not establish reliability, security, or sustained use. Stars can accumulate rapidly around a compelling architecture. Real validation will come from workloads that run for weeks, recover from partial failures, and preserve files consistently across runtime changes.

Cloudflare’s transparency helps here. Publishing unfavorable I/O numbers gives developers a better basis for experiments. The explicit warning also prevents the trending rank from being mistaken for a general-availability launch.

The cautious conclusion is straightforward. Cloudflare Computer offers a credible mechanism for separating agent state from execution, but the preview has not proven that the extra coordination beats a dedicated sandbox in production.

What Developers Should Watch After the GitHub Surge

The next phase depends on three signals: API stabilization, real workload evidence, and enforceable policies for backend selection.

The first signal is a versioned, production-oriented release. Cloudflare Computer currently presents unstable APIs and experimental backend requirements. A move toward a stable interface would show that Cloudflare has resolved the ownership boundaries among Computer, Sandbox SDK, Dynamic Workers, and Durable Objects.

That release should clarify recovery behavior. Developers need predictable outcomes when a container command finishes but synchronization fails. They also need guarantees for concurrent access, cleanup, storage limits, and long-running RPC sessions.

If Cloudflare publishes a stable release with migration guidance, the architectural argument becomes stronger. If the APIs churn or the package remains an experiment, teams will keep treating the repository as design research.

The second signal is evidence from complete agent workloads. Microbenchmarks already show where FUSE performs well and where it struggles. The harder question is whether routing commands across isolates and containers improves total task time, reliability, or resource use.

Useful evaluations would compare identical coding, research, and data-analysis agents. They should measure startup delay, execution duration, synchronization failures, storage transferred, and successful task completion. A raw filesystem benchmark cannot capture those combined effects.

The examples in the repository are a start, especially the interface that compares runtimes on the same task. Independent tests should add larger repositories, repeated package installations, parallel agents, and sessions that resume after interruptions.

If mixed-runtime workflows finish reliably while invoking fewer containers, Cloudflare’s mechanism gains support. If synchronization and routing erase those savings, a persistent sandbox remains the simpler choice.

The third signal is backend policy. Today, an application can describe available backends and let an agent select one. Production buyers will want deterministic controls governing which backend can access each file, network, secret, and command.

Cloudflare already has related infrastructure. Its Sandbox platform includes programmable outbound controls, while Durable Objects supply private, persistent state. Cloudflare Computer must combine those pieces into a policy model developers can reason about.

A mature implementation should make escalation visible. When an agent moves from a Worker shell to Linux, the application should know why, what new capabilities became available, and what data crossed the boundary.

This question reaches beyond Cloudflare. LangChain, Daytona, Ona, Modal, and other platforms are pursuing agent environments with different combinations of microVMs, containers, persistence, and developer tooling. Their competition concerns the definition of an agent computer, not just execution speed.

Some providers argue that untrusted agent code requires hardware-level isolation and a complete machine boundary. Cloudflare Computer instead focuses on decomposition, letting a workspace use lighter execution until it needs Linux. These positions can coexist because isolation needs vary by task.

Enterprise coding agents may still favor dedicated environments with reproducible toolchains and strict tenant boundaries. High-volume document agents may benefit more from durable files and lightweight commands. Data agents handling large inputs may expose the FUSE design’s throughput limits.

Developers should therefore test their task mix before adopting the concept. Count how many steps truly require native binaries. Measure how much data moves through the workspace. Trigger synchronization failures deliberately and confirm recovery.

They should also separate an appealing agent experience from an adequate security design. “One workspace” is a useful interface, but it does not mean every execution path has the same trust boundary. Runtime escalation deserves the same scrutiny as permission escalation.

Cloudflare Computer matters because it makes that design choice explicit. It asks developers to treat files as durable state, execution as a selectable service, and the apparent computer as an abstraction assembled for each task.

That framing will influence agent infrastructure even if this preview changes substantially. It offers an alternative to keeping one container or microVM alive merely because the agent needs its files later.

The GitHub surge confirms interest in the idea. It does not settle whether developers prefer the operational simplicity of one machine or the efficiency promised by several runtimes sharing one workspace.

For the next several months, watch the repository rather than the star count. Stable APIs, end-to-end benchmarks, and strict backend policies will determine whether Cloudflare Computer becomes production infrastructure or remains a compelling preview.

Teams evaluating the cloudflare computer preview should begin with a contained workload, document every runtime transition, and test recovery before trusting persistent state. Which operations truly need Linux, and which only need files plus a small execution surface? Answering that question with traces and failure tests will show whether the hybrid model fits your agents. It will also expose where a conventional sandbox remains easier to secure and operate. The larger lesson is already useful: an agent’s computer does not have to be one permanently running machine. However, splitting it into services transfers complexity into routing, synchronization, and policy. Treat those mechanisms as core infrastructure, not implementation details.