多年来，我们一直想让服务端软件构建更简单，并思考模块分发、JavaScript 运行时安全与工具链。与 Node.js（Node.js）兼容也很重要：用户希望用 Deno（Deno）改进并接入现有 JS 生态。团队和社区打造出整合这些能力的运行时，并挑战 JS 开发设想。今天，整个 Deno 团队加入 Cloudflare（Cloudflare）以推进这项工作。我们的目标不止于运行时，希望计算、存储与通信协同；借助 Deno Deploy（Deno Deploy），更进一步，但底层复杂性仍待简化，这也催生了 celld（celld）。
正文
多年来，我们一直想让服务端软件开发变得更简单。从模块分发方式、JavaScript 运行时该提供的安全保证、完整工具链应包含什么，到应用如何作为独立可执行文件分发，我们都在重新思考。兼容 Node.js 后来也成了重点：用户希望继续接入现有 JS 生态，同时获得 Deno 的改进。团队和社区最终把这些能力整合进一个运行时，也挑战了人们对 JS 开发可能形态的设想。
今天，我们宣布整个 Deno 团队加入 Cloudflare，把这项工作继续向前推进。
我们的目标从来不止于运行时。在 JavaScript Containers 这篇文章里，我写过：计算、存储和通信应当协同工作，而不是每个应用都自己拼凑一套基础设施。
Deno Deploy 让我们朝这个目标又近了一步，希望把运行应用变得尽可能简单。但构建和运维 Deploy 的过程也让我看到，在这种开发体验之下仍藏着大量复杂度。我也想简化这一层。
这带来了 celld。它基于 Cloudflare Workers 的编程模型，让开发者从一开始就构建分布式应用，同时系统依旧易于运维。最让我兴奋的是，扩展能力被写进了编程模型，而不是留给每个应用自行搭建基础设施。
从 Deno 到 Deno Deploy 再到 celld，这条演进路径说明了为什么这次加入对我们说得通。在 Cloudflare，我们会把自己的工作与 Workers 和 Durable Objects 团队的工作结合起来，希望让这套编程模型成为构建服务端的默认方式——无论你运行在 Cloudflare 网络上，还是自己的基础设施上。
加入也意味着选择把精力投向哪里。我们决定把未来的开发工作放进这个共享平台，而不是继续单独做一个运行时和托管服务。我们知道，对已经在 Deno 上构建项目的人来说，这会是一个重大影响。
感谢所有贡献过代码、基于 Deno 建立业务、报告过问题，并信任我们方向的人。这意味着什么，具体来说：
- 我们会在接下来一年继续维护 Deno runtime，每月发布包含错误修复和安全更新的版本。一年后，我们将停止开发 Deno runtime。Deno 仍会是开源项目，也欢迎其他人接手继续开发。
- Deno Deploy 会继续运行六个月后关停，我们会为迁移到 Cloudflare Workers 的付费客户提供支持。
- JSR 会继续运行，其基础设施将迁移到 Cloudflare。
- 我们会继续维护 rusty_v8，并推动把它集成进 workerd。
AI 尤其需要更好的抽象。Durable Objects 汇集了几项对智能体运行环境特别有用的能力：低成本的无服务器执行、持久化状态、WebSockets，以及高级 JavaScript 接口。这正是我最想探索的方向，也是 celld 聚焦于 Durable Objects 的原因。
Kenton Varda 和我在 Cloudflare 博客的联合文章 里进一步说明了这些想法。如果你正在大规模构建智能体，并希望运行在自己的基础设施上，现在可以通过 ry@cloudflare.com 联系我。
评论
多数评论对这次收购感到失望，认为 Deno 运行时实际上会被 Cloudflare 买下后逐步关停，JavaScript/TypeScript 运行时少了一个有意义的 Node 替代品。也有高赞的技术性意见认为，真正的重点是把 celld 与 workerd 合并，可能做出可自托管的开源 Workers 运行时，并对 Ryan Dahl 团队表示祝贺。
认为 Deno 运行时一年后就会被实质放弃
- Cloudflare 只承诺接下来一年继续提供修复和安全更新，之后就会结束 Deno 运行时的开发；除非社区有人接手，否则就是不再维护。多人认为标题不该是“Deno 加入 Cloudflare”，而是人才收购后的关停与抽干。（高赞） > 官方说只再支持一年，之后就会结束 Deno 运行时的开发；除非有人接手，否则它就是不再维护了。（@theodorejb）
认为真正的重点是把 celld 并入 workerd，做出可自托管的开源 Workers 运行时
- Cloudflare 官方说明，Ryan Dahl 团队会把 celld 与 workerd 合并，做成一流的开源、可自托管的 Workers 与 Durable Objects 运行时；支持者认为这比继续维护 Deno 更有想象空间，也有人原本担心 celld 被砍，看到说明后改观。（高赞） > 我们会把 celld 合并进 workerd，做出一个头等的、开源且能自己托管的 Workers 与 Durable Objects 运行时。（@kentonv）
认为两个有意义的 Node 替代品都被大厂吸收，开源创新与选型信心一起受挫
- Deno 进入 Cloudflare，Bun 又被视为过度追求增长，社区感到仅有的 Node 替代路线都被专有体系收编；有人不再相信开源项目不会被买走后关停，新项目选型更迷茫，倾向回到 Node，也有人用“Node 之后是 Deno，然后就结束”的说法自嘲生态反复分叉、重写、关停。（较多人） > 过去一年里，两个唯一有意义的 Node 替代品都被专有巨兽吸收了，开源创新就此终结。（@ramesh31）
认为 Cloudflare 不继续做 Deno 运行时是个反直觉的错误
- 有日常用户强调 Deno 运行时本身体验很好、开箱即用而不臃肿；而部署、KV、Workers 等能力反而和 Cloudflare 现有产品高度重合，更像是低垂果实。因此有人不理解 Cloudflare 为什么不让团队无限期延续 Deno。（少数人） > Deno 的运行时本来像他们的秘密武器，结果最后反而没被保留。（@multisport）
认为 Deno 从一开始就难以竞争，Rust 不是护城河
- 有人认为 Deno 的败象早现，面对 Bun 的猛烈竞争，光是“用 Rust 写”并不足以成为卖点；也有观点认为在 LLM 时代，Deno 当初想解决的问题已经不再关键。（少数人） > “用 Rust 写”并不足以成为卖点，它最终还是输给了 Bun 的激烈竞争。（@rvz）
有价值的补充
- celld 的模型把持久化和协调都建立在对象存储之上，能大幅简化自托管；虽然自托管听起来仍依赖云，但 S3 已是广泛支持、也能自行部署的协议，因此这个“云依赖”反而说得通。（@ryanrasti）
- 有开发者原以为 Cloudflare 会借收购杀掉 celld 这个运行时，但读了官方说明后确认：他们反而会推进 workerd 成为开源、可自托管的运行时。（@vmg12）