Cloudflare与Deno宣布团队合并，计划将Deno的celld与Cloudflare的开源workerd整合，推动Workers与Durable Objects在Cloudflare网络与自托管环境中的可扩展运行。Deno产品线将逐步收缩并移交迁移支持，具体商业条款和自托管支持细节尚未公布。
Cloudflare与Deno在2026年10月9日分别宣布，Deno团队将加入Cloudflare。双方计划把Deno近期推出的开源项目 celld 与Cloudflare的开源Workers运行时 workerd 结合起来，推动一种既能运行在Cloudflare网络、也能部署在用户自有基础设施上的Workers编程模型。
这项安排没有公布交易金额。Deno官方使用的是“整个团队加入Cloudflare”的表述；TechCrunch在10月10日的报道中将其描述为Cloudflare收购Deno，并称Deno此前累计融资约2600万美元。因此，当前更准确的说法是：双方已确认团队与技术整合计划，但商业交易条款仍未披露。
从Deno运行时转向Workers平台
Deno由Node.js创始人Ryan Dahl等人参与创建，长期围绕JavaScript和TypeScript运行时、模块分发、安全权限以及独立可执行文件等方向发展。之后，Deno又推出了Deno Deploy，希望降低应用部署和运行的复杂度。
Deno在官方公告中说，Deno、Deno Deploy和celld代表了同一条技术路线的逐步推进：让计算、存储和通信能力更紧密地结合，并把分布式应用的扩展能力放进编程模型，而不是交给每个应用单独拼装基础设施。加入Cloudflare后，团队将把这套工作与Workers和Durable Objects结合起来，目标是让Workers编程模型成为一种更普遍的服务器开发方式。
Cloudflare的说法则更直接地指向自托管。该公司表示，Deno团队将帮助把Workers与Durable Objects的编程模型扩展到更多部署环境，并改善分布式应用自行托管时的复杂度。Cloudflare此前已经把workerd开源，并强调它与生产环境运行的Workers代码相同，而不是一个仅用于演示的平行实现。
celld试图补上workerd的关键缺口
Cloudflare承认，workerd虽然实现了Durable Objects，但目前的相关能力主要是单实例版本，适合本地测试，却不能满足可扩展的分布式自托管需求。Cloudflare在官方博客中说，生产环境中的Durable Objects路由依赖面向其全球网络设计的多项服务和运维系统，这种实现并不适合直接交给希望在自有服务器上运行的用户。
Deno在8月发布的celld，正是围绕这一缺口设计。Cloudflare称，celld提供了与Workers和Durable Objects兼容、同时面向自托管和扩展能力的实现。后续工作将把celld中的代码和设计思路整合回workerd，Ryan Dahl和Bert Belder将负责推动workerd自托管能力成为一条正式、受支持的运行路径。
这也意味着，Cloudflare试图处理一个长期存在的矛盾：Workers的独特编程模型能够简化全球分布式应用的开发，但越是依赖Durable Objects等特有抽象，应用迁移到其他环境就越需要额外工作。Cloudflare认为，开源和“逃生出口”并不必然削弱商业模式，反而可能降低企业采用平台的顾虑。
这一思路与Cloudflare近期围绕自托管Agent工作空间的动作相互呼应。AIFlux此前报道的Cloudflare开放托管版Cloudflare OS候选名单显示，Cloudflare正在同时探索开源自部署和由公司承担更多运维工作的托管路径。
Deno运行时和Deno Deploy将进入倒计时
团队整合也伴随着Deno产品线的收缩。Deno官方宣布，Deno运行时未来一年仍将获得每月一次的漏洞修复和安全更新；一年之后，Deno将停止由官方继续开发。不过，Deno仍会保持开源，项目社区或其他维护者可以继续推进其发展。
Deno Deploy则将继续运行六个月，之后关闭。Deno表示，会为付费客户迁移到Cloudflare Workers提供支持。JSR包注册与分发服务将继续运营，但其基础设施会迁移到Cloudflare；Rust实现的V8绑定rusty_v8也会继续获得支持，并计划逐步整合进workerd。
这些时间表需要与“立即关闭”区分开来。官方公告确认的是未来安排，而不是Deno运行时或Deno Deploy在10月9日当天已经停止服务。对于依赖Deno Deploy的团队，六个月的期限意味着迁移评估、兼容性测试和数据迁移需要尽早开始；对于依赖Deno运行时的开发者，一年的维护期则更像是一个重新评估运行时选择的窗口。
Durable Objects为何与Agent运行时相连
Cloudflare和Deno都把Agent列为这次技术整合的重要应用方向。Deno称，Durable Objects具备持久状态、WebSocket连接、无服务器执行和较高层次的JavaScript接口，这些能力适合需要持续运行的Agent或Agent编排系统。
这类应用与一次性请求响应服务不同。一个Agent可能需要保存任务状态，等待外部事件，持续与用户或其他服务通信，并在执行中断后恢复现场。若每个团队都要自行处理状态存储、实时连接、任务调度和故障恢复，开发和运维成本会迅速上升。把这些能力放进运行时和编程模型，正是Cloudflare希望扩大Workers适用范围的原因。
不过，Durable Objects适合Agent运行时是平台方的设计判断，并不等于Agent已经实现普遍商业化。真实部署仍然要面对权限控制、凭据隔离、数据驻留、任务回滚、成本管理和故障审计等问题。尤其当Agent可以长期保存状态并代表用户操作外部系统时，运行时的便利性必须与可观察性和人工审批机制同时建设。
类似的运行时转向也出现在其他开发者工具中。AIFlux此前对Qwen Code从终端工具走向托管运行时与持久化Agent工作流的报道也指出，长任务Agent的竞争重点正在从模型输出扩展到会话持久化、任务取消、故障转移和运行时生命周期管理。
开源承诺能否转化为可用平台
Cloudflare此次宣布的核心并不是把Deno品牌并入Workers，而是试图把两套开源技术路线合并成一个更完整的运行时平台。对开发者而言，最值得关注的结果将包括：workerd能否在不同基础设施上稳定运行，Durable Objects能否获得真正可扩展的自托管实现，以及Cloudflare能否提供足够清晰的部署、升级和运维文档。
Deno团队的加入可能加快这些工作的推进，但目前仍没有公布统一的商业支持方案、正式发布时间表或自托管版本的服务等级承诺。Cloudflare也没有说明，未来哪些能力会在开源workerd中提供，哪些能力仍然依赖Cloudflare的托管网络。
对Deno用户来说，短期内最明确的变化是产品维护期限和迁移路线；对Cloudflare用户来说，潜在收益是Workers编程模型可能更容易进入私有云、边缘节点或企业自有服务器。最终，这项整合能否改变开发者对平台锁定的担忧，取决于Cloudflare是否真的把兼容性、可移植性和可运维性落实为长期支持的工程产品，而不只是一次团队和项目的宣布。
来源：