celld开源：Deno推出自托管分布式Durable Objects，Cloudflare Workers的

2026年8月6日，Deno团队（由Node.js创始人Ryan Dahl领导）正式开源了celld——一个可以在自己服务器上运行的自托管、分布式Durable Objects运行时。项目上线即获得1,600+星标，在Hacker News引发热烈讨论。

Ryan Dahl：从Node.js到Deno，再到celld

要理解celld的意义，必须先了解Ryan Dahl的轨迹。2009年，Dahl创建了Node.js，彻底改变了JavaScript的格局——让这种原本只能跑在浏览器里的语言登上了服务器。Node.js的巨大成功让JavaScript成为全栈语言，但Dahl在2018年JSConf EU上发表了著名的演讲《我对Node.js感到后悔的十件事》，坦言Node.js存在安全模型缺失、模块系统过度复杂、package.json膨胀等设计缺陷。

这些反思催生了Deno——一个”secure by default”的现代JavaScript/TypeScript运行时，内置TypeScript支持、去中心化的模块系统、以及权限沙箱。Deno不只是Node.js的替代品，而是Dahl对整个服务端JavaScript生态的重新思考。

如今，celld标志着Deno生态的又一次扩张：从”替代Node.js”走向”替代Cloudflare Workers的平台锁定”。Dahl正在构建一个完整的、开源的服务端JavaScript基础设施栈——从运行时（Deno）到分布式有状态计算（celld），用户无需依赖任何单一云厂商。

为什么Deno要投资celld？

Cloudflare Workers的Durable Objects是边缘计算领域最亮眼的设计之一：每个对象拥有独立的SQLite数据库和全局唯一ID，天然适合构建协作应用、游戏状态、AI会话等有状态场景。但这种强大能力被锁在Cloudflare的围墙花园里。

Deno团队的战略意图很清晰：

1. 打破平台锁定：让Durable Objects的编程模型脱离Cloudflare，成为通用的、可移植的分布式计算范式

2. 与Deno Deploy形成互补：Deno Deploy是Deno自家的边缘计算平台（类似Cloudflare Workers），celld则为需要自托管或混合部署的客户提供了”逃生舱”

3. 扩大Deno生态的护城河：如果开发者用Durable Objects API写的代码可以在Cloudflare和celld之间自由迁移，Deno就成为了这个生态的标准制定者

4. Rust技术栈的延续：Deno核心就是Rust写的，celld同样是Rust项目，团队有深厚的技术积累

Durable Objects的”去平台化”

Cloudflare Workers最强大的特性之一就是Durable Objects——一种有状态的、持久化的计算单元，每个对象拥有独立的SQLite数据库和唯一ID，天然支持分布式架构。

但Durable Objects有一个致命局限：只能运行在Cloudflare平台上。如果你想在自己的VPS、裸金属服务器或混合云上跑，对不起，不行。

celld解决了这个问题。它是一个Rust编写的守护进程，内嵌V8引擎（Deno的JavaScript运行时核心），可以直接在你自己的机器上运行Cloudflare Workers和Durable Objects。这意味着：

– 你写的Worker代码无需修改就能在celld上运行

– 每个Durable Object仍然是独立的SQLite数据库

– 数据备份到你自己拥有的S3兼容存储（MinIO、AWS S3、Cloudflare R2等）

– 无需控制平面、无需共识协议——节点通过对象存储的CAS操作协调

CAS协调机制：技术深度解析

celld的分布式协调方案极其优雅，值得深入理解。传统分布式系统处理”谁拥有哪个对象”这个问题时，通常需要引入Raft/Paxos共识算法、成员协议（membership protocol）、心跳机制、故障检测器等复杂组件。这些组件本身就有大量的边缘情况和运维负担——脑裂、选举超时、日志压缩……每个运维过etcd或ZooKeeper的人都深有体会。

celld的选择是：全部砍掉，只用一个共享的S3兼容存储桶。

核心机制是对象存储的原子Compare-And-Swap（CAS）操作。当节点需要获取某个Cell的所有权时：

1. 节点读取存储桶中该Cell的当前所有权记录（包含拥有者ID和epoch版本号）

2. 如果Cell无人持有（或原持有者租约已过期），节点发起CAS写入，声明”我是新拥有者，epoch为N+1″

3. CAS保证：只有当存储桶中的记录”仍然是步骤1读到的值”时，写入才成功。如果另一个节点抢先写入了，CAS失败，当前节点需重试

4. 获取所有权后，节点从存储桶恢复该Cell的SQLite数据库快照，将其加载到内存并开始处理请求

整个过程的关键设计决策：

– 存储桶是唯一的真相来源（source of truth），节点是完全无状态、可替换的

– 写前复制（RPO=0）：celld在前端确认写入之前，必须先将数据持久化到存储桶，保证节点故障不会丢失已确认的数据

– 无需成员列表：节点通过读取存储桶中的租约发现自己应有的同伴，不存在”加入集群”的操作

– 节点间通信通过签名HTTP：每个节点有独立的HMAC密钥，防止重放攻击和伪造请求

一个具体的场景：用户请求到达某个celld节点，该节点发现自己不持有目标Cell。它读取存储桶发现Cell所有者是node-B，于是通过签名HTTP将请求转发给node-B。node-B处理完请求后，将SQLite的WAL日志增量同步到存储桶。如果node-B宕机，其他节点检测到其租约过期，通过CAS抢到Cell所有权，从存储桶恢复最新数据库，继续服务。

真实部署场景

celld在以下场景中尤其有价值：

1. 数据合规与主权：金融、医疗、政府等行业要求数据必须存储在特定地理位置或自有硬件上。celld让这些行业也能享受Durable Objects的编程模型，而不需要把数据交给Cloudflare

2. 混合云架构：核心服务部署在自己的数据中心，利用celld处理有状态工作负载；突发流量时可以扩展到公有云上的celld节点，共享同一个S3桶

3. 边缘/离线场景：IoT设备、工厂车间、远洋船舶等网络不稳定或完全离线的环境，可以本地运行celld + MinIO，在网络恢复时同步数据

4. 成本敏感的高流量应用：一个拥有百万级Durable Objects的应用，如果每个请求都走Cloudflare的按量计费，成本可能极高。自建celld集群配合自有硬件或廉价VPS，在足够规模下可以显著降低成本

5. 开发与测试环境：开发者可以在本地用celld + MinIO模拟完整的Cloudflare Workers + Durable Objects环境，无需依赖Cloudflare账号和网络

局限性与”什么时候不该用”

celld并非银弹，在以下情况下应谨慎或避免使用：

1. 还在Alpha阶段：按照官方文档，celld目前存在明确限制：一个集群只能运行一个应用、没有多租户调度器、TLS需要自己在外层处理、Windows不支持、压力驱逐（pressure shedding）默认关闭等待调优

2. 没有全球边缘网络：Cloudflare Workers的核心优势是全球300+节点的超低延迟边缘网络。celld部署在你自己选择的服务器上，延迟取决于服务器位置。如果你的用户遍布全球且延迟至关重要，celld暂时替代不了Cloudflare

3. 运维负担：你需要自己管理服务器、S3存储桶、网络安全、TLS终止、监控告警。对于小团队，”简单”可能是伪命题——虽然celld没有etcd/ZooKeeper，但你仍然需要运维Linux服务器和S3服务

4. 生态集成缺失：celld不支持Cloudflare的KV、R2（虽然可以用S3替代）、D1、Queues等深度集成的周边服务。如果你重度依赖这些服务，迁移成本不低

5. WebSocket跨节点迁移的限制：当一个Cell从一个节点迁移到另一个节点时，现有的出站WebSocket连接不会自动跟随，需要在应用层处理重连逻辑

6. 不要为了”去锁定”而去锁定：如果你的应用规模不大，对Cloudflare的体验满意，没有合规需求，强行迁移到celld只会增加不必要的运维复杂度

安装与上手

安装非常简单：curl -fsSL https://celld.dev/install.sh | sh，然后用celld deploy部署Worker项目。项目使用Apache-2.0开源协议，Rust编写，生产级可靠性有Deno团队背书。

celld的哲学可以概括为：你的代码，你的数据，你的服务器。它不试图成为Cloudflare的替代品，而是确保Durable Objects的编程模型不会成为单一平台的囚徒。对于重视数据主权、需要灵活部署、以及希望保留”随时离开”能力的开发者来说，celld是一份重要的自由。

— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn