Deno Goes the Way of the Dinosaur

Cloudflare is acquiring Deno’s team, but the deal comes with an unwelcome surprise for developers who built on its JavaScript and TypeScript runtime: the company is winding down development, leaving the community to work out how to keep it going.

Ryan Dahl, creator of both Node.js and Deno, announced on October 9 that the entire team is joining Cloudflare. Deno will receive another year of monthly bug fixes and security updates before the team ends its development work. Deno Deploy will shut down in six months, with migration assistance for paying customers moving to Cloudflare Workers.

The runtime won fans by taking much of the setup out of TypeScript development, with formatting, linting, and testing built in. Its security model also let developers decide what their code could access, restricting files, networks, and environment variables by default.

The news has prompted developers to question the decision, revisit the risks of building on venture-backed open source, and start organizing forks. Some would prefer to keep Deno intact under independent stewardship. Others are ready to take the code in a different direction.

The acquisition arrives less than a year and a half after Dahl published “Reports of Deno’s Demise Have Been Greatly Exaggerated,” addressing concerns about the company’s direction and momentum. At the time, he reported that adoption had more than doubled since Deno 2 and assured users: “We’re not winding down. We’re winding up.”

For some developers who trusted those assurances, being invited to maintain the runtime themselves while the company moves on is a bitter pill to swallow. “I invested a lot and use deno everywhere. Can't trust anything these days,” one Hacker news commenter wrote, before proposing a community fork.

Another commenter said they felt “very misled” by the acquisition messaging promoting “Deno + Cloudflare” while revealing at the bottom of the post that development of the runtime would end.

Others questioned what businesses should expect from software they use for free, with some participants pushing back on the complaints:

This is just normal open source. The software is provided AS IS, WITHOUT ANY WARRANTY.
As a community we've gotten so used to getting things for free and then getting mad when they go away. That's a fine attitude if it's your hobby dependency, but if you're making $100k off that dependency what did you actually expect?

Cloudflare is expanding self-hosting for Workers and Durable Objects#

The project that brought the companies together is celld, an open source implementation of the Workers and Durable Objects programming model designed to run on developers’ own infrastructure.

Celld combines JavaScript execution and persistent state in individually addressable objects, each backed by SQLite. Those objects can be distributed across machines, with shared object storage holding their durable data. The aim is to make building and operating a distributed application require far less infrastructure assembly.

On October 1, eight days before the acquisition announcement, Dahl argued that celld would largely displace traditional JavaScript runtimes for serving applications:

once you see it, you'll realize there's no point to traditional javascript runtimes in serving applications - only for build processes (eg bundling) and scripting.

In the joint Cloudflare announcement, Dahl described how operating Deno Deploy had exposed him to the complexity underneath an apparently simple hosting service: multiple clouds, databases, and interconnected services. Celld grew out of his desire to simplify that machinery.

Cloudflare had a gap that celld could fill. Its open source Workers runtime, workerd, supported Durable Objects on a single instance, but lacked the distributed implementation needed for scalable self-hosting. Cloudflare’s production implementation depended on infrastructure that self-hosters would not have.

Kenton Varda acknowledged that releasing workerd and hoping the community would build the surrounding ecosystem had not been enough. “Perhaps we were naive,” he wrote.

When Deno released celld in August, Cloudflare saw a team working on something it had wanted to build. Dahl and Deno co-founder Bert Belder will now lead an effort to merge celld’s code and ideas into workerd and make self-hosting a supported way to run Workers applications.

Other pieces of Deno’s work will continue. JSR will remain operational, with its infrastructure moving to Cloudflare. The team will keep supporting rusty_v8 and work toward integrating it into workerd. Its attention, however, is moving away from maintaining a separate general-purpose runtime and hosting service.

Developers are forking Deno to keep it alive#

Over on Hacker News, someone asked the burning question: was abandoning the runtime Cloudflare’s idea or Deno’s?

In his response, Dahl indicated that he had come to see Deno as a lot of engineering in service of too small a problem.

"It's a joint decision and I agree with it," he said. "I'm most invested in its success and have put the most work into it - and I no longer think it's where I can do the most important work."

After years of making the case for a better JavaScript runtime, Dahl was no longer convinced its advantages justified the work:

There are some good ideas in Deno and it's well engineered - but it ultimately is not solving big problems. It has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough.

He was considerably more enthusiastic about celld:

I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development.

For those still interested in the runtime he was leaving behind, the invitation was brief:

We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.

Developer Paul Webb, who uses Deno for his APIs and personal projects, was less sympathetic to Dahl’s change of interests:

My brother in Christ. YOU reimplemented Node and now you’re bored? I get it was done for adoption purposes but like, that’s a solvable problem? Whatever, this ain’t my first rodeo.

The compatibility argument is particularly striking given how Deno had previously described its progress. In the May 2025 post defending the project, Dahl credited Node compatibility with removing a major adoption barrier and opening Deno to more serious use cases. The feature that helped bring developers aboard had become part of the explanation for why its creator wanted to move on.

Webb’s response is to remove it. His announced fork, Ende, would drop Node compatibility and cut features he considers distractions, including Deploy, KV, and Jupyter integration. The proposed roadmap includes per-module permissions, sandboxes for untrusted code, post-quantum cryptography in Web Crypto, and improvements to compiled binaries.

Webb is also building a business on Deno, so he has a stake in keeping the runtime alive.

Another community fork, Dodo, is starting with the difficulty of contributing to the existing codebase. Its maintainers point to core components spread across separate repositories, requiring changes to be merged and released in several places before the runtime can use them. Their first goal is to bring those components together so a change can be made and reviewed in a single pull request.

Dodo is still at an early stage. Its README says there are no Dodo releases yet, and its installation commands still install upstream Deno. Running the fork currently requires building it from source.

These efforts already suggest different ideas about what Deno should become: a more focused runtime freed from Node compatibility, or a project reorganized to make outside maintenance easier.

Developers want a handoff they can build on#

There is also interest in preserving Deno itself, without requiring its users and contributors to choose among successors.

A joke GitHub issue lamenting Deno’s fate drew serious responses from developers who had built their projects around the runtime. One commenter, marvinpeter95, said their web application depended on Deno and Fresh, and that persuading their employer to adopt Deno had taken considerable convincing.

Another commenter, rapidbott-cloud, said their team had planned to launch an AI chatbot and automation platform that month:

Our entire backend is built on the Deno runtime and infrastructure, and this sudden announcement has put us in a very difficult position. We've now had to postpone our product launch and start planning a migration away from Deno.

An October 15 update clarified that the team will publish monthly Deno 2.9.x LTS releases through October 2027, triage security reports, and review bug fixes. New feature work is stopping. Feature pull requests will be closed without merging, and features added to canary builds after the 2.9 branch was cut will be reverted.

The update also said the team was considering ways to organize development beyond October 2027.

Contributors proposed a dedicated foundation or an existing organization such as the OpenJS Foundation. One organizer reported that a community server had attracted more than 100 active members in 48 hours. Although the group was coordinating a fork, the organizer said, “we would much prefer Deno itself be officially passed on to a reputable steward organization.”

Developer Brett Chalupa argued that the company should help organize the transition, proposing public discussions toward a Deno Foundation with open governance.

Ryan Dahl didn't need to have the answers, but I sure do wish there was more of an openness to the future of the Deno project than "If people want to carry it forward, I'd like that."

Deno’s company was originally created to supply exactly that continuity. When Dahl and Belder announced its $4.9 million seed funding in 2021, they described a staff of full-time engineers who would address issues, fix bugs, and ship timely releases. They promised to “ensure Deno is a platform others can build on with trust.” A $21 million Series A followed in 2022.

The result was a runtime with users invested enough to contemplate maintaining it themselves. That is an achievement for an open source project, even if it did not produce a business the company wanted to keep operating.

AI is rewriting the future of JavaScript runtimes#

Deno’s acquisition also invites an obvious comparison with Bun, the other prominent Node.js alternative that found a buyer.

When Anthropic acquired Bun in December 2025, creator Jarred Sumner said the project had no revenue. The expected business model had been to build a cloud hosting product around its runtime and bundler. AI coding tools offered another route.

Bun’s standalone executables had made it useful for distributing command-line tools, including Claude Code. Anthropic acquired a runtime its own product depended on, and the announcement committed to continued public development, the same team, and continued work on Node.js compatibility.

Chalupa described that outcome with considerably less corporate polish in The Disappointing Death of Deno:

Bun succeeded in the mission of making rich people richer by building an open source JavaScript runtime. One investment dollar likely turned into many more.

Deno also had technology relevant to a world where agents generate and execute code. But the availability of a new market does not guarantee that an existing company can build a sufficiently large business around it.

“Despite Deno being primed for this major shift in how software is developed, the stars didn’t align,” Chalupa wrote.

He pointed to the time required to create a commercial product capable of sustaining the company and wondered whether its newer projects had also helped attract a buyer:

Building a commercially successful software product that can grow in revenue at the order needed by the Deno company takes at least six months, if not years, even with LLMs generating the code. Building wildly financially successful software products is hard. Acquisition seemed the only option, and maybe these efforts were bait on the fishing line to find a suitable buyer? Building and releasing open source tools and libraries doesn’t seem like an obvious path to making money or an acquisition. But Silicon Valley is a strange place...

His comparison captures some of the indignation surrounding Deno’s exit: years of investment and open source development ending in an acquihire, “while the upstart competition that’s arguably not any better gets bought by one of the largest AI companies.”

AI is also changing the work inside these projects. In Bun’s acquisition announcement, Sumner said a Claude Code bot had become the GitHub account with the most merged pull requests in the repository over the preceding several months. It was helping fix bugs, supplying tests, and responding to review comments. The runtime was supporting AI coding tools while those tools increasingly helped develop the runtime.

For Dahl, the opportunity now lies in the infrastructure that agents need. He made that motivation explicit in Deno’s announcement:

The need for better abstractions is especially acute with AI. Durable Objects bring together capabilities that are particularly useful for agent harnesses: inexpensive, serverless execution, persistent state, WebSockets, and a high-level JavaScript interface. This is what I’m most excited to explore and why celld focuses on Durable Objects.

AI’s headlong advance is reaching into the foundations of software development. All that generated code still needs somewhere to run. Agents need persistent state, coordination, and inexpensive execution at scale. These demands are drawing runtime teams into problems far beyond making JavaScript faster or TypeScript easier to use. AI tools are actively building the machinery they depend on, accelerating the work while changing its direction.

Bun has found a place in that machinery. Dahl wants to redesign more of it. The competition that once revolved around improving on Node.js is being pulled into the much larger race to build and operate software through agents. In the rush to build for AI, even a cutting-edge JavaScript runtime can be left behind by the people who spent years persuading developers to trust it.