How to Get Support for Cloudflare Computer: GitHub Channels and Documentation

The primary support channels for cloudflare/computer are GitHub Issues for bugs, GitHub Discussions for usage questions, and the extensive documentation in the docs/ folder and package READMEs.

Cloudflare Computer is a preview‑only virtual‑filesystem platform built on top of a Durable Object that maintains authoritative state in SQLite. Because the project is currently in preview, official support is handled entirely through public GitHub channels rather than traditional enterprise support portals. This guide explains exactly how to get cloudflare/computer support, where to find authoritative documentation, and how to structure your questions to get fast responses from maintainers.

Understanding the Architecture Before Requesting Help

Before opening a support request, identify which component you are interacting with. The system is split into several packages that together provide the complete development experience:

• packages/dofs/ – The Durable Object Filesystem (DOFS) stores VFS state in a SQLite database and implements the sync protocol. See packages/dofs/README.md for implementation details.
• packages/rpc/ – Defines the Cap’n Proto wire format used between the DOFS and the computerd daemon. Documentation lives in packages/rpc/README.md.
• packages/computerd/ – The daemon that runs inside a sandbox container, mounts the VFS via FUSE, and exposes an HTTP/WebSocket RPC server. Refer to packages/computerd/README.md for capabilities and limitations.
• packages/computer/ – The public‑facing API that Workers use (workspace.runtime.exec, workspace.fs, etc.). Entry points and usage examples are documented in packages/computer/README.md.

Knowing which layer you are targeting helps you reference the correct specification—such as docs/08_capnweb_interface.md for RPC contracts or docs/04_filesystem_interface.md for supported filesystem operations—when filing detailed reports.

Official Support Channels for Cloudflare Computer

GitHub Issues for Bug Reports

If you encounter a bug, have a feature request, or need clarification on unexpected behavior, create a new issue in the cloudflare/computer repository. To ensure a quick response, include:

1. A minimal reproducible example using the public API from packages/computer.
2. The specific backend you are using (container, worker-shell, or worker-javascript).
3. Relevant logs or error messages from the computerd daemon if applicable.

GitHub Discussions for Usage Questions

For design‑level conversations, usage tips, or community support that does not require a formal bug report, use the Discussions tab. This is the appropriate venue for questions about architecture decisions, best practices for mounting the FUSE filesystem, or how to structure RPC calls according to the capnweb interface defined in docs/08_capnweb_interface.md.

Contributing Guidelines

The CONTRIBUTING.md file at the repository root explains the contribution workflow and how to report problems effectively. Note that the repository explicitly states unsolicited pull requests are not accepted; all feedback must be routed through issues or discussions first.

Self-Service Documentation and Resources

Core Documentation in docs/

The docs/ folder contains the authoritative design specification. Before reaching out, consult:

• docs/08_capnweb_interface.md – The RPC contract that underlies all backend communication between the DOFS and the daemon.
• docs/04_filesystem_interface.md – Lists every supported filesystem operation and its semantics.
• docs/17_isolate_javascript.md – Details the worker-javascript backend, including how modules are evaluated inside Dynamic Workers.

Package-Specific READMEs

Each package contains targeted documentation:

• packages/dofs/README.md – Details on the SQLite‑backed VFS and the sync protocol used to maintain state consistency.
• packages/computerd/README.md – Information about the FUSE mount process, sandbox container constraints, and the HTTP/WebSocket RPC server.
• packages/computer/README.md – Public API documentation, including method signatures for workspace.runtime.exec and workspace.fs.

Example Projects

The examples/ directory contains ready‑to‑run sample projects (container, worker‑shell, worker‑javascript, think, etc.) that demonstrate real‑world usage patterns. Each subdirectory includes its own README with setup instructions.

Common Integration Patterns

Below are three patterns that illustrate standard interactions with the cloudflare/computer platform. Understanding these helps you construct better support requests when things go wrong.

Executing Shell Commands in the Container Backend

Use workspace.runtime.exec with the container backend to run commands inside the sandbox where computerd has mounted the VFS via FUSE:

import { workspace } from '@cloudflare/computer';

async function runLs() {
  const result = await workspace.runtime.exec('ls -la', {
    backend: 'container',
  });
  console.log('STDOUT:', result.stdout);
  console.log('STDERR:', result.stderr);
}
runLs();

Implementation note: This sends the command over the capnweb RPC channel defined in packages/rpc/ to the daemon described in packages/computerd/README.md.

Using the Workspace Filesystem API

The fs namespace mirrors Node’s fs/promises API but routes every operation through the Durable Object, guaranteeing a consistent view across backends:

import { workspace } from '@cloudflare/computer';

async function writeAndRead() {
  await workspace.fs.writeFile('/hello.txt', new TextEncoder().encode('Hello, Cloudflare!'));
  const data = await workspace.fs.readFile('/hello.txt');
  console.log(new TextDecoder().decode(data));
}
writeAndRead();

Reference: Supported operations are listed in docs/04_filesystem_interface.md.

Running ECMAScript Modules in the Worker-JavaScript Backend

The worker-javascript backend evaluates supplied modules inside a Dynamic Worker, with automatic marshaling of structured input and output:

import { workspace } from '@cloudflare/computer';

const moduleSource = `
export async function main({ input }) {
  return { message: \`You sent: \${input}\` };
}
`;

async function runModule() {
  const result = await workspace.runtime.exec(moduleSource, {
    backend: 'worker-javascript',
    input: 'Hello from the client',
  });
  console.log(result.output);
}
runModule();

Reference: Implementation details are described in docs/17_isolate_javascript.md.

Summary

• GitHub Issues are the correct channel for bug reports and feature requests regarding cloudflare/computer.
• GitHub Discussions host community support and architectural questions.
• Documentation is authoritative in the docs/ folder and package READMEs (packages/computer/README.md, packages/dofs/README.md, etc.).
• Unsolicited pull requests are not accepted; use issues and discussions to propose changes.
• When reporting issues, specify your backend (container, worker-shell, or worker-javascript) and reference relevant files like docs/08_capnweb_interface.md.

Frequently Asked Questions

Is there a paid support tier for Cloudflare Computer?

No. Because Cloudflare Computer is a preview‑only platform, support is limited to the public GitHub channels—Issues for bugs and Discussions for usage questions. There is no enterprise support portal or SLA for this project.

Why are unsolicited pull requests not accepted?

The maintainers require that all feedback be routed through GitHub Issues or Discussions first to align with the project’s roadmap and architectural vision. This process is documented in CONTRIBUTING.md. Once a proposal is discussed, the team may invite specific contributions, but opening PRs without prior coordination violates the contribution workflow.

Which backend should I specify when reporting an issue?

Always indicate whether you are using the container backend (which uses the computerd FUSE daemon), worker-shell, or worker-javascript backend. Each follows different code paths in packages/computerd/ or packages/dofs/, and knowing this helps maintainers reproduce your issue against the correct subsystem.

Where can I find the RPC protocol specification?

The complete RPC contract—known as capnweb—is documented in docs/08_capnweb_interface.md. This file specifies the wire format used between the Durable Object and the computerd daemon, as implemented in packages/rpc/. Understanding this specification is essential when debugging connectivity or serialization issues.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}