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
· Operator site
· Architecture
English · 简体中文
You already know how to write Cloudflare Workers. open-compute runs them unchanged — the same module workers, the same bindings, the same APIs — 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 control plane to babysit. No vendor.
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. Your code runs on stock workerd, Cloudflare's open-source V8 runtime. Isolates start in milliseconds and idle in megabytes — not containers, not gigabytes, not per-request process spawns.
- Nothing else to run. SQLite owns platform metadata and direct Local storage owns object bytes by default. You can select one S3-compatible authority instead; neither mode needs a sidecar.
- Pinned and verified. The current release pin uses stock workerd. Native limits and Loader development uses the
elliothux/workerd submodule at third_party/workerd; adopting a fork binary requires a coordinated pin update and validation.
- Yours completely. Your code, your data, your machines, fully offline. No account, no egress, no telemetry, no bill.
Proof, not promises
Compatibility here is measured, not asserted. The same fixtures run against open-compute and real Cloudflare — and if the results differ, it does not ship.
|
|
| 2,097 |
stable API members implemented across the Workers runtime and every product binding — zero gaps |
| 7 / 7 |
product surfaces verified byte-for-byte against real Cloudflare: Workers, Cache, KV, D1, R2, Durable Objects, Queues |
| 1 : 1 |
a production Next.js 16 build runs identically on Cloudflare and on open-compute — same artifact, same behavior |
| 90%+ |
enforced line coverage, with real processes, real SQLite, and real workerd in every acceptance run |
Compatibility
Write standard module workers (export default { fetch }) with the bindings you already know.
Runtime & bindings
| Module |
Status |
| Workers |
██████████ 100% ✅ |
| KV |
██████████ 100% ✅ |
| R2 |
██████████ 100% ✅ |
| D1 |
██████████ 100% ✅ |
| Durable Objects |
██████████ 100% ✅ |
| Queues |
██████████ 100% ✅ |
| Cron |
██████████ 100% ✅ |
| Workflows |
██████████ 100% ✅ |
| Static Assets |
██████████ 100% ✅ |
| Service Bindings |
██████████ 100% ✅ |
| Cache |
██████████ 100% ✅ |
| Images |
██████████ 100% ✅ |
| Version Metadata |
██████████ 100% ✅ |
| WebSocket Hibernation |
██████████ 100% ✅ |
Management
| Surface |
Status |
| Cloudflare v4 API |
█████████░ 90% — Local /client/v4 works with Wrangler and the official SDK. Matching every hosted Cloudflare response still needs a Cloudflare account token. |
| Wrangler |
█████████░ 95% — Pinned Wrangler 4.127.1: deploy and resource commands verified against a running ocd. |
| Dashboard |
████████░░ 80% — Operator admin UI on the same /client/v4 APIs — not a clone of the Cloudflare dashboard. |
| Workers Logs / realtime tail |
█████████░ 90% — wrangler tail plus Workers Logs query and live tail on a single node. Tail Workers, distributed traces, and Logpush are separate. |
Partial
| Module |
Status |
| Vectorize |
████████░░ 80% — Stable post-beta Vectorize binding and v2 control API. Beta VectorizeIndex is out of scope. |
| Markdown Conversion |
████████░░ 80% — Available through standard env.AI (toMarkdown). |
| AI Search |
████████░░ 80% — RAG namespaces, indexing, and retrieval with operator-configured OpenAI-compatible providers. |
Planning
Design is underway; bindings and APIs are not available to deploy yet.
| Module |
Status |
| Browser Run |
██░░░░░░░░ 20% — Planning (formerly Browser Rendering). |
| Artifacts |
██░░░░░░░░ 20% — Planning (Git-backed artifact repositories). |
Not yet
Not started for Day 1. Upload or config that requires these fails closed.
| Module |
Status |
| Workers AI |
░░░░░░░░░░ 0% — Hosted model inference (AI.run, model catalog, AutoRAG) is not provided. Markdown Conversion and AI Search above use env.AI only for their own surfaces. |
| Containers |
░░░░░░░░░░ 0% — Not yet. |
| Hyperdrive |
░░░░░░░░░░ 0% — Not yet. |
| Analytics Engine |
░░░░░░░░░░ 0% — Not yet. |
| Workers for Platforms |
░░░░░░░░░░ 0% — Not yet. |
| Dynamic Workers |
░░░░░░░░░░ 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 Worker or product API has no missing methods. Remaining differences are single-node topology (no global edge), documented in the compatibility matrix. Live surface: ocd capabilities --json.
Quick start
Bring up the platform locally (needs Rust 1.98, Bun 1.3.14, Node 26, and Git LFS — see docs):
git lfs pull --include="share/workerd/**"
./scripts/dev.sh
Ship your first Worker:
./target/debug/ocd wrangler --project examples/hello-worker deploy --env dev
Type-checked, bundled, deployed, and served — one command. In production it is even smaller: one executable, one config file, one data directory. No build tooling on the host, no runtime downloads, no network required at startup.
For remote targets, CI, staging/production environments, tail, and rollback, see Wrangler projects and deployment targets.
Architecture
| Component |
Role |
ocd |
The whole control plane: ingress, control API, scheduler, supervisor, deployment authority |
workerd |
The runtime — pinned, checksum-verified, unmodified upstream |
| SQLite |
Local, authoritative state — no external database, no eventual consistency |
| Local / S3 object authority |
Bundles, static assets, R2 bytes, snapshots, backups, cache bodies, and AI Search 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 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 with SQLite bundled in — transactions are function calls, not network round-trips. Foreign keys on, synchronous callbacks, WAL.
- Zero-copy where it counts. Verified runtime payloads are content-addressed and materialized once, then reused across restarts.
Layered crates with enforced boundaries
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 a Cap'n Proto config with the verified binary, spawns workerd as a supervised child, and speaks to it over a loopback-only channel with per-generation tokens that never touch argv, env, or logs. It owns the full child lifecycle: readiness probes, process groups, bounded output capture, graceful and forced stop, reaping, restart backoff, and secret-free orphan 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.
What it's not
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.
Documentation
Security
- One
ocd per 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.
License
Apache-2.0. Packaged workerd remains under upstream Cloudflare workerd licensing.
open-compute 是一个自托管平台，可以在你自己控制的硬件上原样运行 Cloudflare Workers 代码，把 Workers、KV、D1、R2、Durable Objects、Queues、Workflows、Cron、Cache、Images、Vectorize 和 AI Search 重新实现为单个 Rust 二进制文件。