Cloudflare Computer 0.1.1: Prototype the Workspace, Not Production

Cloudflare Computer solves a real agent-infrastructure problem: a model should not need a permanently running Linux container just to read a note, edit a small file, or run a lightweight command. Version 0.1.1 puts a durable SQLite-backed workspace inside a Durable Object, then lets an application route execution to a fast Worker isolate or a full Cloudflare Container without changing the file API.

That is a useful design experiment. It is not a production platform yet.

OpenSourceChoice verdict: prototype Cloudflare Computer when you already build on Cloudflare and want to measure whether a shared workspace plus tiered execution reduces container starts, latency, or orchestration code. Do not place production data, untrusted public code, or a recovery-critical workflow on 0.1.1. The maintainers explicitly label the package preview-only, the API and design are unstable, current documentation includes forward-looking specifications, and the first public release has no formal GitHub release notes. Production teams should evaluate Cloudflare Sandbox SDK in parallel for a supported Cloudflare container boundary and E2B when provider portability or self-hosting matters more.

Methodology: This is a researched architecture and adoption analysis, not a hands-on benchmark. OpenSourceChoice inspected the official repository, package documentation, npm registry record, tag and commit history, issue and pull-request state, license, security policy, public advisories, platform documentation, pricing, and independent trend signals on August 6, 2026. We did not deploy the package, execute its examples, reproduce reported bugs, or independently verify Cloudflare's performance claims.

Why this matters now

Cloudflare introduced Computer on August 3 and published @cloudflare/computer@0.1.1 the same day. Three days later, the repository appeared first on GitHub's daily Trending page; the page displayed 796 stars gained that day when observed. A separate Reddit thread attracted practical questions about how Computer differs from a container and what it costs.

Those are two independent interest signals, but neither establishes technical quality. The stronger reason to examine the project now is architectural: agent workloads are splitting into short, cheap operations and rarer jobs that need a real operating system. Keeping every session inside an always-on sandbox wastes resources; pretending a JavaScript isolate is Linux breaks as soon as an agent needs a native binary, package manager, or unrestricted process model.

Cloudflare Computer proposes one workspace across both execution classes. That is more interesting than the launch slogan because it moves the selection boundary from “which product hosts this agent?” to “which runtime should execute this step?”

Hacker News, Lobsters, Product Hunt, XDA, and broader social searches did not add primary technical evidence for this decision during the review. Community reactions are used only to establish interest and the questions developers are asking.

Current state on August 6, 2026

The v0.1.1 tag points to an August 3 commit that stopped bundling the computerd binary in the npm tarball and changed the default publishing tag. The repository adopted a Changesets release flow on August 5, after 0.1.1. That is evidence of release-process work, but it is not a retroactive changelog or stability commitment.

The open issue list also needs careful interpretation. Fresh reports describe symlink handling, container/package version mismatch, remote-stub accounting, local secret-file defaults, and a PDF tutorial failure. These reports had not all been confirmed or fixed when reviewed. They should become targeted evaluation cases, not claims that every deployment is affected.

What Cloudflare Computer actually provides

The Durable Object owns the authoritative filesystem state in its SQLite storage. Applications use a Workspace facade with familiar asynchronous file operations and a single workspace.runtime.exec() surface. The backend determines what that execution means.

Agent or application
        |
        v
Workspace in a Durable Object
authoritative SQLite-backed filesystem
        |
        +--> Worker shell: just-bash in a Dynamic Worker
        |
        +--> Worker JavaScript: ECMAScript module in a Dynamic Worker
        |
        +--> Container: Linux userland through computerd + FUSE + RPC sync

The two Worker backends reach the Durable Object workspace directly. The container backend projects that state into a real Linux environment through FUSE and synchronizes changes over a capnweb WebSocket channel. An application can register several backends, give them stable names, and choose one per execution.

This separation can be valuable for agents that mostly manipulate text or structured files but occasionally need npm, pandoc, a compiler, or another native tool. A policy layer can send cheap, constrained work to an isolate and reserve the container for commands that genuinely need Linux.

The package also includes optional AI SDK tools for reading, writing, editing, listing, executing, and publishing files; an opt-in Git client; read-only R2 mounts; artifact helpers; and observability hooks. The current repository documents three execution backends. It does not document a browser backend in the package, despite the broader launch post discussing browsers as part of the platform vision. Budget only for the interfaces that ship and that your prototype verifies.

What it does not provide

Computer is not a general-purpose virtual machine, a full local Docker environment, or a drop-in self-hosted agent runner.

• The Worker shell is just-bash, not Linux. Native binaries, Docker, arbitrary system packages, and full POSIX behavior belong in the container backend.
• The Worker JavaScript backend executes modules in a Dynamic Worker; it is not Node.js with unrestricted operating-system access.
• The container-side filesystem is held in memory. The project recommends agent-scale workspaces rather than full monorepos and documents an approximate 10 GB workspace ceiling shared with Durable Object storage.
• Heavy FUSE I/O, large dependency installs, and tar extraction can trail native disk. The project's published benchmark is a maintainer result, not an independent measurement.
• The library does not own your Durable Object alarm. Applications must schedule retries when a post-command synchronization remains pending.
• Remote RPC stubs are not garbage-collected during a session. Long-lived applications must dispose workspace and execution handles correctly.
• The MIT package is open source, but the documented deployment architecture depends on Cloudflare-specific Durable Objects, Dynamic Worker Loader bindings, Containers, R2, and Artifacts. No supported self-hosted control plane is documented.

The last point is the main portability constraint. Source availability lets a team inspect or fork the library; it does not make the hosted runtime portable. Replacing the provider would mean reimplementing storage, execution, synchronization, routing, lifecycle, and observability contracts—not merely changing an endpoint.

Installation and compatibility reality

The basic package installation is short:

npm install @cloudflare/computer

The platform setup is not. A filesystem-only workspace needs a SQLite-backed Durable Object migration and the nodejs_compat compatibility flag. Worker shell and Worker JavaScript additionally require the experimental flag and a Worker Loader binding. The container backend requires a Cloudflare Container running computerd plus the relevant Worker and Durable Object bindings.

The npm manifest for 0.1.1 declares MIT and dependencies on acorn, capnweb, and just-bash. It does not declare a Node engine. Optional features introduce peer dependencies such as the AI SDK, Zod, and @platformatic/vfs. This is a Workers-oriented package; absence of an npm engine constraint should not be read as a promise of broad Node runtime compatibility.

There is no official Docker Hub-style package that turns Computer into a provider-neutral service. The repository describes a private package directory used as the Docker image context for the prebuilt Linux computerd binary. Follow the current example and Cloudflare deployment path rather than inventing an unsupported container distribution.

The real operating cost

The package has no license fee, but the full runtime is not free infrastructure.

Cloudflare's current Containers pricing requires the Workers Paid plan, listed at $5 per month, and meters provisioned memory and disk plus active CPU. The plan includes monthly allowances, after which usage is billed. Container egress, the Worker handling requests, each container's Durable Object, and logs can add separate usage charges.

A filesystem-only or isolate-only prototype can avoid container compute, but it still consumes Workers and Durable Objects resources. Durable storage, requests, duration, R2 mounts, artifacts, model calls, and retained logs all belong in the total cost model. The expensive failure mode is not one command; it is an agent loop that keeps creating sessions, retaining workspaces, or waking containers without budgets and cleanup.

Measure at least:

• workspace count and retained bytes per tenant;
• Durable Object requests, active duration, storage, and alarm retries;
• container starts, active seconds, instance type, and egress;
• isolate-to-container routing ratio;
• p50 and p95 execution latency by backend;
• failed or pending synchronization rate;
• model tokens and tool retries per completed task;
• log volume and retention;
• abandoned sessions deleted within the promised lifecycle window.

Cloudflare's launch post says its own internal agents route fewer than 10% of workloads to containers and reports lower latency and cost. Treat that as the project's published workload result. Your commands, dependencies, repository sizes, cache behavior, and security controls may produce a different ratio.

Security and data flow

Computer can reduce the time that a full Linux sandbox is running. It does not make agent execution safe by itself.

The authoritative workspace resides in a Durable Object. Container execution copies or projects data through a FUSE and RPC synchronization path; optional R2 mounts and asset publishing create additional data flows. Commands with network access can exfiltrate files or injected credentials unless egress and secret access are constrained outside the model's control.

Before any real-data pilot, define:

1. Tenant boundary: one durable identity and workspace per security principal; no user-controlled reuse of another tenant's Durable Object ID.
2. Authorization: every file, execution, publish, and artifact operation checked server-side. A model choosing a tool is not authorization.
3. Capability policy: Worker shell for a reviewed command set; container only for tasks needing Linux; no silent fallback to a more powerful backend.
4. Network policy: default-deny or allowlisted container egress, especially for untrusted repositories and generated package installs.
5. Secret brokering: short-lived, scoped credentials injected only for the required operation; never durable plaintext in the workspace.
6. Lifecycle: hard time, CPU, storage, output, and retry budgets; explicit kill and disposal on cancellation.
7. Audit: actor, tenant, selected backend, command or module identity, file changes, published artifacts, network policy decision, and exit state recorded without logging secrets.
8. Recovery: export and restore tests for workspace data plus a documented path for incomplete container synchronization.

No public advisory found for 0.1.1 is reassuring only in a narrow sense. The package was days old, the APIs were unstable, and several correctness reports arrived after launch. Security review must include the library, the platform bindings, the container image, dependency graph, generated commands, and application policy.

License, governance, and lock-in

MIT is commercially permissive and has not changed since the license file was added. That lowers legal friction for experiments and forks.

Governance is narrower than the license. The contribution guide accepts bug reports, fix proposals, feature requests, and design proposals, but the project does not accept unsolicited pull requests; implementation PRs are routed through approved collaborators. In the 30-day commit sample reviewed, one account authored nearly all returned commits. That does not prove the project has a bus factor of one—Cloudflare may have internal review and staffing not visible in commit authorship—but adopters should ask who can publish, review security changes, and maintain the sync protocol.

Vendor lock-in is high at the runtime layer. The Durable Object filesystem, Worker Loader, Container binding, R2 integration, and Artifacts binding are platform primitives. A team can retain its application data if it builds export functions early, but code written directly around these bindings is not portable without an adapter or rewrite.

The practical hedge is to keep the agent's task model independent of Computer. Define your own interfaces for workspace files, command execution, artifact publication, cancellation, limits, and audit events. Then make Cloudflare Computer one adapter rather than the domain model.

Alternatives to evaluate in parallel

Within Cloudflare, Sandbox SDK is the mandatory comparison. It is not necessarily the cheaper choice, but it separates a production container requirement from Computer's experimental routing layer. Outside Cloudflare, E2B tests whether a sandbox-centric API and self-host option are more valuable than Durable Object-native state.

Do not select an alternative from star counts. Run the same task corpus, data policy, failure injection, export test, and cost model against each candidate.

A measurable evaluation plan

Use a disposable Cloudflare account or isolated development environment with synthetic data.

Phase 1: filesystem only

Create one workspace per synthetic tenant and exercise read, write, edit, list, delete, binary streams, directory traversal, quotas, and restart persistence. Add explicit tests for symlinks and concurrent writes because current issues identify those areas as active. Reject the pilot if one tenant can address another tenant's workspace or if export and restore cannot preserve the corpus.

Phase 2: isolate backends

Run a fixed set of text-processing and JavaScript tasks through Worker shell and Worker JavaScript. Record unsupported commands rather than silently moving them to a container. Require predictable timeouts, output limits, cancellation, and disposed RPC handles over long sessions.

Phase 3: container path

Repeat native-tool tasks with the exact computerd image and package versions. Test cold starts, large files, dependency installation, network denial, process termination, pending sync, retry alarms, and cancellation during execution. Confirm that a completed response means the authoritative Durable Object state is complete.

Phase 4: comparative gate

