open-compute: a self-hosted Workers platform in one Rust binary

What open-compute actually solves, and who it is for

workerd executes isolated Workers well, but the README is blunt about the gap: "workerd is a runtime, not a platform." There is no multi-tenant routing, no durable state, no scheduling, no deployment lifecycle and no control API in workerd itself. Anyone who wants the Workers model on their own hardware ends up writing that layer. open-compute positions itself as exactly that layer, shipped as one file.

The target reader is a team that already writes module workers and does not want to rebuild the surrounding platform. The README lists KV, R2, D1, Durable Objects, Alarms, Queues, Cron, Workflows, Static Assets, Service Bindings, Cache, Images, Version Metadata, WebSocket Hibernation, Vectorize, Markdown Conversion, AI Search and Artifacts at 100 percent each. If your application leans on those bindings and you are comfortable operating a single host, the pitch is coherent. If you were hoping for a distributed control plane, this is the opposite of that: the README says no Kubernetes, no Redis, no service mesh.

One caveat on the name. open-compute is not the Open Compute Project, the data center hardware initiative. Searches for "open compute project" or "OCP" describe something else entirely, and the repository here is a Workers-compatible runtime, not a hardware specification.

One binary, SQLite metadata, and a pinned workerd fork

The architecture is deliberately flat. The README's own diagram contrasts the usual stack (gateway, router, control plane, scheduler, Redis or Valkey, Postgres, Kubernetes operators) with a single box labelled "ocd (1 bin)" plus SQLite and local or S3 objects. Runtime, control plane, scheduler and product bindings are compiled into that one binary.

Worker code does not run on a hand-rolled interpreter. The README states it runs on a pinned, checksum-verified workerd fork, and that the runtime and its assets are fixed and verified at build and startup, with production startup staying offline. That is a meaningful design decision: you are not tracking upstream workerd drift, but you also inherit whatever that fork pins.

State lives in two places. 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, per the README. The workspace layout backs this up: crates/storage, crates/runtime, crates/workers, crates/artifacts, crates/images, crates/search and crates/service are separate crates, and the workspace pins aws-sdk-s3 at =1.96.0, which matches the claim that S3 is a real but optional path.

Management is exposed through a local /client/v4 surface. The README rates Cloudflare v4 API compatibility at 90 percent and says it works with Wrangler and the official SDK. Wrangler 4.127.1 is named as the version that deploys and manages the supported products.

Installing open-compute and deploying a first worker

The README does not print a copy-paste install command. It points to https://open-compute.dev/docs/ for installation, and the repository ships examples/hello-worker/, examples/systemd/, examples/launchd/ and examples/container/ for deployment shapes. Treat those as the starting points rather than inventing a package name.

The deployment path the README does name is Wrangler 4.127.1 against the local /client/v4 API. The repository's own build script shows the example worker being typechecked with tsc, which is how the hello-worker example is validated in CI:

tsc --project examples/hello-worker/tsconfig.json --noEmit

That command comes from the build script in the repository's package.json, and it is the check the project runs against the example rather than a deploy step. For the deploy itself, the README names Wrangler 4.127.1 as the tool that manages the supported products through the local API, and the docs page is where the exact invocation lives. Once a worker is registered, the README describes wrangler tail and live tail on one node, so log streaming is the natural second step. If you want the process supervised, examples/systemd/ and examples/launchd/ exist for Linux and macOS respectively; the README lists macOS and Linux as the supported platforms.

Where the single-node model breaks down

The honest limitation is in the name of the compatibility guide: single-node differences. The README says the compatibility guide covers "exact behavior and single-node differences," which means some semantics do not match Cloudflare because there is one machine, not hundreds of edge locations. Durable Objects, Queues and Workflows all assume a placement story on Cloudflare that a single binary cannot reproduce identically. The README does not document rollback, so a bad deploy is a problem you solve with your own backup of the SQLite metadata and object store, not with a built-in revert.

The coverage table is also worth reading literally rather than as a victory lap. Dynamic Workers sits at 76 percent, with the README noting core Worker Loader APIs are available. Workers Standard limits is at 20 percent and marked planning. Workers AI is at 20 percent, and the README restricts it to Markdown Conversion and AI Search only. The Dashboard is at 80 percent. If your application depends on Workers AI models or on Dynamic Workers as a primary mechanism, this is the wrong tool today, and the README says so through its own numbers rather than through prose.

The API inventory badge reads 2,203 stable members and overloads, and the README claims 7 of 7 core product surfaces checked against real Cloudflare. Those are coverage claims about the surface, not a statement that every edge case behaves identically. The README is careful to say comparison happens "wherever the hosted API permits direct comparison," which implies some comparisons were not possible.

How open-compute differs from running workerd yourself or staying on Cloudflare

The closest alternative is workerd on its own. The difference is scope, not speed. workerd gives you isolate execution and stops; open-compute adds routing, durable state, scheduling, a deployment lifecycle and a control API around it. If you only need to run a worker process locally for tests, plain workerd is less to operate. If you need KV, D1, R2, Durable Objects and Queues with a deploy command, you are rebuilding open-compute's layer by hand.

The other alternative is staying on Cloudflare, and the difference is placement. Cloudflare runs your worker across a global network; open-compute runs it on one host you own, with the README's stated benefits being ownership of code, data and machines, and no external services unless you configure them. The README's own comparison table makes the trade explicit: the left column is a stack of gateway, control plane, scheduler, Redis, Postgres and Kubernetes, and the right column is one binary plus SQLite and objects. That is a real simplification, and it is also a real ceiling. A single host has one failure domain.

A third comparison the README makes is artifact parity. It claims a production Next.js 16 build runs on Cloudflare and open-compute from the same project and deployment artifact. That is the strongest argument in the README for teams that want to keep Cloudflare as an option while developing against a local instance.

Licence, releases and the cost of tracking a pinned runtime

open-compute is Apache-2.0, stated in the README badge and in the workspace Cargo.toml under [workspace.package]. The workspace sets publish = false, so this is not a crate you pull from crates.io as a dependency; it is a platform you run. Apache-2.0 permits commercial use and modification, and it includes a patent grant, but the repository does not ship a NOTICE file at the top level, so if you redistribute a modified binary, check the licence text yourself rather than relying on this summary. This is not legal advice.

Upgrade cost is shaped by the pinned workerd fork. The README says the runtime and its assets are fixed and verified at build and startup, which means runtime updates arrive when the project updates the pin, not when upstream workerd releases. The release cadence is fast: v0.1.5, v0.1.6 and v0.1.7 all landed within days of each other in September 2026, and the last push to main was on 2026-09-13. At 0.x versions with that cadence, expect to read release notes before upgrading rather than treating it as a drop-in patch stream.

The Rust side is pinned too. rust-toolchain.toml exists in the repository and the README badge names Rust 1.98, matching rust-version = "1.98" in Cargo.toml. If your build environment tracks a different toolchain, that is the first thing to reconcile.

Editorial conclusion

Adopt open-compute if you already write module workers and want KV, D1, R2, Durable Objects, Queues and Workflows on a machine you control, with Wrangler 4.127.1 as the deploy path. Do not adopt it if you need multi-node failover, Kubernetes-style orchestration, or full Workers AI, since the README lists Workers AI at 20 percent and Dynamic Workers at 76 percent. Before committing, verify that your Wrangler version matches the tested 4.127.1, that your host is macOS or Linux, and whether your workload fits a single node, because the README describes single-node differences and does not document rollback.

Frequently asked questions

Official sources

1. elliothux/open-compute on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases