Celld：把 Cloudflare 的 Durable Objects 搬回你自己的服务器

原文来源：denoland/celld（GitHub） — 自托管、分布式的 Durable Objects，把 Cloudflare 的有状态计算模型带到你自己的机器上

Cloudflare Workers 的无服务器模型很香，但它的有状态组件 Durable Objects 一直是个"平台绑定"的痛点——你想用就得在 Cloudflare 生态里玩。8 月 5 日，Deno 官方（就是 Ryan Dahl 亲自提交代码的那个项目）发布了 celld，一个让你在自己机器上跑 Workers 和 Durable Objects 的开源守护进程，Apache-2.0 协议，GitHub 上 2.9k stars，一周内冲到 Hacker News 282 分。

它解决了什么问题

Durable Objects 是 Cloudflare 提出的有状态计算模型：每个对象是一个独立的、按名字寻址的状态单元，有持久存储、有单线程执行保证，天然适合做 WebSocket 房间、协作编辑、队列、分布式锁这类需要"某个逻辑单元持有状态"的应用。

问题在于这套模型和 Cloudflare 平台深度绑定。你想自托管，以前基本没得选——要么自己拼数据库加一致性方案，要么忍受供应商锁定。celld 的思路是：把 Durable Objects 的运行时整个开源，用你已有的基础设施（一台机器 + 一个 S3 兼容存储）跑起来。

核心设计：没有控制平面，S3 就是一切

celld 的架构思路非常"Deno"——极简、反共识。

每个对象是一个独立的 SQLite 数据库。 按名字寻址，应用天然分片：不存在一个共享大库的争用问题，一个对象挂了爆炸半径也只限于它自己。这种"每个对象一个库"的设计把分布式系统里最头疼的共享数据库问题直接设计掉了，而不是靠运维去管理。

节点之间只通过 S3 兼容 bucket 协调。 部署包、cell 状态、小的所有权记录都放在一个 bucket 里。对象存储的 compare-and-swap 操作保证"同一个 cell 同一时刻只有一个节点拥有它"——没有成员协议、没有故障检测器、没有共识服务。celld 持续把每个 cell 的 SQLite 数据库复制到 bucket；当 cell 迁移或被唤醒时，新主人从 bucket 恢复数据库继续执行。bucket 是持久真相的来源，节点是可以随时替换的。

空闲即休眠。 空闲的 cell 会休眠到几乎不占资源，这对按量付费的 VPS 很友好。

每个 celld 节点都内嵌 V8 引擎，直接执行 Wrangler bundles——也就是说，你给 Cloudflare Workers 写的代码，理论上可以直接部署到 celld 上，迁移成本很低。

怎么上手

安装是一条命令：

curl -fsSL https://celld.dev/install.sh | sh

部署 Worker 项目到 bucket，然后启动节点：

celld deploy . --bucket s3://my-cells-bucket
 
celld --bucket s3://my-cells-bucket \
  --listen 0.0.0.0:8080 \
  --advertise 10.0.0.12:8080

用 Docker 也一样，官方镜像发布在 ghcr.io/denoland/celld，支持 Linux x86-64 和 ARM64。Worker 代码需要 esbuild 在 PATH 上（纯静态资源项目不需要）。

安全与运维细节

这个项目刚发布，安全模型写得很直白，值得留意：

• peer HTTP 不终止 TLS。节点间的 HTTP 通信要求放在可信私有网络或 WireGuard/Tailscale 加密隧道里，别直接暴露公网端口。字面意义的公网 IP 会被拒绝，除非你显式传 --unsafe-public-advertise。
• bucket 访问权 = 管理员权限。所有 peer 请求带协议版本号、HMAC 认证、时钟边界和防重放保护，密钥存在 bucket 里的 fleet/peer-auth.json。谁拿到 bucket 凭据谁就能控制整个 fleet。
• celld diagnose 一键体检。枚举所有节点租约，对每个在线 peer 做签名直连探测，区分过期记录、异常地址、不可达节点和协议不兼容，还会打印每个节点的常驻 cell 数、WebSocket、RSS、CPU、文件描述符等指标。
• 压力卸载是渐进式上线的。v0.1.0 把负载卸载重写了：常驻 cell 上限变成准入时的硬限制，压力驱逐只看 RSS 和 CPU；满载节点拒绝新放置而不是驱逐已有 cell。想精细控制可以用 CELLD_MAX_RESIDENT_CELLS、CELLD_MAX_RSS_MB 这些环境变量。

一些值得注意的立场

有两件事能看出 Deno 团队做这个项目的态度：

贡献方式很特别。 这个仓库直接禁用了 Pull Request——作者的理由是"编码智能体太容易发出大而低上下文的改动，维护者花的时间比省下的还多"。想贡献，用 git format-patch 把补丁邮件发给 ry@deno.com。考虑到 2026 年开源维护者被 AI 生成 PR 淹没的现状，这个决定虽然激进，但逻辑是自洽的——README 里明说"请先理解代码、保持补丁聚焦、尊重你要求的评审时间"。

许可在 v0.1.0 换成了 Apache-2.0。 从 v0.0.1 到 v0.1.0 一周内完成重许可，为的是让项目可以放心用于商业生产。官方文档也提醒：运营公开 fleet 之前，先读 limitations 和 security 页面。

适合谁用

• 想摆脱供应商锁定的 Workers 用户：代码兼容 Wrangler bundle，迁移成本低
• 自托管爱好者：一台 Linux 机器 + 一个 S3 兼容存储（MinIO、R2、AWS S3 都行）就能跑
• 边缘计算 / 有状态应用开发者：需要 WebSocket 房间、协作状态、分布式队列这类能力，又不想上 Kafka 级重装备

坦白说，项目才 v0.1.0，分布式协议还在演化中，生产环境部署前需要认真读文档、做故障注入测试。但"用对象存储代替共识来做分布式协调"这个思路本身就很值得关注——如果它能跑稳，自托管有状态应用的复杂度会被砍掉一大截。