Which parts can you consider for production?
The current package guide marks the filesystem and Worker JavaScript backend stable; Worker shell and ContainerBackend remain experimental. Choose Computer when persistent files in a Durable Object are the requirement, then select execution separately.
Cloudflare currently considers the package suitable for production, while its experimental components remain unsuitable for production use. The package status table also lists computerd, the synchronization protocol and interrupted JavaScript recovery among the experimental pieces. A stable execution tool inherits the limitations of the backend it calls.
This guidance differs from the README at our tested commit, which called the whole package preview-only and unsuitable for production. Our September run tested that older checkout. It cannot validate the implementation behind the current stable designation, and this review includes no new execution.
What did our sandbox establish?
Our run took place in our sandbox on September 28, 2026, at commit e5e28a7. Install, build and test commands returned exit code 0, taking 115, 78 and 131 seconds respectively. The recorded environment used Node 22, three CPUs and 8 GB RAM.
Our harness records command success, exit code, elapsed time and timeout status separately from parsed test counts. The stored parser summary records 664 passed, 0 failed and 0 skipped tests. These are stored parser summaries, not verified exhaustive counts of unique tests across the monorepo.
The raw output contains several suite footers. It also identifies skips in src/cli/computerd.test.ts and src/exec/runner.fuse.test.ts, despite the stored parser summary recording no skips. Those are skipped tests, not failures. We have neither summed the footers nor replaced the attached summary with a suite-specific count. In particular, the skipped FUSE runner test does not establish that FUSE execution worked.
The stored dependency measurement records 743 packages and 1,073 MB. The install log reports a different package count; that command output is not interchangeable with the stored on-disk dependency measurement. Neither figure establishes audit coverage.
npm audit recorded six high-severity advisories and no critical, moderate or low advisories in its stored summary. The record has no scannedPackages field, so scan coverage is unknown. It also provides no affected dependency paths or reachability analysis. These are recorded advisories, not proof of exploitability or a security assessment.
The MrKeyoor testing methodology explains how repository command outcomes differ from workload validation. That page describes the publisher's current procedure; it does not establish which methodology version governed this older run. Our record does not demonstrate a deployed Worker, a live container workload, backend performance, network-policy enforcement or an agent completing a task.
What does the persistent filesystem provide?
Cloudflare Computer keeps authoritative filesystem state in a Durable Object's SQLite storage, with files durable across restarts. A workspace can use the filesystem without any execution backend.
When execution is needed, the application can register backends and select one for a call. Worker JavaScript evaluates ECMAScript modules; Worker shell runs just-bash; the container backend provides Linux binaries through a FUSE projection of the workspace. These are documented capabilities, not workloads demonstrated by our run.
Start with the filesystem alone for agent notes or generated files. Consider Worker JavaScript when module execution fits the task. If the task requires shell commands or Linux binaries, account for the experimental status of those backends before adopting them.
The package guide documents approximately 10 GB per workspace, shared with the Durable Object. It says the container-side filesystem is held in memory and that heavy I/O, such as large dependency installs and tar extraction, is slower than native disk. Our repository install timing does not benchmark that filesystem.
What setup work remains in your application?
The filesystem quick start requires a Durable Object binding, a SQLite migration and nodejs_compat. Worker JavaScript adds a Worker Loader binding; Worker shell adds just-bash and the experimental flag. Container execution adds Cloudflare Container and computerd configuration.
Long-lived clients must dispose workspace stubs and execution handles. The package guide says remote stubs otherwise accumulate until the RPC session ends. Test this lifecycle in your application, along with restart behavior and the selected backend's network restrictions. Repository commands returning zero do not validate those application choices.
When should you choose another sandbox?
Cloudflare Sandbox SDK provides file operations and bucket mounts around a Container that your own Durable Object starts. Its current README assigns command execution to the application's Durable Object through the Container API. Consider it when the application starts with a Linux container and direct lifecycle control rather than Computer's persistent virtual filesystem. It is an alternative integration, not a drop-in replacement or a required complement.
E2B provides JavaScript and Python SDKs for starting and controlling cloud sandboxes. Its README makes that platform role explicit. Consider it when those SDKs and a separate sandbox service fit better than a Workers-owned filesystem. Our evidence establishes no comparative speed, cost or reliability advantage for either alternative.
What do the ratings mean?
The assessed ratings use this rubric: 1 means substantial documented obstacles; 2 means considerable configuration or experimental constraints; 3 means a usable path with material caveats; 4 means detailed practical support with explicit limits; 5 requires broader validation than this record provides. Setup ease concerns configuration and contributor burden, docs concerns actionable guidance, and maturity concerns the combined filesystem and execution offering. Community is unassessed because sustained participation and support responsiveness are not established.
Setup ease is 2 because bindings, migrations and backend configuration accompany a substantial repository dependency footprint. Docs is 4 because the guide supplies installation examples, component status, backend requirements and disposal rules. Maturity is 2 for the combined offering because shell, container and synchronization components remain experimental; that rating does not override the separately documented stable filesystem and Worker JavaScript backend.
For an adoption trial, begin with durable reads and writes, then exercise your chosen backend, restart behavior and stub disposal in your own deployment. Make the production decision against that specific surface and its current status.