@cloudflare/computer Guide: Durable Filesystems and Sandboxed Runtimes for AI Agents

By AiCybr Editorial · Published August 11, 2026

@cloudflare/computer is best understood as a durable working directory plus a selectable execution layer for AI agents. Its filesystem lives in a SQLite-backed Durable Object, while the same workspace can execute against a full Linux container, a lightweight shell in a Dynamic Worker, or isolated JavaScript in a Dynamic Worker. The useful idea is that files survive independently of whichever execution backend is chosen.

That makes Cloudflare Computer materially different from simply attaching an agent to a disposable container. It is also different from Cloudflare OS, which is a broader employee-facing AI application platform. Computer is a lower-level developer primitive intended for agents that need to read, write, edit, search and execute against persistent files.

There is one major qualification: Cloudflare explicitly labels the package preview-only, with unstable APIs, and says it is not suitable for production use yet. Treat it as an architecture worth evaluating, not a production platform commitment.

Quick verdict

The core problem it is trying to solve

An agent that can only call stateless APIs is straightforward to reason about, but many useful agent workflows need something closer to a computer:

• a working directory that survives multiple turns;
• source files and generated artifacts;
• search and edit operations;
• shell commands or scripts;
• package managers and real binaries for some tasks;
• a lighter-weight execution path for simple tasks;
• controlled publishing or export of generated files.

A normal container gives an agent a filesystem and shell, but persistence and lifecycle become your responsibility. Cloudflare’s Sandbox SDK solves much of the isolated-container side of that problem, but a sandbox’s container filesystem is tied to its lifecycle unless you explicitly add persistence. Cloudflare’s current Sandbox documentation says an idle sandbox can stop and restart with a fresh container, with previous container state lost.

Cloudflare Computer changes the ownership model: the Durable Object is the authoritative workspace, not the execution environment. An execution backend becomes something that operates on those files rather than the sole place where those files exist.

That separation is the most important architectural idea in the project.

Architecture: Durable Object first, runtime second

The current repository describes a Workspace whose filesystem is backed by the Durable Object’s SQLite storage. The API is intentionally similar to node:fs/promises, with operations such as readFile, writeFile, mkdir, readdir, rm and grep.

The workspace can exist with no execution backend at all. In that configuration, an application gets persistent files without giving the agent a shell.

Execution is added through workspace.runtime.exec(). Cloudflare currently ships three backend types:

A single Workspace can register more than one backend and select one for a particular execution. That means an agent can use the lightweight Worker shell for simple operations and escalate to a container only when it genuinely needs Linux tools.

This is more useful than treating “sandbox” as one fixed execution class.

Why the filesystem design matters

The durable filesystem is built on SQLite-backed Durable Object storage. Cloudflare’s current Durable Objects limits documentation lists 10 GB of storage per SQLite-backed Durable Object on paid plans, which lines up with the Computer package’s guidance of roughly 10 GB per workspace.

That makes the design appropriate for agent-scale working directories, not arbitrary bulk storage. Cloudflare explicitly warns against treating the container-side projection like a giant monorepo disk and notes that large sequential I/O can be slower than native disk.

The practical implication is important:

Good fits

• notes, plans and intermediate documents;
• a small codebase or generated project;
• configuration files;
• reports and data extracts;
• agent-created scripts;
• compact artifacts that should survive runtime restarts.

Poor fits

• multi-hundred-gigabyte datasets;
• huge source trees with very large dependency directories;
• storage-heavy media workflows;
• workloads where sustained native-disk throughput is the primary requirement.

For larger data, Cloudflare Computer also exposes patterns such as read-only R2-backed mounts and artifact publishing rather than requiring every byte to live permanently inside the Workspace.

Container backend: when the agent needs a real machine

The container backend is the closest match to the intuitive idea of “give the agent a computer.” It provides a full Linux userland, real binaries and network access.

The key difference from a plain container is that the Workspace remains the logical source of truth. The repository describes a computerd daemon inside the sandbox container that mounts the Workspace through FUSE and synchronizes changes with the Durable Object over RPC.

