先看证据
加入Cloudflare，重心却不在Deno Runtime
2026年10月9日，Deno宣布团队加入Cloudflare，双方计划把Deno团队开发的celld与Cloudflare的workerd结合，让Workers编程模型能够在Cloudflare以外的自有基础设施上运行。公告所说的是团队加入以及后续技术计划，交易金额和具体结构并未公开，因此不宜把它理解为Deno所有产品都会被Cloudflare接续经营。
这次变化值得技术负责人读，不是因为又多了一个JavaScript运行时阵营，而是因为两家公司把重心放在了部署边界：Cloudflare想让Workers不只是一种托管服务，也成为可以自托管的运行模型。代价同样写在公告里：Deno Runtime还会获得一年的月度版本更新，包含修复和安全更新，之后Deno团队将停止开发；Deno Deploy则计划再运行六个月后关闭，并协助付费客户迁移到Workers。
自托管要解决的是Durable Objects的多机运行
Cloudflare已经开源workerd，但按其公告，当时Durable Objects支持仅适用于单实例，不能据此构建可扩展的多机部署；生产环境的分布式路由则依赖Cloudflare自己的网络基础设施。于是，“把Workers带到自有机器”并不只是把运行时二进制下载下来，还得回答对象状态放在哪里、哪台机器负责处理它，以及机器失效后如何接手。
Durable Objects的编程模型把协调单元从整台服务器转向一个个有身份的对象。每个对象有自己的持久化SQLite数据库，JavaScript在对象内单线程执行，也可以处理WebSocket；例如聊天室可以按频道创建对象，让频道数据和连接分散到不同对象上。这样做的吸引力在于，应用逻辑围绕有状态对象组织，而不是由开发者先搭一套通用服务器集群，再自行拼接状态和连接管理。
celld把集群协调交给对象存储
celld是Deno团队为Workers和Durable Objects自托管开发的实现，Cloudflare称其首版在8月发布。它由多个运行celld的节点组成一个fleet，共享对象存储桶；桶里保存部署内容、对象状态和所有权记录。每个cell同一时刻只由一个节点持有，节点通过对象存储的条件写入竞争取得所有权，而不是另设一套集群成员协议或共识服务。
写入确认方式会随部署形态变化。单节点模式必须等数据上传到对象存储后才确认写入；多节点模式可以先把SQLite写入日志复制到其他节点的磁盘，在达到持久化条件后确认，再异步上传对象存储。这个设计把一部分协调工作交给已有的对象存储，但没有让持久化问题消失：单节点要承受等待对象存储的延迟，多节点则要判断磁盘副本、节点故障和后续上传之间的恢复边界。公开文档没有给出可通用于不同部署的延迟或吞吐数字。
计划合并不等于部署能力已经到位
Cloudflare表示，Ryan Dahl和Bert Belder将推进workerd自托管，并把celld的代码和设计思路合并进workerd。公告将此描述为未来几个月的工作，合并尚未完成，也没有给出可供团队直接采用的正式支持方案。对已有Workers用户来说，眼下能判断的是目标方向，而不是迁移工具、运维承诺或生产级故障恢复细节已经确定。
这一区别很重要：开源workerd提供了运行时出口，不自动等于完整的平台出口。开发团队仍要核实对象存储条件写入的语义是否适合自己的持久性要求，也要评估写入延迟、节点接管和状态恢复；这些问题不能仅凭“自托管”三个字解决。Cloudflare对Workers锁定争议的回应，是强调开源workerd提供迁移出口，但公告本身并没有证明用户迁移的难度已经消失。
Deno为何退场，团队为何转向新抽象
Ryan Dahl在Hacker News上的解释，为这次取舍提供了比公司公告更直接的理由。他认为Deno有好的设计，但逐渐被Node兼容性牵引，最终必须像Node一样工作；如果目标只是重新实现Node，有限的性能、体验或安全优势不足以构成长期方向。他更想投入的是新的服务器抽象，而celld所依赖的对象存储协调和持久化，在他看来提供了不同于文件系统或网络API微调的开发模型。
Deno的权限系统曾是运行时差异之一：脚本可以被限制为只读写指定文件和目录，并访问指定网络主机。Node.js后来也加入了权限模型，Node 20.0.0于2023年4月加入该能力，Node 22.13.0于2025年1月将其标记为稳定；不过，Node当前还不能按主机设置网络允许列表。这个对照说明Deno仍有具体的设计特色，却也解释了为何单靠运行时层面的差异，未必足以支撑一个独立的产品方向。
技术负责人现在可以据此做什么判断
如果团队正在使用Workers，合理的判断不是立即把自托管写进架构承诺，而是把它列为待验证的部署选项：等待workerd与celld的整合进展，再用实际工作负载检查状态持久化、写入确认和故障接管是否符合要求。尤其要区分单节点与多节点路径，因为它们确认写入所依赖的持久化条件不同。若应用依赖Cloudflare网络或其他托管能力，自托管运行时本身也不能保证这些依赖随之可用。
如果团队依赖Deno Runtime，则应把一年维护承诺当作明确的迁移窗口，而不是长期支持保证；开源项目仍然存在，也不等于之后会有稳定的官方维护者。Deno Deploy付费用户则需要关注公告所说的六个月运行期和迁移支持。更大的判断是：这次合作把资源从维护一个通用运行时转向构建可移植的有状态应用平台，但真正的可移植性要由成熟的部署、恢复和维护承诺来证明，不能由代码开源或计划中的合并单独担保。