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)

Searching Database…

2K ·GitHub
Open-compute
Что это?open-compute — это self-hosted платформа, которая запускает код Cloudflare Workers без изменений на вашем железе, заново реализуя Workers, KV, D1, R2, Durable Objects, Queues, Workflows, Cron, Cache, Images, Vectorize и AI Search в виде одного Rust-бинарника.
Это просто рантайм workerd или полноценная платформа?Это полноценная платформа, построенная поверх workerd. workerd лишь исполняет изолированные Workers в песочнице; open-compute добавляет недостающую управляющую плоскость — маршрутизацию, постоянное состояние, планирование и жизненный цикл развертывания — и поставляет всё это одним бинарником (ocd).
Как развернуть на нём свой первый Worker?Вы поднимаете платформу локально и развертываете через тот же Wrangler CLI, которым уже пользуетесь для Cloudflare. Одна команда проверяет типы, собирает, развертывает и запускает Worker. В продакшене всё работает как один исполняемый файл с одним файлом конфигурации и одной директорией данных.
Что нужно установить для сборки и запуска?Для сборки нужны Rust 1.98, Bun 1.3.14, Node 26 и Git LFS. Скомпилированному продакшен-бинарнику ничего из этого не требуется — ни инструментов сборки, ни сетевого доступа на хосте при запуске.
Каких функций Cloudflare всё ещё не хватает?Workers AI, Containers, Hyperdrive, Analytics Engine, Workers for Platforms, Pipelines, Rate Limiting, сертификаты mTLS и Tail Workers/Logpush находятся на отметке 0% — пока не реализованы. Vectorize и AI Search готовы лишь частично, на 80%.
Может ли он масштабироваться на несколько машин, как настоящий Cloudflare?Нет, он изначально одноузловой: одна директория данных, один процесс, одна машина, без Anycast-маршрутизации и межрегиональной репликации, как у настоящего edge Cloudflare.
Он отправляет данные Cloudflare или требует аккаунт?Нет — он полностью работает офлайн: без аккаунта Cloudflare, без исходящих вызовов наружу, без телеметрии и без счетов к оплате.
Насколько точно его поведение совпадает с настоящим Cloudflare?Команда прогоняет одни и те же тестовые фикстуры через open-compute и настоящий Cloudflare и не выпускает релиз при расхождениях: 2 097 членов API реализовано без пробелов, 7 из 7 продуктовых поверхностей проверены побайтово, и продакшен-сборка Next.js 16 работает одинаково на обеих.
Где на самом деле хранятся мои данные?Метаданные платформы лежат в локальной базе SQLite, а байты объектов — данные R2, бандлы и снапшоты кэша — по умолчанию находятся в локальной файловой системе, с опциональным S3-совместимым хранилищем как единственной альтернативой — Redis или внешняя база данных не нужны.
Зачем это создавать, вместо того чтобы использовать напрямую workerd?workerd лишь запускает изолированные Workers — у него нет собственных маршрутизации, постоянного состояния, планировщика или API развертывания. open-compute оборачивает стандартный workerd всей этой управляющей плоскостью (ocd), так что ничего дополнительного запускать рядом не нужно.
Могу ли я по-прежнему пользоваться панелью Cloudflare или инструментами для её API?Wrangler работает почти без изменений — привязан к версии 4.127.1 и проверен на 95% — против локального API /client/v4, а на том же API есть отдельная админ-панель для операторов, хотя это не клон собственной панели Cloudflare.
What are similar projects?celld, cloudflare_temp_email, DoulorCloud, WasmEdge, mailflare, nodewarden, durable-git, company-brain
Which topics is it in?v8, queue, cloudflare-r2, edge-computing, cloudflare-d1, container, object-storage, workflow-engine, ai-gateway, key-value, runtime, cloudflare-workers
Creator
elliothux
Size
86.2 MB
Stars
2K
Updated
CommitOct 19Releasev0.3.0Oct 10
Age
1mo
Commits · 90 Days