来源：
- Cloudflare 博客：Deno is joining Cloudflare（Ryan Dahl & Kenton Varda）
- Deno 官方博客：Deno is joining Cloudflare（Ryan Dahl）
发布时间：2026 年 10 月 9 日
标题里的「Deno 时代」，指的是 Deno 作为独立运行时和托管平台的这条路线。这条路线确实走到了终点，但 Deno 项目本身会继续开源，后续是否有人接手，目前还没有答案。
先说结论
整个 Deno 团队加入 Cloudflare。表面上是团队合流，实质上是一次战略转向：
- Deno 团队把后续开发投入到 Cloudflare 的 Workers / Durable Objects 编程模型上，目标是让它成为构建服务端应用的默认方式，不论跑在 Cloudflare 网络上还是自己的基础设施上
- Deno 自己的 运行时和托管服务不再作为独立产品继续发展
- 具体来说，是把 Deno 团队的自托管项目 celld 与 Cloudflare 开源的 workerd 合并
对 Deno 用户最重要的时间线
这部分是 Deno 官方博客给出的具体安排，正在使用 Deno 的人务必留意：
| 项目 | 安排 |
|---|---|
| Deno 运行时 | 再支持一年，期间每月发布 bug 修复和安全更新；一年后 Deno 团队终止开发。项目保持开源，欢迎他人接手 |
| Deno Deploy | 继续运行六个月后关停；付费客户可获得迁移到 Cloudflare Workers 的支持 |
| JSR | 继续运营，基础设施迁往 Cloudflare |
| rusty_v8 | 继续维护，并推进集成到 workerd |
如果你的项目在用 Deno Deploy，迁移窗口只有半年，需要尽早评估。如果只是用 Deno 做本地工具或脚本，短期不受影响，但一年后需要考虑社区接手情况或迁移方案。
Ryan Dahl 为什么这么选
Ryan 把自己的路线概括为一条主线：让服务端软件更简单，不再让每个应用自己拼装基础设施。
从 Node.js 到 Deno，再到 Deno Deploy，最后到 celld，他一直想解决的其实是同一件事。
- Node.js 当年证明了异步 I/O 能让服务器代码非常简洁，但那个 500 行的 IRC demo 是单机单线程的，一旦要扩展，就要面对跨机器分片、数据存储等一系列问题
- Deno 改善了 JavaScript 的开发体验，但没有改变开发者要在运行时之外自己拼装分布式基础设施的现实
- 运营 Deno Deploy 让他看到了底层有多复杂：多云、多数据库、服务层层耦合
- 他在 Cloudflare 的 Durable Objects 里找到了答案：带 SQLite 的分布式单例，一个实体对应一个 DO，数据和 WebSocket 连接天然分片
- 他做了 celld：单个 Rust 二进制，唯一的外部依赖是对象存储，部署时只管多个 celld 实例加一个存储桶
在他看来，扩展能力应该内置在编程模型里，而不是每个应用自己去搭建。
AI Agent 是明确的动机
Deno 官方博客特别强调了 AI 场景。Ryan 认为 Durable Objects 把几项对 agent harness 特别有用的能力放在了一起：
- 低成本的 Serverless 执行
- 持久化状态
- WebSocket
- 高层的 JavaScript 接口
这也是 celld 聚焦 Durable Objects 的原因。他还在文末公开邀请：如果你在大规模构建 agent，并想跑在自己的基础设施上，可以直接联系他。
Kenton Varda：「厂商锁定」是个误会
Cloudflare 一侧的 Kenton 回应了网上长期存在的一种说法：Workers 故意做得与众不同，是为了锁定客户，而 celld 这种开源实现会破坏这个策略。他认为这个说法不成立。
Workers 与众不同，是因为它确实更好
- 架构更高效，管理遍布全球数百个节点的应用既简单又便宜
- 「bindings」这种实时环境设计，让访问外部资源更易配置也更安全
- Durable Objects 让实时协作和分布式系统更容易实现，这在传统三层架构下很难甚至做不到
- 想要这些收益，就无法与现有平台完全兼容
锁定对 Cloudflare 自己不利，所以才开源
2022 年 Cloudflare 向 Shopify 等客户推销 Workers for Platforms 时，对方明确要求运行时必须开源。于是有了 workerd，它与生产环境运行的是同一份代码，而不是平行实现。有客户用 workerd 迁走了，Kenton 认为没关系：没有开源，这些客户一开始就不会签约。
Cloudflare 的坦率自我批评
Kenton 承认了几个问题：
- 开源 workerd 之后，Cloudflare 没有认真建设周边生态和工具，只是寄希望于社区自己去适配，结果并没有发生
- workerd 最大的生产化缺口是 DO：只支持单实例，适合本地测试，不能横向扩展
- Cloudflare 自己的生产级 DO 路由实现过于庞大，依赖大量由 SRE 团队运维的外部服务，不适合自托管用户
- 他自己去年春天尝试做过自托管方案，没有成功
所以 celld 对他们来说正好补上了这个缺口：一个完全兼容 Workers 和 DO、同时专注自托管和可扩展的实现。Deno 团队在自托管运行时的开发者体验上经验丰富，这也是 workerd 一直没做好的部分。
接下来的计划
- Ryan Dahl 和 Bert Belder 将领导新项目，把 workerd 的自托管做成官方一等支持的使用方式
- 把 celld 的代码和思路合并回 workerd
- 未来几个月会有更多公告
- 现在就可以自己试用：celld 和 workerd 都能自托管
- Kenton 表示，他打算在家里用它跑一个 Cloudflare OS 实例
我的几点解读
- 这是 Deno 独立路线的终点。 官方措辞很克制，但「一年后终止运行时开发、半年后关停 Deploy」意味着 Deno 作为独立产品生态的退场。运行时能否被社区接手，是后续最大的变数。
- 对 Node.js 生态的格局影响有限，对 Deno 用户影响很大。 短期内真正需要行动的是 Deno Deploy 用户和深度依赖 Deno 特有能力的项目。
- Workers 模型想成为通用的服务端标准。 如果 workerd 的自托管真正成熟，Cloudflare 的「锁定」争议会明显缓和。但合并后的路线图和生产可用性，还要等后续公告才能判断。
- Durable Objects 的抽象值得关注。 「一个实体一个 DO，自带数据库」的思路，对做实时协作、聊天、agent 这类状态密集型应用很有参考价值。
本文为对两篇官方博客的中文提炼与解读，具体安排与时间线请以官方公告为准。