open-compute: Cloudflare Workers Bindings in One Rust Binary
Self-hosted Cloudflare Workers-compatible platform with KV, D1, R2, Durable Objects, Queues, and Workflows in one Rust binary.
At a glance
- What is it?
- open-compute packages a workerd fork, KV, D1, R2, Durable Objects, Queues and Workflows behind one binary and a local /client/v4 API. The compatibility claim is measured, but the single-node design is the real boundary.
- Who is it for?
- Adopt open-compute if you already write module workers and want the same deployment artifact to run on your own hardware, and if a single node with SQLite and local or S3 objects is an acceptable failure domain. Do not adopt it if you need Workers AI beyond Markdown Conversion and AI Search, or if your architecture assumes Cloudflare's global anycast, regional replication or Workers Standard limits.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What workerd does not give you, and what open-compute adds
workerd executes isolates well, but the README is blunt that it is a runtime and not a platform: no multi-tenant routing, no durable state, no scheduling, no deployment lifecycle, no control API. open-compute is that layer. The target reader is an engineer who already understands module workers and bindings, wants to keep the programming model, and does not want to operate a gateway, a control plane, a scheduler, Redis, Postgres and Kubernetes to get there. The repository's own comparison diagram reduces that stack to a single process named ocd plus SQLite and local or S3 object storage. The problem being solved is operational surface area, not raw execution speed.
One process, SQLite for metadata, local or S3 for object bytes
The architecture visible in the README is deliberately flat. Platform metadata lives in SQLite. Object bytes live on the local filesystem by default, with S3-compatible storage as an optional mode. Worker code runs on a workerd fork that the README describes as pinned and checksum-verified at build and startup, with production startup staying offline. Management traffic arrives through a local /client/v4 API that the project says works with Wrangler and the official Cloudflare SDK, and the operator dashboard is built on that same API rather than a separate control path. That single-authority design is why there is no distributed control plane to babysit, and it is also why the failure domain is one machine. The README points to a compatibility guide for single-node differences, which is the document to read before assuming parity.
Compatibility is measured, and the numbers have edges
The project tracks 2,203 stable API members and overloads and reports 7 of 7 core product surfaces checked against real Cloudflare: Workers, Cache, KV, D1, R2, Durable Objects and Queues. It also states that a production Next.js 16 build runs on Cloudflare and open-compute from the same project and deployment artifact, and that acceptance tests use real processes, SQLite and the pinned workerd runtime with 90 percent or more required line coverage. Read the status tables carefully, though. Cloudflare v4 API is listed at 90 percent, the dashboard at 80 percent, and Workers Logs and realtime tail at 90 percent. Dynamic Workers sits at 76 percent with core Worker Loader APIs available. Workers Standard limits is at 20 percent and marked planning, and Workers AI is at 20 percent, limited to Markdown Conversion and AI Search. Anything in the planning section has no binding yet.
Deploying with Wrangler against a local endpoint
The README gives the deployment shape rather than a full command list: copy the binary to a host, point it at a data directory, and serve traffic. Wrangler compatibility is stated for version 4.127.1, which the README says deploys and manages the supported products, and the local /client/v4 API is what Wrangler and the official SDK talk to. The README does not document rollback, migration between local and S3 object storage, or how to move an existing data directory to another host, so treat those as unverified until the docs site covers them. The runtime and its assets are fixed and verified at build and startup, and production startup is described as offline, which matters if your hosts have no egress.
The single-node boundary is the real limitation
Everything runs on one machine, and the README does not describe replication, failover or multi-region placement. If that host goes down, the Workers, the KV namespace, the D1 database, the R2 bucket and the Durable Objects all go with it, because SQLite and the default local object store are on the same box. This is not a defect in the design; it is the design. But it rules open-compute out for workloads that assume Cloudflare's anycast edge or that need a durable object to survive a regional outage. The planning status of Workers Standard limits is a second constraint: if your Workers depend on the platform's enforced resource ceilings, the project is not there yet. Workers AI is the third: Markdown Conversion and AI Search only, so inference-heavy Workers are the wrong fit.
How it differs from running Miniflare or Wrangler's local mode
The obvious alternative for local Workers development is Miniflare or Wrangler's own local mode, which emulate bindings in a development process. Those tools are built for the inner loop, and they do not present a Cloudflare v4 management API that Wrangler and the official SDK can deploy against, nor do they claim a persistent multi-tenant control plane with a scheduler and a deployment lifecycle. open-compute's stated position is that it runs the compatible programming model as a serving platform, with the same deployment artifact used on Cloudflare and on your hardware. The difference in approach is the management surface: Miniflare emulates the runtime, while open-compute emulates the runtime and the account API around it.
Licence, maintenance and the cost of upgrading
The project is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; it does not impose copyleft on your Worker code. The repository is not archived and the last push was on 2026-09-13, with v0.1.7 released on 2026-09-12, v0.1.6 on 2026-09-12 and v0.1.5 on 2026-09-11. Three releases in three days is a fast cadence for a project at 0.1.x, and the practical upgrade cost is the pinned workerd fork: because the runtime is fixed and checksum-verified, moving to a new version means adopting a new pin rather than tracking upstream workerd continuously. Budget for reading release notes on each bump, and check whether the compatibility guide's single-node differences change for the bindings you rely on. This is not legal advice; review the Apache-2.0 terms against your own distribution model.
Editorial conclusion
Adopt open-compute if you already write module workers and want the same deployment artifact to run on your own hardware, and if a single node with SQLite and local or S3 objects is an acceptable failure domain. Do not adopt it if you need Workers AI beyond Markdown Conversion and AI Search, or if your architecture assumes Cloudflare's global anycast, regional replication or Workers Standard limits. Before committing, verify the compatibility guide's single-node differences for the bindings you use, check that your Wrangler version matches the tested 4.127.1, and confirm whether the pinned workerd fork is rebuilt on the cadence your security process requires.
Community notes