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

Website · Docs · Compatibility · Architecture

English · 简体中文

---

The Workers platform, running on your hardware

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

Why open-compute

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

Write standard module workers (export default { fetch }) with the bindings you already know. Supported means the documented public API matches Cloudflare. Single-node differences are listed in the compatibility guide. A running daemon reports its surface with ocd capabilities --json. If behavior differs from Cloudflare, please open an issue.

Supported	Partial	Not yet
Workers, Workers Standard limits	Cloudflare v4 API: /client/v4 works with cf and the official SDK	General Workers AI inference
KV, R2, D1	Dashboard: operator UI on the same /client/v4 API	Hyperdrive
Durable Objects, Alarms	Workers Logs and Live Tail, on one node	Analytics Engine
Queues, Cron, Workflows	Workers AI: Markdown Conversion and AI Search only	Workers for Platforms
Static Assets, Service Bindings	Browser Run: CDP, managed browser, Quick Actions, DevTools, Live View, Custom AI (operator guide)	Pipelines
Cache, Images	Containers: 65-member API with directory restore; needs an operator-owned Linux Broker; tag qualification pending	Rate Limiting
Version Metadata, WebSocket Hibernation		mTLS certificates
Vectorize, Markdown Conversion, AI Search		Tail Workers, traces, Logpush
Artifacts, Dynamic Workers
cf 1.0.0-beta.12 deploys and manages the supported products

Uploads or configuration that need a "Not yet" capability are rejected.

The test suite tracks 2,256 stable API members and overloads. Ten products (Workers, Cache, KV, D1, R2, Durable Objects, Queues, Vectorize, AI Search and Observability) are compared request by request with real Cloudflare where the hosted API allows it.

Quick start

Set up with an AI coding agent

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.

Set up manually

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.

Architecture

Component	Role
ocd	The control plane: ingress, API, scheduler, supervisor, and deployment authority
workerd	Pinned, checksum-verified Worker runtime
SQLite	Local authoritative state — no external database, no eventual consistency
Local / S3 object authority	Bundles, static assets, R2 bytes, Artifacts, snapshots, backups, cache bodies, and AI sources

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.

Built in Rust, engineered for the hot path

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 unused_must_use = "deny" and Clippy -D warnings across all targets and features.
• Release built for speed. Thin 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.
• Content-addressed runtime payloads. Verified runtime payloads are content-addressed and materialized once, then reused across restarts.

Layered crates with enforced boundaries

CI checks the dependency direction:

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.

Dashboard

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.

Native extensions

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.

What it's not

• 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.

Documentation

Goal	Start here
Understand the design	Architecture and project guide
Check API support	Compatibility · Worker API index
Track unsupported features	Not available
Build and deploy Workers	Develop
Download and release	GitHub Releases · Project guide
Run in production	Get started · Operate
Operate and recover	Operate · Incident guides
Contribute	Contributing guide · Code of conduct

Security

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.

Sponsors

This project is sponsored by Lynx AI.

License

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