Evidence at a glance
The Team Is Joining Cloudflare, but the Runtime Is Not the Focus
On October 9, 2026, Deno announced that its team was joining Cloudflare. The companies plan to combine celld, developed by the Deno team, with Cloudflare's workerd so the Workers programming model can run on infrastructure outside Cloudflare. The announcements describe a team joining and a technical plan, but disclose neither the transaction's value nor its precise structure. This should not be read as a promise that Cloudflare will continue every Deno product.
The change matters to technical leaders not because it adds another JavaScript runtime camp, but because both companies are focusing on the deployment boundary. Cloudflare wants Workers to be more than a hosted service: it wants the programming model to be self-hostable. There is a clear cost to that shift. Deno Runtime will receive monthly releases with fixes and security updates for one more year, after which the Deno team will stop developing it. Deno Deploy is scheduled to operate for six more months, with migration help for paying customers moving to Workers.
Self-Hosting Must Make Durable Objects Work Across Machines
Cloudflare had already open-sourced workerd, but its announcement said Durable Objects support was limited to a single instance and could not, by itself, provide a scalable multi-machine deployment. Production distributed routing depended on infrastructure in Cloudflare's own network. So bringing Workers to machines a customer controls is not just a matter of downloading a runtime binary. It also requires answers to where object state lives, which machine owns each object, and how another machine takes over after a failure.
Durable Objects shift the unit of coordination from an entire server to an identified object. Each object has its own persistent SQLite database; JavaScript runs single-threaded within it, and the object can also handle WebSockets. A chat application, for example, can create one object per channel, distributing channel data and connections across objects. The appeal is that application logic can be organized around stateful objects instead of requiring developers to assemble a general-purpose server cluster and bolt on state and connection management themselves.
celld Uses Object Storage to Coordinate a Fleet
celld is the Deno team's implementation for self-hosting Workers and Durable Objects; Cloudflare says its first version was released in August. A fleet consists of multiple celld nodes sharing an object-storage bucket. The bucket stores deployments, object state, and ownership records. Only one node owns a given cell at a time, and nodes compete for ownership using conditional writes to object storage rather than relying on a separate cluster-membership protocol or consensus service.
The write-acknowledgment path changes with the deployment shape. In single-node mode, a write is acknowledged only after its data reaches object storage. In multi-node mode, the SQLite write log can first be replicated to other nodes' disks; once the durability condition is met, the write can be acknowledged and uploaded to object storage asynchronously. This design delegates some coordination to existing object storage, but does not eliminate persistence concerns. A single node must absorb the wait for object storage; a multi-node deployment must reason about disk replicas, node failures, and recovery before the upload completes. The public documentation gives no latency or throughput figures that apply across deployments.
A Planned Integration Is Not a Finished Deployment Option
Cloudflare says Ryan Dahl and Bert Belder will lead the work on self-hosted workerd, folding celld's code and design ideas into it. The announcement describes this as work for the coming months. The integration is not complete, and no finished, formally supported deployment path has been specified for teams to adopt today. Existing Workers users can infer the direction, but not yet the migration tooling, operational commitments, or production failure-recovery details.
That distinction matters: an open-source runtime provides an exit from a hosted runtime, but it is not automatically a complete platform exit. Teams will still need to check whether conditional writes to object storage meet their durability requirements and evaluate write latency, ownership handoff, and state recovery. The word self-hosting does not settle those questions. Cloudflare's response to concerns about Workers lock-in is that open-source workerd offers a migration path, but the announcement does not establish that migration has become easy.
Why Deno Is Winding Down and the Team Is Moving to a New Abstraction
Ryan Dahl's comment on Hacker News gives a more direct explanation for the trade-off than the corporate announcements. He said Deno had good ideas and was well engineered, but had been pulled into Node compatibility until it was forced to behave like Node. If the goal is to reimplement Node, he argued, incremental gains in performance, user experience, or security are not enough to justify the effort. He wants to work on new server abstractions, and sees celld's use of object storage for coordination and persistence as a different development model, not a minor variation on file-system or network APIs.
Deno's permission system was one of its runtime-level distinctions: a script could be restricted to particular files and directories and to specific network hosts. Node.js later added a permissions model, introduced in Node 20.0.0 in April 2023 and marked stable in Node 22.13.0 in January 2025. Node still cannot allow-list individual network hosts. The comparison shows that Deno retains concrete design differences, while also helping explain why runtime-level distinctions alone may not sustain an independent product direction.
What Technical Leaders Can Decide Now
For teams already using Workers, the sensible move is not to make self-hosting an architectural commitment immediately. Treat it as a deployment option to validate once the workerd and celld integration advances, testing whether state persistence, write acknowledgment, and failure handoff meet the workload's requirements. Pay particular attention to the single-node and multi-node paths, since they rely on different durability conditions for acknowledging writes. And if an application depends on Cloudflare's network or other hosted capabilities, a self-hosted runtime alone does not guarantee those dependencies will be available elsewhere.
Teams relying on Deno Runtime should treat the one-year maintenance promise as a migration window, not a long-term support guarantee. The project remaining open source does not ensure that stable official maintainers will continue afterward. Paying Deno Deploy customers should likewise plan around the announced six-month operating period and migration support. The broader bet is a shift from maintaining a general-purpose runtime to building a portable platform for stateful applications. Real portability will have to be demonstrated through mature deployment, recovery, and maintenance commitments; neither open source nor a planned integration can guarantee it on its own.