Cloudflare 收下 Deno：Ryan Dahl 带着整个团队，去把 Workers 搬到你自己的服务器上

2026 年 10 月 9 日，Ryan Dahl 在 Deno 官网发了一篇公告，标题很克制：《Deno Is Joining Cloudflare》。措辞是"加入"，条款读起来却像一场收购：Deno 整个团队并入 Cloudflare；Deno runtime 再给一年、每月一次的 bug 修复与安全更新，之后 Deno 公司停止 runtime 开发——代码保持开源，欢迎社区接手；Deno Deploy 六个月后关停，付费客户可以获得迁移到 Cloudflare Workers 的支持；JSR 包注册表继续运营，基础设施搬到 Cloudflare；rusty_v8 继续维护，目标是并入 Cloudflare 的 workerd。

几乎同一时间，Kenton Varda 在 Cloudflare 博客发了配套文章。两边讲的是同一个故事，目标也写得毫不含糊：把 celld（Deno 今年 8 月发布的 Durable Objects 开源实现）和 workerd 合并，让 Workers 的编程模型能在 Cloudflare 的网络之外、在你自己的服务器上跑起来，成为"一等公民"。

先把硬条款摆清楚：谁留下，谁关门

公告的措辞是"joining"，但把条款一条条摊开看，这就是一次收购，外加一份写得明明白白的日落时间表：

• 人：Deno 整个团队加入 Cloudflare。Ryan Dahl 和联合创始人 Bert Belder 将牵头一个新的方向——让 Workers 的编程模型可以在自建基础设施上成为官方支持的运行方式。
• Deno runtime：再给一年，每月一次 bug 修复与安全更新。到 2027 年 10 月前后，Deno 公司停止 runtime 开发。代码保持开源，Deno 明确欢迎社区接手继续做下去。
• Deno Deploy：六个月后关停，也就是 2027 年 4 月前后。付费客户迁移到 Cloudflare Workers 可以获得官方的迁移支持。
• JSR：包注册表继续运营，基础设施搬到 Cloudflare 之上。
• rusty_v8：继续维护，目标是把它并入 Cloudflare 的 workerd。

同样值得注意的是公告没说的部分：Fresh（Deno 的 Web 框架）、Deno Sandbox（给 AI agent 跑代码的隔离执行环境）、Subhosting 和企业支持，都没有公布去向。Subhosting 本来就是建在 Deploy 的基础设施上的。已经有开发者公开指出，Supabase 的 Edge Functions 就跑在 Deploy / Subhosting 之上——这些下游厂商现在都得在 2027 年 4 月之前拿出自己的迁移方案，留给 CTO 们的思考时间并不多。

迁移本身也不是无痛的。Deno 自己的迁移指南只覆盖了"小请求处理程序"这类简单场景，完整的 Web 服务器和应用不在范围内；凡是调用了 Deno 特有 API 的代码，都得为 Workers 重写；存在 Deno KV 里的数据，公告里没有给出官方替代方案，团队得自己选型、自己搬。

真正的赌注：celld × workerd

把"收购"先放一边，这笔交易真正的技术赌注只有一个：celld。

celld 是 Deno 今年 8 月 5 日发布的 0.1.0 版本——距离这次公告只有 9 周。它是 Durable Objects 的一个开源实现，目标很具体：让公司能在自己的服务器上跑 Workers + Durable Objects 这套编程模型，而唯一的外部依赖是一个标准的对象存储桶。

为什么 Cloudflare 需要它？workerd 本来就是开源的，但它里面的 Durable Objects 支持只能跑单实例——本地测试够用，跨机器扩展不行。而 Cloudflare 生产环境的版本，依赖的是一整个运维团队和一堆外部服务，没有哪家公司愿意照搬那一套。换句话说，开源的 workerd 一直缺一块"能在生产环境自托管"的拼图，而 Deno 过去几个月恰好把这块拼图做出来了。

所以这不是 Cloudflare 收了个 runtime，而是 Cloudflare 把做出这块拼图的人整个请了进来。Dahl 和 Belder 接下来的工作，就是把 celld 的代码折进 workerd，让"自托管"成为运行 Workers 的官方支持方式。Kenton Varda 在 Cloudflare 博客的配套文章把这一点说得更直白：两家公司同一天发声，讲的是同一个平台，而不是两个 runtime。

celld 与 workerd 的合并目标：让 Workers 编程模型在 Cloudflare 网络之外也能跨机器运行

这背后还有一层商业算计。Cloudflare 公开承认：它最大的一些客户一直想要"退出选项"。2022 年 Shopify 就告诉过 Cloudflare——没有开源，就不在 Workers 上构建，于是才有了 workerd 的开源。现在把自托管补齐，Cloudflare 就可以对那些"不上公有云"的大客户说：你可以先在我们这里跑，哪天想走，代码和编程模型都能带走。退出选项越可信，大单越好签。这笔收购首先是销售武器，其次才是技术合并。

成本账也有人算过：一份第三方测评里，跑 100 个 Durable Objects 一个月，在 Cloudflare 上要 416.51 美元，在一台 celld 服务器上只要 48 美元。但这只是一个很窄的厂商对比，看看热闹就好——同一份测评也提醒，celld 还处在早期阶段，暂时不适合在同一台机器上跑不可信的外部代码。自托管的便宜，是有代价的便宜。

Dahl 的核心论点：Durable Objects 是 agent 的天然底座

公告里最值得 vibe coder 划线的，不是收购条款，而是 Dahl 的一句话论点：Durable Objects 把廉价的 serverless 执行、持久状态、WebSocket 和 JS 接口装进了一个东西里，这正是 agent harness 需要的底座。