Run the same container tasks on Sandbox SDK and one provider-neutral alternative. Compare task success, p95 latency, total billed resources, operational alerts, data export time, and recovery from a killed runtime.

Approve only a prototype if all of these are true:

• 100% tenant-isolation tests pass;
• zero commands escalate to a stronger backend without policy approval;
• 100% cancelled runs terminate and dispose resources within the target window;
• workspace export and restore meet the recovery objective;
• pending sync is observable, retried within a budget, and never reported as success prematurely;
• the cost cap stops runaway sessions;
• the chosen task corpus shows a meaningful improvement over using Sandbox SDK directly.

Production approval needs additional upstream evidence: a non-preview release, stable API documentation that describes current code, formal release notes, resolved critical correctness reports, a reviewed upgrade path, and successful canary operation with real observability.

OpenSourceChoice assessment

• Best for: Cloudflare-native teams exploring agents that need durable small workspaces and a mix of lightweight and full-Linux execution.
• Not for: production workloads today, regulated data without a completed platform review, full monorepos, or teams requiring provider-neutral self-hosting.
• Why now: the August 3 launch produced both rapid repository interest and concrete architecture, cost, and reliability questions.
• Real cost: platform usage, policy engineering, synchronization recovery, observability, and provider exit work—not the MIT package.
• Main risk: an unstable preview becomes embedded as a platform dependency before its filesystem and runtime contracts settle.
• Production gate: a supported release plus verified isolation, cancellation, synchronization, export, cost controls, and recovery.
• Parallel alternative: Cloudflare Sandbox SDK first; E2B if portability and self-hosting are decision drivers.
• Recommendation: prototype with synthetic data and a fixed task corpus. Keep Computer behind your own adapter and do not ship 0.1.1 as production infrastructure.

Sources

Primary project, release, security, and platform sources:

• Cloudflare Computer repository — Cloudflare; current architecture, preview status, activity, issues, pull requests, contribution model, and MIT license observed August 6, 2026.
• @cloudflare/computer package documentation — Cloudflare; installation, limits, execution backends, lifecycle, synchronization, and observability for the current main branch; accessed August 6, 2026.
• v0.1.1 source tag — Cloudflare; tagged August 3, 2026; version reviewed in this analysis.
• @cloudflare/computer registry record — npm registry; version, publication time, license, dependencies, and peer dependencies observed August 6, 2026.
• Introducing @cloudflare/computer — Cloudflare; published August 3 and updated August 4, 2026; project rationale and maintainer-reported routing and performance claims.
• Cloudflare organization security policy — Cloudflare; HackerOne and security-email reporting routes observed August 6, 2026.
• Cloudflare Computer security advisories — GitHub; no published repository advisory observed August 6, 2026.
• Cloudflare Containers pricing — Cloudflare; Workers Paid requirement, included usage, metering, egress, Durable Object, and logging costs; updated April 21, 2026.
• Durable Objects pricing — Cloudflare; request, duration, storage, and plan details; updated June 19, 2026.

Alternative evaluation sources:

• Agents have their own computers with Sandboxes GA — Cloudflare; published April 13, 2026; GA status and product scope for Cloudflare Sandboxes.
• Cloudflare Sandbox SDK repository — Cloudflare; Apache-2.0 SDK, examples, release activity, and current beta API caveat observed August 6, 2026.
• E2B repository — E2B; Apache-2.0 infrastructure, SDKs, releases, and self-hosting entry point observed August 6, 2026.
• E2B BYOC guide — E2B; Terraform provisioning model, supported providers, and control-plane boundary accessed August 6, 2026.

Trend and independent community signals:

• GitHub daily Trending — GitHub; Cloudflare Computer listed first with 796 stars that day when observed August 6, 2026; a point-in-time interest signal, not a quality metric.
• Cloudflare Computer discussion — r/CloudFlare; August 2026; independent questions about differentiation and pricing, used only as a community-interest signal.

Architecture judgments, risk classifications, production gates, and adoption recommendations are OpenSourceChoice editorial analysis. Cloudflare performance and routing numbers remain maintainer-published results until independently reproduced.