10 月 9 日，Deno 团队宣布加入 Cloudflare，同时启动了两只倒计时：Deno runtime 只再提供一年按月发布的漏洞修复和安全更新，Deno Deploy 继续运行六个月后关闭。第二天，TechCrunch 将这笔交易确认为收购，双方没有披露金额。Cloudflare 得到的因此不只是又一个 JavaScript runtime 团队，而是 Deno 已经转向的新项目 celld——一套试图把 Workers 和 Durable Objects 放回开发者自有基础设施的系统。
这也是一次明确的路线取舍。Deno 不再继续同时经营独立 runtime、托管平台和分布式运行层，Ryan Dahl 与 Bert Belder 将在 Cloudflare 领导 workerd 自托管项目，把 celld 的代码与设计并入其中。对 Cloudflare 来说，收购要补的不是开源许可证，而是 workerd 尚未补齐的分布式状态能力；对 Deno 用户来说，代价则是原有产品线进入迁移期。
Deno 停止并行造运行时，把团队押到 Workers 编程模型
Deno 官方把产品去向说得很具体。runtime 在未来一年继续获得每月一次的修复和安全更新，之后 Deno 团队停止开发；代码仍然开源，但官方没有宣布基金会、继任维护者或新的治理安排。Deno Deploy 将在六个月后关闭，付费客户可获得迁往 Cloudflare Workers 的支持。JSR 包注册表继续运行，基础设施迁到 Cloudflare；连接 Rust 与 V8 的 rusty_v8 也会继续维护，并计划接入 workerd。
这意味着“Deno 加入 Cloudflare”并不是两个 JavaScript runtime 长期并行。Deno 公告写明，团队会把未来开发投入共享平台，不再维护一套独立 runtime 和托管服务。独立开发者仍可继续使用开源代码，但企业用户要面对一个实际的维护边界：一年后谁负责版本演进、漏洞响应与生态兼容，目前没有交接方案。
独立开发者 Simon Willison 抓住了这笔交易最直接的代价：Deno 最有辨识度的细粒度权限系统仍在代码中，但原团队的重心已经从“改进 Node.js 替代运行时”转向“为分布式服务器建立新抽象”。Cloudflare 收购的核心资源，正是做出这种取舍的团队。
workerd 缺的是跨机器状态，celld 用对象存储补这一层
workerd 是 Cloudflare Workers 在线上使用的同一套开源 JavaScript/Wasm runtime，开发者今天已经能在自己的服务器运行它。真正的缺口在 Durable Objects：Cloudflare 官方承认，workerd 的实现只能支持单实例，足够本地测试，却不能在多台机器之间完成对象放置、请求路由和持久状态恢复。Cloudflare 线上版本依赖大量内部服务与运维系统，也不适合作为一个可移植发行版直接交给用户。
celld 选择了一条更窄的路径。每个 Durable Object 被实现为一个带独立 SQLite 数据库的“cell”，任一时刻只由一个节点持有；多个节点共享一个兼容 S3、Google Cloud Storage 或 Azure Blob Storage 的 bucket，用条件写入决定所有权，并保存部署、状态和租约记录。节点失效后，另一节点可以接管 cell 并从对象存储恢复。两台以上节点还可先把写入复制到同伴磁盘，再异步上传 bucket，减少每次写入都等待对象存储往返的延迟。
在收购宣布前两天发布的 v0.6.2 中，celld 已支持 Workers、Durable Objects、KV、Queues、D1、R2、Workflows、Cron Triggers、静态资源和 Dynamic Workers；这不是只有架构图的原型。它把 Cloudflare 多种有状态服务映射为同一种 cell、租约和故障接管机制，展示了如何用一套较小的依赖重建 Workers 编程模型的核心部分。
celld 已能跑分布式应用，却不是完整 Workers 控制面
把 celld 称为“自托管 Cloudflare Workers”容易掩盖三个边界。第一，v0.6.2 的一个 fleet 只能运行一个应用，没有账户服务、多租户调度器或托管入口；它负责 cell 在节点间的归属和恢复，并不负责把多个客户安全地装进同一平台。第二，Workers AI、Vectorize、Hyperdrive、Browser Rendering 和 Email Workers 都未实现，Python Workers 也只有部分支持。第三，TLS 终止、节点扩缩容、私网加密、入口负载均衡和 bucket 权限仍由使用者配置。
因此，交易宣布时可以确认的能力与路线图应分开看：
| 状态 | 已确认内容 |
|---|---|
| 今日可用 | workerd 可单机自托管；celld v0.6.2 可运行多节点 Durable Objects 及一组 Workers 服务，但仍是 beta |
| 已宣布 | celld 的代码和设计将并入 workerd，Ryan Dahl 与 Bert Belder 领导该项目，Cloudflare 要把自托管做成正式支持路径 |
| 尚未承诺 | 合并版本的发布日期、迁移工具、兼容矩阵、多租户与账户控制面、托管 Workers 和自建集群之间的数据迁移 |
这张表也限定了 Cloudflare 所说的“逃生舱”。开源 runtime 和可迁移的编程模型能降低采购前对锁定的顾虑，却不等于应用可以无修改地搬走，更不等于自建集群自动获得 Cloudflare 全球网络、GPU 或浏览器集群。celld 的兼容页逐项记录差异，部署时也会拒绝未知 Wrangler 配置；这比口号更接近可检验的可移植性，但仍需要应用级测试。
收购把自托管从社区项目变成 Cloudflare 的产品责任
Cloudflare 的商业逻辑并不矛盾：让客户拥有一条真实可用的退出路径，可能比制造无法退出的锁定更容易赢得大型客户。公司称，过去已经有客户借助 workerd 离开，而开源 runtime 仍帮助它拿下更多原本不会采用 Workers 的客户。celld 则把这条路径从“能启动同一 runtime”推进到“能在多台机器上保存和恢复状态”。
收购真正改变的是责任归属。此前，celld 可以被视为 Deno 对 Cloudflare 平台缺口的外部实现；合并计划公布后，Cloudflare 要决定哪些能力进入 workerd、如何维护兼容，以及自托管是否只是源代码可用，还是有版本、升级和故障恢复承诺的正式产品。官方只说未来数月还会发布更多消息，没有给出交付时间。
接下来最值得观察的不是仓库是否换了组织名，而是三个可验收结果：celld 的分布式 Durable Objects 何时进入 workerd 的正式版本；Wrangler 项目在托管 Workers 与自建集群之间能通过多少兼容测试；Cloudflare 是否提供多应用隔离、升级流程和长期支持边界。在这些结果出现前，开发者今天能自托管的是两套各有缺口的实现，而不是一套已经完成合并的“私有 Cloudflare”。