想想 agent 到底在为什么付费：它需要便宜到可以大规模铺开的算力（试错成本得低），需要"记得自己上一步在干嘛"的持久状态（上下文不能丢），需要长连接（WebSocket）和人或工具持续交互，还需要一个 JS 开发者随手就能写的接口。Durable Objects 的设计恰好把这四样焊在了一起——每个对象是一个有自己小数据库的独立单元，天然对应"一个 agent 会话"或"一个 agent 实例"。扩展的方式也不是加机器、改配置，而是多生几个对象。

更有信号意义的是 Dahl 的动作：他在公告里公开邀请正在大规模构建 agent 的人直接邮件联系他。这不是客套话。一个刚把公司并入巨头、手里攥着下一代平台方向的人，此刻最缺的不是钱，是真实 workload 的反馈。他在为 celld × workerd 的下一步找第一批吃螃蟹的 agent 团队——你的生产痛点，就是他的路线图输入。

把 Dahl 的轨迹连起来看会更清楚：Deno → Deno Deploy → celld，终点从来不是"再造一个 runtime"，而是"Durable Objects + Workers 编程模型"。他 2009 年做了 Node.js，2018 年做了 Deno 来修正 Node 的安全模型和包管理，这一次他把答案从"换个 runtime"改成了"换个编程模型"。Runtime 之争他打了十七年，现在他认定真正值得打的是下一层。

三国杀落幕？先别急着写墓志铭

JS 运行时这场"三国杀"——Node.js、Deno、Bun——随着这次收购，算是落下了一个标志性句点。别忘了 2022 年 Deno 还和 Node.js、Cloudflare 一起搞过运行时互操作，Dahl 当时公开说过，Workers 是 Deno Deploy"最接近的竞争对手"。四年后，他带着整个团队，亲自在竞争对手的编程模型上盖楼。商场上没有永远的敌人，只有没跑通的路。

Hacker News 上这条新闻拿了 851 points、467 条评论，评论区基本分成两派：一派在算 Deno Deploy 的迁移账，另一派在讨论一个更大的问题——"收购 + 渐进式收尾"是不是一家开源公司能拿到的最好结局？

我的判断是：这是一次体面的退出，体面到值得写进教科书。有明确的时间表（一年 runtime 维护、六个月 Deploy 关停），有迁移支持（付费客户有人管），代码留在开源社区（欢迎接手），生态的关键部分（JSR）有人接盘。对比一下这个行业常见的结局——突然关停、慢慢烂掉、代码锁进私有仓库——Deno 这次的每一步都给了用户选择权。能把"认输"这件事做得这么有条理，本身就是一种能力。

但也别急着给 Deno 写墓志铭。Runtime 战争结束了，战争只是转移到了"编程模型"这一层：以后比的不是谁的 JS 跑得快，而是"写分布式应用"这件事本身能变得多简单。Dahl 赌的是后者，而 Cloudflare 愿意为这个赌注买单。

对 vibe coder 意味着什么

说了这么多，落到我们这些用 AI 写代码、把 prompt 当生产力的人身上，这件事有五层意思：

第一，理解 Durable Objects，比追下一个新 runtime 重要得多。未来一两年，agent 基础设施的事实标准大概率就长这个样子：便宜算力 + 持久状态 + 长连接 + JS 接口。你今天花一下午搞懂"每个 agent 会话是一个有状态的独立单元"这个心智模型，比跟进十个新 runtime 的 release note 值钱。Runtime 会死，编程模型会活。

第二，如果你在 Deno Deploy 上跑着东西，现在就开始规划迁移。六个月听起来很长，但一旦涉及 Deno 特有 API 重写和 Deno KV 数据搬迁，时间会过得比你想象得快。Workers 是官方指定的目的地；与此同时已经有第三方（比如 Appwrite）在抢这波迁移生意，多看两家不吃亏。

第三，如果你只是在本地用 Deno 写代码，不用恐慌。一年的维护期、每月安全更新，足够你从容决定去留。JSR 继续运营，你依赖的包不会一夜消失。真正要做的只有一件事：新项目别再深度绑定 Deno 特有 API。

第四，给 agent builder 的信号弹：Dahl 在找你。如果你正在大规模构建 agent 系统——不管是多 agent 编排、长时间运行的 agent，还是 agent 基础设施本身——Dahl 公开说了欢迎直接联系。这种级别的创始人亲自下场收反馈，窗口期不会太长。更重要的是，这确认了 Cloudflare 下一阶段的火力方向就是 agent workload：现在学 Durable Objects，就是在学未来两年 agent infra 的通用语言。

第五，也是最大的判断：vibe coding 时代，runtime 本身越来越不重要，重要的是编程模型。你写的代码长什么样、状态存在哪、怎么扩展、怎么从一台机器长到一千台——这些问题的答案，正在从"运维手册"变成"编程语言的一部分"。Dahl 用十七年时间从 Node 走到 Deno，又从 Deno 走到 Durable Objects，给 vibe coder 的启示只有一句：选边的时候选模型，不要选 runtime。

Durable Objects 的心智模型：一个 agent 会话 = 一个有持久状态的独立单元

尾声

十七年前，Dahl 用 Node.js 教会了全世界用 JS 写服务器；八年前，他用 Deno 试图修正 Node 的原罪；这一次，他干脆不做 runtime 了——他要去解决"分布式应用为什么这么难写"这个问题。从 10 月 9 日起，这个战场的名字叫 workerd + celld，而第一个检验标准，是它能不能成为 agent 时代默认的底座。

日期口径说明：deno.com 官方公告原文未能直接打开，本文事实经 RuntimeWire（2026 年 10 月 9 日发布，Primary source: Deno）与 Shashi Bellamkonda（2026 年 10 月 9 日）两家独立来源交叉核实；HN 热度数据（851 points / 467 comments）经 Hacker News 首页日报交叉确认。