open-compute发布单机版Cloudflare Workers兼容平台

一个二进制文件。一个守护进程。多个隔离实例。 一个自托管、兼容 Cloudflare Workers 的单机平台。 网站 · 文档 · 兼容性 · 架构 你已经知道如何编写 Cloudflare Workers。open-compute 在你自己的单台机器上运行兼容的 Workers 编程模型——模块化 Worker、熟悉的绑定，以及 cf 工作流。 一个二进制文件。一个共享守护进程。每个实例一个对象权威。默认使用本地文件系统；S3 兼容存储为可选项。 没有 Kubernetes。没有 Redis。没有服务网格。没有需要照看的分布式控制平面。没有供应商锁定。 其他方案 open-compute ───────────── ──────────── 网关 + 路由器 ┌──────────────┐ 控制平面 │ │ 调度器服务 ═══> │ ocd（1 个二进制） │ Redis / Valkey 集群 │ │ Postgres └──────────────┘ K8s + operator + SQLite + 本地/S3 对象 为什么选择 open-compute workerd 是运行时，不是平台。它出色地执行隔离的 Workers——然后到此为止。没有多租户路由，没有持久状态，没有调度，没有部署生命周期，没有控制 API。每个想在自己的基础设施上运行 Workers 的人，都必须自己构建这一层。 open-compute 就是这一层——而且它以单个文件的形式交付。 编写标准的模块化 Worker（export default { fetch }），使用你已熟悉的绑定。“支持”意味着文档化的公开 API 与 Cloudflare 一致。单节点差异列在兼容性指南中。运行中的守护进程通过 ocd capabilities --json 报告其能力范围。如果行为与 Cloudflare 不同，请提交 issue。 需要“尚不支持”能力的上传或配置将被拒绝。 测试套件跟踪 2,256 个稳定的 API 成员和重载。十个产品（Workers、Cache、KV、D1、R2、Durable Objects、Queues、Vectorize、AI Search 和 Observability）在托管 API 允许的情况下，与真实的 Cloudflare 逐请求进行对比。 使用 AI 编程代理进行设置 将以下提示复制到 Codex、Claude Code 或其他编程代理中： 读取 https://open-compute.dev/llms.txt，并在本机安装当前 open-compute 版本。配置一个本地实例，先检查任何现有安装，保留其配置和实例数据，在使用 sudo 或进行破坏性更改前询问，然后运行 ocd status 并报告结果。 llms.txt 包含最低限度的设置和使用说明，并在需要时提供详细文档的链接。 为你的用户安装发布二进制文件，创建默认的用户所有实例，并启动其登录作用域的服务： curl -fsSL https://open-compute.dev/install.sh | sh ocd setup --yes ocd status ocd dashboard 对于在登录前启动的主机级服务，请显式选择系统作用域： curl -fsSL https://open-compute.dev/install.sh | sudo sh sudo ocd setup --system --yes 使用 cloudflare.config.ts 和官方 cf + Vite 插件 v2 工作流。Node.js 22.18+ 运行 cf；ocd cf 选择部署目标。CI 固定 cf 1.0.0-beta.21；用户版本在 1.0.x 之外只会警告： 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 生产环境仍然是一个发布可执行文件和一个共享守护进程，具有显式的每实例配置和数据目录。运行时负载已嵌入并经过验证；守护进程启动时不会下载 workerd，也不会在 PATH 中搜索它。 有关完整的安装路径、远程目标、CI、环境、tail 和回滚，请参阅入门和开发。 租户只能获得其部署所声明的内容——除此之外一无所有。没有 SQLite 或本地对象路径，没有 S3 凭证，没有内部令牌，没有同级租户。在能力层强制执行，而非依靠约定。 主机是一个单一的异步 Rust 进程——没有 GC 暂停，没有解释器，没有套接字与 Worker 之间的 sidecar 跳转。 core ── storage ── artifacts ── runtime（同级，较低层级） └── workers（可使用 core/storage/artifacts，从不使用 runtime） └── service（组合根：CLI、HTTP、workerd 桥接） ocd 编译运行时配置，将 workerd 作为受监督的子进程启动，并通过仅限回环的通道进行通信。它负责就绪状态、优雅关闭、重启退避和恢复。 部署是不可变的且内容寻址的。workerLoader 键是部署标识，因此晋升和回滚只是移动一个指针——它们从不改变已经在运行的内容。 Dashboard 管理通过 /client/v4 暴露的计算、存储、AI 和平台资源。它还会在当前 ocd 守护进程注册的实例之间切换。 当 Worker 需要本地硬件、专有库或内部守护进程时，操作员可以注册原生扩展：一个带有少量 JavaScript 外观的原生 Provider 进程，通过 cf Service Bindings（bindings.worker + props）暴露给 Workers。 扩展教程介绍了完整的设置过程。仓库中还包含一个小的 Rust 参考 Provider。 不是 Cloudflare 的全球边缘。你运行的基础设施上的一个节点——没有 Anycast，没有跨区域复制，没有 POP 网络。这一取舍正是为你换来强大的本地一致性。 不是通用的即插即用替代品。兼容性按功能面逐一跟踪，每个偏差都有文档记录，而不是被掩盖。 不是多副本高可用集群。一个守护进程，一台机器，以及隔离的每实例权威——这是设计使然。 文档 目标 从这里开始 理解设计 架构和项目指南 检查 API 支持 兼容性 · Worker API 索引 跟踪不支持的功能 不可用 构建和部署 Workers 开发 下载和发布 GitHub Releases · 项目指南 在生产环境运行 入门 · 运维 运维和恢复 运维 · 事故指南 贡献 贡献指南 · 行为准则 安全 使用 SECURITY.md 私下报告漏洞。 Apache-2.0。打包的 open-compute workerd 分支仍受适用的上游 Cloudflare workerd 许可约束。