open-compute README

The project's README from github.com/elliothux/open-compute. As one markdown file: README.md.

open-compute

High-performance Cloudflare Workers–compatible infrastructure in a single binary, deployed in one step.
Millisecond cold starts. MB-scale memory. Zero extra dependencies.

CI Apache-2.0 stock workerd 2097 members Rust 1.98 macOS | Linux

Website · Docs · Operator site · Architecture

English · 简体中文

The Workers platform, running on your hardware

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.

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

open-compute 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.

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:

Documentation

Goal Start here
Understand the design Architecture & design
Check API support Compatibility matrix
Track remaining qualification Acceptance plans
Build and deploy Workers Toolchain guide
Download and release GitHub Releases · Release process
Run in production Single-binary guide · Container / systemd / launchd
Operate and recover Runbooks · Operator site
Contribute AGENTS.md · Testing policy

Security

Sponsors

This project is sponsored by Lynx AI.

License

Apache-2.0. Packaged workerd remains under upstream Cloudflare workerd licensing.

open-compute (elliothux/open-compute)

infrastructure
Searching Database…

2K ·GitHub
Open-compute
What is this?open-compute is a self-hosted platform that runs Cloudflare Workers code unchanged on hardware you control, reimplementing Workers, KV, D1, R2, Durable Objects, Queues, Workflows, Cron, Cache, Images, Vectorize and AI Search as a single Rust binary.
Is this just the workerd runtime, or a full platform?It is a full platform built on top of workerd. workerd only executes isolated Workers in a sandbox; open-compute adds the missing control plane — routing, durable state, scheduling, and deployment lifecycle — and ships it all as one binary (ocd).
How do I deploy my first Worker on it?You bring the platform up locally and then deploy with the same Wrangler CLI you already use for Cloudflare. A single command type-checks, bundles, deploys, and serves the Worker. In production it runs as one executable with one config file and one data directory.
What do I need installed to build and run it?Building it needs Rust 1.98, Bun 1.3.14, Node 26, and Git LFS. The compiled production binary needs none of that — no build tooling or network access on the host at startup.
Which Cloudflare features are still missing?Workers AI, Containers, Hyperdrive, Analytics Engine, Workers for Platforms, Pipelines, Rate Limiting, mTLS certificates, and Tail Workers/Logpush are all at 0%, not implemented yet. Vectorize and AI Search are only partially done at 80%.
Can it scale across multiple machines like real Cloudflare?No, it's explicitly single-node by design: one data directory, one process, one machine, with no Anycast routing or cross-region replication like Cloudflare's actual edge.
Does it phone home to Cloudflare or need an account?No — it runs fully offline with no Cloudflare account, no egress calls, no telemetry, and no bill.
How closely does it actually match real Cloudflare behavior?The team runs the same test fixtures against open-compute and real Cloudflare and refuses to ship on mismatches: 2,097 API members implemented with zero gaps, 7 of 7 product surfaces verified byte-for-byte, and a production Next.js 16 build runs identically on both.
Where does my data actually live?Platform metadata lives in a local SQLite database, and object bytes like R2 data, bundles, and cache snapshots sit on the local filesystem by default, with an optional S3-compatible store as the only alternative — no Redis or external database needed.
Why build this instead of just using workerd directly?workerd only runs isolated Workers — it has no routing, durable state, scheduler, or deployment API of its own. open-compute wraps stock workerd with that entire control plane (ocd) so there is nothing extra to run alongside it.
Can I still use the Cloudflare dashboard or API tooling?Wrangler works almost unchanged, pinned to 4.127.1 and 95% verified, against a local /client/v4 API, and there is a separate operator admin UI on that same API — though it is not a clone of Cloudflare's own dashboard.
What are similar projects?celld, cloudflare_temp_email, DoulorCloud, WasmEdge, mailflare, durable-git, nodewarden, company-brain
Which topics is it in?v8, edge-computing, queue, cloudflare-r2, cloudflare-d1, container, object-storage, workflow-engine, ai-gateway, key-value, runtime, cloudflare-workers
Creator
elliothux
Size
84.3 MB
Stars
2K
Updated
CommitOct 10Releasev0.3.0Oct 10
Age
1mo
Commits · 90 Days