High-performance Cloudflare Workers–compatible infrastructure in a single binary, deployed in one step.
Millisecond cold starts. MB-scale memory. Zero extra dependencies.
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 Wrangler workflows — on a single machine you own.
One binary. One data directory. One object authority. 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.
| 2,203 | stable API members and overloads tracked across the Workers runtime and product bindings |
| 7 / 7 | core product surfaces checked against real Cloudflare: Workers, Cache, KV, D1, R2, Durable Objects, and Queues |
| 1 : 1 | a production Next.js 16 build runs on Cloudflare and open-compute from the same project and deployment artifact |
| 90%+ | required line coverage, with real processes, SQLite, and the pinned workerd runtime in acceptance tests |
Write standard module workers (export default { fetch }) with the bindings you already know. See the compatibility guide for exact behavior and single-node differences.
| Module | Status |
|---|---|
| Workers | ██████████ 100% ✅ |
| KV | ██████████ 100% ✅ |
| R2 | ██████████ 100% ✅ |
| D1 | ██████████ 100% ✅ |
| Durable Objects | ██████████ 100% ✅ |
| Alarms | ██████████ 100% ✅ |
| Queues | ██████████ 100% ✅ |
| Cron | ██████████ 100% ✅ |
| Workflows | ██████████ 100% ✅ |
| Static Assets | ██████████ 100% ✅ |
| Service Bindings | ██████████ 100% ✅ |
| Cache | ██████████ 100% ✅ |
| Images | ██████████ 100% ✅ |
| Version Metadata | ██████████ 100% ✅ |
| WebSocket Hibernation | ██████████ 100% ✅ |
| Vectorize | ██████████ 100% ✅ |
| Markdown Conversion | ██████████ 100% ✅ |
| AI Search | ██████████ 100% ✅ |
| Artifacts | ██████████ 100% ✅ |
| Surface | Status |
|---|---|
| Cloudflare v4 API | █████████░ 90% — local /client/v4 works with Wrangler and the official SDK |
| Wrangler | ██████████ 100% ✅ — Wrangler 4.127.1 deploys and manages the supported products |
| Dashboard | ████████░░ 80% — operator UI built on the same /client/v4 API |
| Workers Logs / realtime tail | █████████░ 90% — logs, queries, wrangler tail, and live tail on one node |
| Module | Status |
|---|---|
| Dynamic Workers | ████████░░ 76% — core Worker Loader APIs are available |
| Workers Standard limits | ██░░░░░░░░ 20% — planning |
| Workers AI | ██░░░░░░░░ 20% — Markdown Conversion and AI Search only |
Design is underway; bindings and APIs are not available to deploy yet.
| Module | Status |
|---|---|
| Browser Run | ██░░░░░░░░ 20% — Planning. |
| Containers | ██░░░░░░░░ 20% — Planning. |
Uploads or configuration that require these capabilities fail closed.
| Module | Status |
|---|---|
| General Workers AI inference | ░░░░░░░░░░ 0% — Not yet. |
| Hyperdrive | ░░░░░░░░░░ 0% — Not yet. |
| Analytics Engine | ░░░░░░░░░░ 0% — Not yet. |
| Workers for Platforms | ░░░░░░░░░░ 0% — Not yet. |
| Pipelines | ░░░░░░░░░░ 0% — Not yet. |
| Rate Limiting | ░░░░░░░░░░ 0% — Not yet. |
| mTLS certificates | ░░░░░░░░░░ 0% — Not yet. |
| Tail Workers / traces / Logpush | ░░░░░░░░░░ 0% — Not yet. |
100% ✅ means the documented Worker or product API has no missing methods. 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 dashboardFor 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 --yesIn a normal Worker project, keep Wrangler project-local for development and use ocd wrangler for a real open-compute target:
npm install --save-dev wrangler@4.127.1
npx wrangler dev
ocd wrangler deployProduction remains one release executable, one config, and one data directory. 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.
| 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.
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.
tokiomulti-threaded runtime withaxum+hyperserving both planes. Request bodies stream through asbyteswithout buffering whole payloads. unsafe_code = "forbid". Workspace-wide — the entire platform is safe Rust. Plusmissing_docs = "deny",unused_must_use = "deny", and Clippy-D warningsacross 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.
rusqliteembeds SQLite inocd; 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.
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 data directory, one process, one machine — by design.
| 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 | Project guide · AGENTS.md |
- One
ocdper data directory — enforced by lock, not documentation. - Internal tokens never appear in argv, environment, logs, status, or metrics.
- Tenant outbound is public-only; private, loopback, link-local, and metadata addresses are rejected at the address layer.
This project is sponsored by Lynx AI.
Apache-2.0. The packaged open-compute workerd fork remains under the applicable upstream Cloudflare workerd licensing.