Use this path when an agent needs things such as:

• npm, Python or other real package tooling;
• compilers;
• native command-line utilities;
• a full Unix environment;
• build/test pipelines;
• commands that cannot reasonably be emulated in a Worker isolate.

The tradeoff is overhead. A full container is heavier than an isolate, and Cloudflare notes that FUSE-backed operations are not equivalent to native disk for every workload.

Worker shell: a lighter execution path

The Worker-shell backend runs just-bash in a Dynamic Worker. It does not create a Linux container.

Cloudflare exposes optional command groups such as curl, python, sqlite, jq, yq, file inspection and JavaScript execution. Applications import only the command groups they want to make available.

This is useful from both performance and capability-control perspectives. If an agent only needs to grep files, transform JSON and make approved HTTP requests, giving it a full Linux environment may be unnecessary.

The Worker shell also accesses the same Durable Object-backed filesystem directly rather than maintaining a second filesystem copy in a container.

That makes it a strong experimental fit for:

• text transformations;
• JSON/CSV manipulation;
• controlled HTTP retrieval;
• lightweight scripting;
• agent planning workflows that occasionally need command-like tools.

Worker JavaScript: structured code instead of shell commands

The third backend runs ECMAScript modules in Dynamic Workers. This is more constrained than a shell but can be cleaner for applications that want structured input and output.

Cloudflare’s Dynamic Workers platform is specifically designed to load code at runtime in isolated Workers while allowing the parent application to control bindings and network access. Computer builds on that primitive so JavaScript code can operate against the durable Workspace.

This can be preferable when:

• generated code is JavaScript/TypeScript-oriented;
• you want a tighter dependency/binding surface than a Linux container;
• you want structured return values rather than parsing shell output;
• startup latency matters more than access to a full operating system.

Cloudflare Computer vs Sandbox SDK

These two products overlap, but they are not the same abstraction.

Cloudflare’s Sandbox SDK remains the clearer choice when the main requirement is simply: run untrusted code in an isolated Linux environment with files, processes and service previews.

Computer becomes interesting when the main requirement is instead: give an agent persistent working state and let the application decide which execution environment should operate on that state.

The container backend can itself make use of Cloudflare’s container/sandbox infrastructure, so these technologies are complementary rather than mutually exclusive.

Cloudflare Computer vs Dynamic Workers

Dynamic Workers are a lower-level sandbox primitive. They let an application load arbitrary Worker code at runtime and control bindings and network access.

Computer uses Dynamic Workers for two of its execution backends, but adds:

• a durable filesystem abstraction;
• a unified runtime.exec() surface;
• ready-made agent tools;
• git operations against the Workspace;
• file publishing and artifact helpers;
• routing between several execution backends.

Use Dynamic Workers directly when you only need isolated Worker code execution and want full control over the loader architecture. Use Computer when persistent agent workspace semantics are also part of the problem.

Cloudflare Computer vs a plain container

A plain container remains simpler for many workloads.

If you need one long-lived service with a mounted disk and do not need an agent-specific durable workspace abstraction, Kubernetes, Docker or Cloudflare Sandbox may be easier to understand and operate.

Computer is most differentiated when runtime lifecycle and workspace lifecycle should be separate. For example:

1. An agent writes a plan and source files into its Workspace.
2. It performs simple edits using Worker shell.
3. A build step is routed to a Linux container.
4. The container stops.
5. The Workspace persists.
6. A later agent turn resumes from the same files without depending on that original container still existing.

That is a real architectural advantage for agentic workloads, but only if an application needs it.

Agent-tool integration

The package includes ready-made AI SDK tool wrappers around the Workspace. Current defaults include file-oriented operations such as read, write, edit and list, with execution and publishing available when configured.

This reduces integration work, but it should not be confused with a complete agent-security policy.

Giving a model a filesystem and exec capability still requires decisions about:

• which backends it may invoke;
• what commands or libraries are exposed;
• network egress;
• credentials and bindings;
• maximum file sizes and output sizes;
• runtime timeouts;
• destructive operations;
• user authorization;
• audit logging;
• approval before high-impact actions.

A sandbox reduces the blast radius of code execution. It does not automatically decide whether an action is authorized or safe for a particular user.

Git, R2 and artifacts

Computer also includes several agent-oriented conveniences that show where Cloudflare is trying to take the project.

Git

The Workspace can use an opt-in typed git client based on isomorphic-git. It operates directly on the virtual filesystem, so basic repository operations do not inherently require a shell backend.

That is useful for coding agents because repository state can remain attached to the agent’s durable Workspace even when execution backends come and go.

R2-backed mounts

Applications can expose read-only R2-backed data inside the Workspace. This is useful for reference material or larger immutable assets that should not consume the Workspace’s primary SQLite storage.

Assets and Artifacts

The package includes mechanisms for publishing workspace files and interacting with Cloudflare Artifacts. This makes the Workspace more than a private scratch directory: it can also become the staging area from which an agent exports something useful.

Limits and operational caveats

Several current limitations should shape any evaluation.

1. It is explicitly preview software

The repository says APIs are unstable, the design may change, and the package is not suitable for production use today. This is the most important limitation.

2. The design documentation is partly forward-looking

Cloudflare warns that portions of the specification describe intended architecture rather than only what current code implements. Verify any specific API against the live package README before depending on it.

3. Workspace storage is not a general-purpose disk

The Durable Object storage ceiling and FUSE characteristics make this better suited to compact agent workspaces than large storage-intensive projects.

4. Runtime capabilities differ materially

Worker shell, Worker JavaScript and container execution are not interchangeable. Code that assumes Linux tools will need the container path.

5. Dynamic Worker features and pricing matter

The Worker-based execution backends depend on Cloudflare’s Dynamic Workers infrastructure, which currently belongs to the Workers Paid platform and has its own request, CPU and created-worker pricing dimensions.

6. Container execution still has container costs and lifecycle concerns

Computer changes where durable files live; it does not make full Linux execution free or instantaneous.

When I would test it

@cloudflare/computer is worth experimenting with when most of these are true:

• you are already building on Workers/Durable Objects;
• the agent needs a persistent working directory;
• you want to avoid keeping a container alive merely to preserve files;
• some tasks can run in a lightweight isolate while others need Linux;
• you want a single API surface across those execution choices;
• you can tolerate API churn because the project is still preview-only.

I would not choose it yet for a production-critical agent platform whose filesystem API, runtime behavior or deployment model must remain stable for years.

For production systems today, it is safer to treat Cloudflare Computer as an architecture to study and prototype while keeping a more mature execution/storage design available as the fallback.

How it relates to Cloudflare OS

AiCybr’s existing Cloudflare OS guide covers a much broader platform: employee AI workspaces, generated Gadgets, Gatekeepers, organizational context and sharing/governance.

Cloudflare Computer sits lower in the stack. It answers a different developer question: how can an agent have durable files and execute against them without binding those files permanently to one container?

The two ideas are adjacent, but they should not be treated as the same product.

Final assessment

Cloudflare Computer is interesting because it separates two things that are often coupled in agent systems: persistent workspace state and the machine that executes against it.

A Durable Object can own the files. A fast Dynamic Worker can handle lightweight operations. A container can be invoked only when a real Linux environment is necessary. The application can switch between those backends while preserving one logical workspace.

That is a strong architecture for agentic workloads where state must outlive execution environments.

But the current product status matters more than the elegance of the design. Cloudflare’s own repository says the package is preview-only and not ready for production. For now, the right posture is experiment, benchmark and learn from the model; do not assume API stability or production guarantees that Cloudflare has not made.

Primary sources

• Cloudflare Computer repository
• @cloudflare/computer package documentation
• Cloudflare Durable Objects limits
• Cloudflare Sandbox SDK overview
• Cloudflare Sandbox for agents
• Cloudflare Dynamic Workers
• Cloudflare Dynamic Workers pricing