elliothux/open-compute

One binary. One daemon. Isolated instances.
A self-hosted, Cloudflare Workers-compatible platform for a single machine.

Website · Docs · Compatibility · Architecture

English · 简体中文

You already know how to write Cloudflare Workers. open-compute runs the compatible Workers programming model — module workers, familiar bindings, and cf workflows — on a single machine you own.

One binary. One shared daemon. One object authority per instance. Local filesystem is the default; S3-compatible storage is optional.

No Kubernetes. No Redis. No service mesh. No distributed control plane to babysit. No vendor lock-in.

   Everyone else                        open-compute
   ─────────────                        ────────────
   gateway + router                     ┌──────────────┐
   control plane                        │              │
   scheduler service          ═══>      │  ocd (1 bin) │
   Redis / Valkey cluster               │              │
   Postgres                             └──────────────┘
   K8s + operators                       + SQLite + Local/S3 objects

workerd is a runtime, not a platform. It executes isolated Workers brilliantly — and stops there. No multi-tenant routing, no durable state, no scheduling, no deployment lifecycle, no control API. Everyone who wants Workers on their own infrastructure has to build that layer.

open-compute is that layer — and it ships as one file.

• One binary, everything inside. Runtime, control plane, scheduler, and every product binding. Copy it to a host, point it at a directory, and you are serving traffic.
• Fast because it's workerd. Worker code runs on a pinned, checksum-verified workerd fork. Isolates start in milliseconds — not one process or container per request.
• Nothing else to run. SQLite owns platform metadata and Local storage owns object bytes by default. S3-compatible storage is optional; neither mode needs a database or cache sidecar.
• Pinned and verified. The runtime and its assets are fixed and verified at build and startup. Production startup stays offline.
• Yours completely. You own the code, data, and machines. External services are optional and explicitly configured.

Compatibility here is measured, not asserted. The same fixtures run against open-compute and real Cloudflare wherever the hosted API permits direct comparison.

Write standard module workers (export default { fetch }) with the bindings you already know. See the compatibility guide for exact behavior and single-node differences.

Design is underway; bindings and APIs are not available to deploy yet.

Uploads or configuration that require these capabilities fail closed.

Cloudflare's APIs are broad and intricate. 99% ✅ means the documented public API surface is fully aligned; it does not promise that every behavioral detail is identical to Cloudflare. open-compute is still at an early stage. If you find behavior that does not match Cloudflare, please open an issue. Single-node differences are listed in the compatibility guide. Live surface: ocd capabilities --json.

Copy this prompt into Codex, Claude Code, or another coding agent:

Read https://open-compute.dev/llms.txt and install the current open-compute release on this machine. Configure one local instance, inspect any existing installation first, preserve its configuration and instance data, ask before using sudo or making destructive changes, then run ocd status and report the result.

llms.txt contains the minimum setup and usage instructions, with links to detailed documentation when needed.

Install the release binary for your user, create the default user-owned instance, and start its login-scoped service:

curl -fsSL https://open-compute.dev/install.sh | sh
ocd setup --yes
ocd status
ocd dashboard

For a host-wide service that starts before login, explicitly choose system scope:

curl -fsSL https://open-compute.dev/install.sh | sudo sh
sudo ocd setup --system --yes

Use cloudflare.config.ts and the official cf + Vite plugin v2 workflow. Node.js 22.18+ runs cf; ocd cf selects the deployment target. CI pins cf 1.0.0-beta.12; user versions outside 1.0.x only warn:

npm install --save-dev cf@1.0.0-beta.12 @cloudflare/vite-plugin@beta vite typescript
npm run dev
npm run build
ocd cf deploy --prebuilt --mode production

Production remains one release executable and one shared daemon, with explicit per-instance configuration and data directories. Runtime payloads are embedded and verified; daemon startup does not download or search PATH for workerd.

For the complete installation path, remote targets, CI, environments, tail, and rollback, see Get started and Develop.

Tenants get exactly what their deployment declares — and nothing else. No SQLite or Local object paths, no S3 credentials, no internal tokens, no sibling tenants. Enforced at the capability layer, not by convention.

The host is a single async Rust process — no GC pauses, no interpreter, no sidecar hops between the socket and your Worker.

• Async all the way down. tokio multi-threaded runtime with axum + hyper serving both planes. Request bodies stream through as bytes without buffering whole payloads.
• unsafe_code = "forbid". Workspace-wide — the entire platform is safe Rust. Plus missing_docs = "deny", unused_must_use = "deny", and Clippy -D warnings across all targets and features.
• Release built for speed. Full LTO, codegen-units = 1, panic = "abort", symbols stripped — one dense, statically-linked artifact.
• In-process state. rusqlite embeds SQLite in ocd; transactions are function calls, not network round-trips. Foreign keys stay enabled and WAL remains locally owned.
• Zero-copy where it counts. Verified runtime payloads are content-addressed and materialized once, then reused across restarts.

Dependency direction is checked in CI — architecture that can't silently rot:

core ── storage ── artifacts ── runtime      (siblings, lower level)
                    └── workers              (may use core/storage/artifacts, never runtime)
                          └── service        (composition root: CLI, HTTP, workerd bridge)

ocd compiles the runtime configuration, starts workerd as a supervised child, and communicates over a loopback-only channel. It owns readiness, graceful shutdown, restart backoff, and recovery.

Deployments are immutable and content-addressed. workerLoader keys are deployment identities, so promotion and rollback move a pointer — they never mutate what is already running.

The Dashboard manages the compute, storage, AI, and platform resources exposed through /client/v4. It also switches between the instances registered with the current ocd daemon.

When a Worker needs local hardware, a proprietary library, or an internal daemon, an operator can register a native extension: a native Provider process with a small JavaScript facade, exposed to Workers through cf Service Bindings (bindings.worker + props).

• No new Binding type. Workers see a standard Service Binding; per-binding props carry configuration.
• Direct data path. ocd authenticates the session, then workerd and the Provider communicate directly over Cap'n Proto.
• Fail closed. Session identities, provider paths, and platform handles never enter tenant code, argv, or logs.

The extension tutorial walks through the complete setup. The repository also includes a small Rust reference Provider.

Honest boundaries beat surprises in production:

• Not Cloudflare's global edge. One node on infrastructure you run — no Anycast, no cross-region replication, no POP fabric. That tradeoff is exactly what buys you strong local consistency.
• Not a universal drop-in. Compatibility is tracked surface by surface, and every deviation is documented rather than glossed over.
• Not a multi-replica HA cluster. One daemon, one machine, and isolated per-instance authorities — by design.

Report vulnerabilities privately using SECURITY.md.

• One ocd per user or system scope, with exclusive locks for every instance data directory.
• Internal tokens never appear in argv, environment, logs, status, or metrics.
• Tenant outbound can reach host-routable public, private, loopback, link-local, and metadata IPs; operators own destination filtering through the host firewall, namespace, container, or VM.

This project is sponsored by Lynx AI.

Apache-2.0. The packaged open-compute workerd fork remains under the applicable upstream Cloudflare workerd licensing.