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. ## Proof, not promises Compatibility here is measured, not asserted. The same fixtures run against open-compute and real Cloudflare wherever the hosted API permits direct comparison. | | | | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **2,256** | stable API members and overloads tracked across the Workers runtime and product bindings | | **10** | product surfaces compared request-for-request with real Cloudflare: Workers, Cache, KV, D1, R2, Durable Objects, Queues, Vectorize, AI Search, and Observability | | **90%+** | required line coverage, with real processes, SQLite, and the pinned workerd runtime in acceptance tests | ## Compatibility Write standard module workers (`export default { fetch }`) with the bindings you already know. See the [compatibility guide](https://open-compute.dev/docs/platform/compatibility/) for exact behavior and single-node differences. ### Runtime & bindings | Module | Status | | ----------------------- | ----------------- | | Workers | █████████▉ 99% ✅ | | Workers Standard limits | █████████▉ 99% ✅ | | KV | █████████▉ 99% ✅ | | R2 | █████████▉ 99% ✅ | | D1 | █████████▉ 99% ✅ | | Durable Objects | █████████▉ 99% ✅ | | Alarms | █████████▉ 99% ✅ | | Queues | █████████▉ 99% ✅ | | Cron | █████████▉ 99% ✅ | | Workflows | █████████▉ 99% ✅ | | Static Assets | █████████▉ 99% ✅ | | Service Bindings | █████████▉ 99% ✅ | | Cache | █████████▉ 99% ✅ | | Images | █████████▉ 99% ✅ | | Version Metadata | █████████▉ 99% ✅ | | WebSocket Hibernation | █████████▉ 99% ✅ | | Vectorize | █████████▉ 99% ✅ | | Markdown Conversion | █████████▉ 99% ✅ | | AI Search | █████████▉ 99% ✅ | | Artifacts | █████████▉ 99% ✅ | | Dynamic Workers | █████████▉ 99% ✅ | ### Management | Surface | Status | | ---------------------------- | ---------------------------------------------------------------------------- | | Cloudflare v4 API | █████████░ 90% — local `/client/v4` works with cf and the official SDK | | cf | Pinned `1.0.0-beta.12` deploys and manages the documented supported products | | Dashboard | ████████░░ 80% — operator UI built on the same `/client/v4` API | | Workers Logs / realtime tail | █████████░ 90% — logs, queries, Dashboard Live Tail on one node | ### Partial | Module | Status | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Workers AI | ██░░░░░░░░ 20% — Markdown Conversion and AI Search only | | Browser Run | CDP and managed browser, Quick Actions, DevTools, Live View and Custom AI; [operator guide](docs/references/runbooks/install-and-first-start.md) | | Containers | The fixed 65-member API includes directory restore. Requires an operator-owned Linux Broker. [Candidate checks passed; tag qualification remains](docs/implemented/p23-cloudflare-containers.md). | ### Not yet 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. | 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](https://github.com/elliothux/open-compute/issues/new). Single-node differences are listed in the [compatibility guide](https://open-compute.dev/docs/platform/compatibility/). Live surface: `ocd capabilities --json`. ## Quick start ### Set up with an AI coding agent Copy this prompt into Codex, Claude Code, or another coding agent: ```text 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`](https://open-compute.dev/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: ```sh 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: ```sh 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: ```sh 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](https://open-compute.dev/docs/get-started/) and [Develop](https://open-compute.dev/docs/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 `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. ### 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 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](https://open-compute.dev/docs/extension/tutorial/) walks through the complete setup. The repository also includes a small Rust [reference Provider](crates/service/src/bin/host_extension_test_provider/main.rs). ## 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 daemon, one machine, and isolated per-instance authorities — by design. ## Documentation | Goal | Start here | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Understand the design | [Architecture and project guide](https://open-compute.dev/docs/project/) | | Check API support | [Compatibility](https://open-compute.dev/docs/platform/compatibility/) · [Worker API index](https://open-compute.dev/docs/platform/reference/api/) | | Track unsupported features | [Not available](https://open-compute.dev/docs/platform/unsupported/) | | Build and deploy Workers | [Develop](https://open-compute.dev/docs/develop/) | | Download and release | [GitHub Releases](https://github.com/elliothux/open-compute/releases) · [Project guide](https://open-compute.dev/docs/project/) | | Run in production | [Get started](https://open-compute.dev/docs/get-started/) · [Operate](https://open-compute.dev/docs/operate/) | | Operate and recover | [Operate](https://open-compute.dev/docs/operate/) · [Incident guides](https://open-compute.dev/docs/ocd/incidents/current-release/) | | Contribute | [Contributing guide](CONTRIBUTING.md) · [Code of conduct](CODE_OF_CONDUCT.md) | ## Security Report vulnerabilities privately using [SECURITY.md](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](https://lynxai.work)**. ## License Apache-2.0. The packaged open-compute workerd fork remains under the applicable upstream Cloudflare workerd licensing.