<p align="center">
<a href="https://open-compute.dev">
<img src="share/brand/open-compute.webp" alt="open-compute" width="480" />
</a>
</p>
<p align="center">
<strong>One binary. One daemon. Isolated instances.</strong><br/>
A self-hosted, Cloudflare Workers-compatible platform for a single machine.
</p>
<p align="center">
<a href="https://github.com/elliothux/open-compute/actions/workflows/ci.yml">
<img src="https://github.com/elliothux/open-compute/actions/workflows/ci.yml/badge.svg?branch=main" alt="CI" />
</a>
<img src="https://img.shields.io/badge/license-Apache--2.0-blue" alt="Apache-2.0" />
<img src="https://img.shields.io/badge/runtime-verified%20workerd%20fork-f38020" alt="verified workerd fork" />
<img src="https://img.shields.io/badge/API%20inventory-2%2C256%20members-success" alt="2256 stable members and overloads" />
<img src="https://img.shields.io/badge/rust-1.98-orange" alt="Rust 1.98" />
<img src="https://img.shields.io/badge/platform-macOS%20%7C%20Linux-lightgrey" alt="macOS | Linux" />
</p>
<p align="center">
<a href="https://open-compute.dev">Website</a>
· <a href="https://open-compute.dev/docs/">Docs</a>
· <a href="https://open-compute.dev/docs/platform/compatibility/">Compatibility</a>
· <a href="https://open-compute.dev/docs/project/">Architecture</a>
</p>
<p align="center">
English · <a href="README.zh.md">简体中文</a>
</p>
---
## 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](https://open-compute.dev/docs/platform/compatibility/). A running daemon reports its surface with `ocd capabilities --json`. If behavior differs from Cloudflare, please [open an issue](https://github.com/elliothux/open-compute/issues/new).
| 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](docs/references/runbooks/install-and-first-start.md)) | Pipelines |
| Cache, Images | Containers: 65-member API with directory restore; needs an operator-owned Linux Broker; [tag qualification pending](docs/implemented/p23-cloudflare-containers.md) | 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.21` 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:
```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.21; user versions outside 1.0.x only warn:
```sh
npm install --save-dev cf@1.0.0-beta.21 @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
<p align="center">
<img src="share/open-compute-architecture.png" alt="open-compute architecture" width="880" />
</p>
| 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
<p align="center">
<img src="share/open-compute-dashboard.webp" alt="open-compute Dashboard in dark and light mode" width="1080" />
</p>
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
- **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.