On 9 October 2026, Cloudflare announced that the entire team behind Deno, the JavaScript and TypeScript runtime, is joining the company. The terms were not disclosed. The sentence that matters to anyone running Deno is in the details: the standalone runtime and the Deno Deploy hosting service stop being developed, the runtime gets monthly maintenance and security updates for one more year, and Deno Deploy shuts down in six months, with migration help for paying customers, according to The New Stack. That makes this less a talent acquisition than a consolidation of a runtime into someone else's platform, and it hands Deno users two dated deadlines.
The timeline in one place
The New Stack, which reported the acquisition from Cloudflare's announcement and from Deno co-founder Ryan Dahl's own explanation, gives the sequence. The Deno runtime continues to receive monthly maintenance and security updates for about twelve months from the announcement, which is to say until roughly October 2027. Deno Deploy, the managed hosting service, shuts down about six months from the announcement, which is to say around April 2027. The JSR package registry continues under Cloudflare. The runtime stays MIT licensed. Dahl said how it lives on after official support ends is up to the community.
The mismatch between those two deadlines is the practical point. A team that uses Deno only as a local runtime and a test runner has a year. A team whose production traffic runs on Deno Deploy has half that, and The New Stack says migration assistance is for paying customers, so free-tier projects should assume they are on their own. Cloudflare's post announces no migration tooling, and neither source describes a specific path off Deno Deploy beyond that assistance. The New Stack reports that Deno had raised about $26 million across two rounds, which puts the scale of the company in context: a small team with a widely used runtime, absorbed at an undisclosed price.
Why Dahl says the standalone runtime stopped making sense
Dahl's stated reasoning, as paraphrased by The New Stack, is unusually direct. Deno's growing Node.js compatibility, a feature added so existing code would run, meant the project was effectively maintaining a second implementation of the same technology as Node. He also argues Deno's influence persists through ideas Node has since adopted: native TypeScript support, a permissions model and web-standard APIs. In other words, the success of Deno's ideas reduced the reason to run Deno.
There is a counter-reading: that an acquirer's reasoning is not the same as the users' reasoning, and that Deno's defaults, such as requiring explicit grants before code touches files or the network, were a reason some teams chose it over Node regardless of compatibility. Dahl's answer is the community. He cites io.js, a community-led fork of Node.js that eventually merged back into the main project, as the precedent for how a project can carry on without its founders. The precedent is encouraging but not a guarantee. A Deno fork would start with no commercial owner and no hosted business to fund it, and the full-time maintainers have just moved to Cloudflare. Neither source reports any group having committed to maintain one.
What Cloudflare is buying
Cloudflare's own blog post, written by Dahl and Cloudflare principal engineer Kenton Varda, explains the strategic logic. Workerd is Cloudflare's open-source Workers runtime, described in the post as the same code Cloudflare runs in production. Its Durable Objects support runs only as a single instance. Durable Objects are the distributed-singleton primitive: each one has its own SQLite database, runs JavaScript on a single thread and handles WebSockets, and the post's example is one object per chat channel, which shards data and connections. A single-instance workerd works for local testing but cannot scale out. The post says that gap has carried TODO comments since the original release.
Deno had built a way around it. Celld, which the Deno team released in August 2026, is an open-source Rust binary that recreates the Workers and Durable Objects model for self-hosted infrastructure, with object storage as its only external dependency: operators run many celld instances and one storage bucket. Dahl and Deno co-founder Bert Belder will lead the work of merging celld into workerd so that self-hosting becomes a first-class option. The New Stack reports the combined project is expected to stay open source, likely under the Apache 2.0 licence celld already uses; Cloudflare's post does not name a licence for either.
Varda's stated motive, per The New Stack, is commercial. An exclusive model would limit Cloudflare's market against the legacy clouds, and customers such as Shopify had asked for an open-source runtime since Workers for Platforms was pitched in 2022. Cloudflare says it had wanted to build this for a long time but lacked the talent to deliver it. Dahl adds that Durable Objects suit the harnesses that run AI agents, because they offer cheap serverless execution, persistent state and WebSockets in one primitive.
How this differs from Bun's path
The obvious comparison is Anthropic's purchase of Bun in December 2025. The New Stack notes that Anthropic committed to continuing Bun's development as an open-source runtime, whereas Deno's runtime development ends under Cloudflare. The distinction is the central one for users: Bun's runtime is a product its new owner keeps building, while Deno's runtime becomes a maintenance project and its team's work moves to workerd. The New Stack also discloses that its owner, Insight Partners, invests in both Deno and Anthropic, which is worth knowing when reading its framing.
Quantitatively, the comparison is lopsided: twelve months of maintenance for the runtime, six months for the hosted service, and an open-ended community option. For Bun users, no comparable end date has been announced.
Why the object-storage design matters is a mechanism worth spelling out. Cloudflare's post says its production routing for Durable Objects is too heavy for self-hosters, and that an earlier internal attempt at a self-hosting approach did not work. Celld sidesteps routing by leaning on a shared object-storage bucket for coordination and storage, which is why Dahl says a fleet of workerd instances would need only an industry-standard bucket and would present an API matching Cloudflare's platform. The plausible trade-off, which is our inference and which neither source quantifies, is that coordinating through a shared bucket gives up some of the speed of purpose-built routing, so the self-hosted version may not match the managed one on latency. That is a question for the benchmarks that have not yet been published.
What a team on Deno should decide now
Decisions depend on how Deno is used, and the sources support a short decision tree. If you run production workloads on Deno Deploy, the six-month shutdown is your deadline, and the realistic targets are Cloudflare Workers, which the Deno engineers are now building, or another host that runs standard JavaScript. If you use the Deno runtime for tooling, scripts or self-hosted services, nothing breaks tomorrow, but the maintenance window is finite, and given the Node compatibility Dahl himself points to, code that sticks to Node-compatible APIs should be the cheapest to move to Node or Bun, though the effort will vary with how much of Deno's own API surface a project uses. That is our inference, not something either source claims. If you rely on JSR, nothing changes yet, since Cloudflare says the registry continues.
Longer term, three questions are worth watching, none of which the sources answer. Will an organisation fund a community fork of Deno, and who? How much of celld's design survives the merge into workerd, and will self-hosted Durable Objects reach parity with the managed product? And what licence ends up on the merged runtime? Cloudflare's post says more details will follow in the coming months. Until then, treat the two dates, April and October 2027 by our reading of the announcement, as hard constraints and everything after that as unannounced.
