We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
Deno Deploy will continue operating for six months before shutting down. We will provide migration support for paying customers moving to Cloudflare Workers.
On the Cloudflare side they explain a bit more in Cloudflares motives for buying Deno/sunsetting the runtime.
Basically, they want to merge celld, an open source runtime for Durable Objects (basically, Cloudflare Workers with State), with the existing Cloudflare Workers runtime, workerd.
What's kinda curious to me is that the celld runtime is only around 2 months old; Cloudflare says they're not buying out their competition, pointing to workerd being open source (and apparently being deployable by unnamed former clients), but it's pretty weird to both immediately buy out Deno for a newly launched product and to specifically cite that they're doing it for the one product tied to Cloudflare itself. It feels like there's a backroom conversation that's missing here, one we probably won't ever be privy to.
wrt the Deno runtime itself, I wonder what this will mean for the yt-dlp project. A while ago they had to drop their own mini-JavaScript engine due to it becoming increasingly fragile and unmaintainable in the face of constant changes by Google, and just told people to install Deno as the "blessed" JavaScript engine. They'll probably have to start looking for a new recommended engine that meets those demands, which on their wiki probably will mean either node or QuickJS (as apparently Bun got deprecated due to excessive LLM usage - which got specifically highlighted over Deno, which also uses LLMs, but apparently to a lesser degree.)
yt-dlp can use deno, node, quickjs and bun so it's not stuck. I'm investigating as I had no idea why deno is preferred; I found in the manpage that "node and bun are still considered insecure", apparently because the scripts that yt-dlp fetches and executes are not run in a sandbox. It looks like quickjs could be very very slow until somewhat recently. The yt-dlp doesn't mention issues with sandboxing for quickjs but the quickjs documentation doesn't contain the word "sandbox" so I'm not completely sure what the status is (either it's fully on, or fully off).
I wrote about Deno's decline a few months ago: I wish Deno would keep doing what it does best. I shared its vision, but I think it never got far because a startup was the one carrying it out. This decision makes me more sure of that.
It also settles something for me. From now on I won't trust a development platform built by a startup, however good the vision. Too risky, too easy to get betrayed.
What I'd rather see is people with strong ideas about development platforms letting go of the impatience and building them as community-driven F/OSS projects instead. Funding is the obstacle, of course. I hope good F/OSS funds like NLnet and the Sovereign Tech Fund keep expanding.
In general I agree with you, but I think sometimes it has also a good outcome, you just have to be ready for some turbulence in the future. Let them burn VC money and if the thing is a net positive there will be a healthy fork maybe with some foundation setup. But yes, the priority should go to something less flammable.
Curious why, I have personally been impressed by their growth technically, in terms of product and also just the business. They also have good people like a Kenton Varda and now the Demo team.
You're curious why someone would be upset that a megacorporation bought out another company and immediately announces they're abandoning the open source project said company runs?
I think that if they agreed to be bought then the writing was on the wall already. If not Cloudflare there would be someone else or they would just dismantle. They probably wanted an exit. It doesn't make it any less sad or make Cloudflare any better.
I think the point of concern is not that they were bought out, but that the buyers chose to shut down the project, rather than saying "Hey you know that project that a bunch of people are using. How about you spend some of your workday on that still. Cool? cool."
I am really disappointing to see this change. I have used deno for practically as long as I've been using node. It started out with some really great ideas and features
I've used deno for everything from small scripts to school projects to hobby projects that have run for years.
I'd be lying if I said the VC-colored writing wasn't on the walls a long time ago, yet I still had hope :(
A shame, really.
I like the idea of Deno. It was supposed to be faster, more secure by default, easier to maintain with good defaults, web API compatibility, the works.
I think the main issue is that it failed to deliver useful value over node. At first it was doing its own thing with deno.json, URL imports, import maps.
It quickly became apparent that people are mostly unwilling to change their ways from the node way of doing things.
So, Deno started pushing node compatibility. It left it kind of in an awkward spot: Not as node compatible as node is (duh), but also not that much on top that would make people want to use it over node.
I think the most important thing that Deno did was force Node to get better: TypeScript support, built in SQLite, a permission system.
I doubt those things would get merged into Node if Deno and Bun hadn't been around.
I will always I will always respect Ryan Dahl. I wish him the best in his future endeavors.
I’m one of many people I know that was cheering on the Deno runtime development even though I didn’t quite need it… yet.
In my case, I needed to render graphics in both the browser and on a server, often in 3D. I’ve had two roles now where doing this with WebGPU has felt like it’s just on the horizon. Server-side rendering of WebGL is no picnic. It’s a pity that Deno’s death is going to more-or-leas coincide with the completion of WebGPU implementation across mainstream browsers.
ema-pe | 8 hours ago
To highlight:
Two9A | 8 hours ago
So when we say "is joining", we mean "has been chewed up and spat out by"?
andyc | 8 hours ago
Well I would just say "acquihire". Cloudflare appparently doesn't want the products, but they want the people.
mort | 7 hours ago
"Deno is being discontinued and its development team will be acquired by Cloudflare" seems like the actual honest headline
calvin | 3 hours ago
An incredible journey for Deno, indeed.
noirscape | 8 hours ago
On the Cloudflare side they explain a bit more in Cloudflares motives for buying Deno/sunsetting the runtime.
Basically, they want to merge celld, an open source runtime for Durable Objects (basically, Cloudflare Workers with State), with the existing Cloudflare Workers runtime, workerd.
What's kinda curious to me is that the celld runtime is only around 2 months old; Cloudflare says they're not buying out their competition, pointing to workerd being open source (and apparently being deployable by unnamed former clients), but it's pretty weird to both immediately buy out Deno for a newly launched product and to specifically cite that they're doing it for the one product tied to Cloudflare itself. It feels like there's a backroom conversation that's missing here, one we probably won't ever be privy to.
wrt the Deno runtime itself, I wonder what this will mean for the yt-dlp project. A while ago they had to drop their own mini-JavaScript engine due to it becoming increasingly fragile and unmaintainable in the face of constant changes by Google, and just told people to install Deno as the "blessed" JavaScript engine. They'll probably have to start looking for a new recommended engine that meets those demands, which on their wiki probably will mean either node or QuickJS (as apparently Bun got deprecated due to excessive LLM usage - which got specifically highlighted over Deno, which also uses LLMs, but apparently to a lesser degree.)
adrien | 7 hours ago
yt-dlp can use deno, node, quickjs and bun so it's not stuck. I'm investigating as I had no idea why deno is preferred; I found in the manpage that "node and bun are still considered insecure", apparently because the scripts that yt-dlp fetches and executes are not run in a sandbox. It looks like quickjs could be very very slow until somewhat recently. The yt-dlp doesn't mention issues with sandboxing for quickjs but the quickjs documentation doesn't contain the word "sandbox" so I'm not completely sure what the status is (either it's fully on, or fully off).
simonw | 5 hours ago
Node.js grew a Deno-style permission model in version 22.13 in January 2025: https://nodejs.org/en/blog/release/v22.13.0
hongminhee | 6 hours ago
I wrote about Deno's decline a few months ago: I wish Deno would keep doing what it does best. I shared its vision, but I think it never got far because a startup was the one carrying it out. This decision makes me more sure of that.
It also settles something for me. From now on I won't trust a development platform built by a startup, however good the vision. Too risky, too easy to get betrayed.
What I'd rather see is people with strong ideas about development platforms letting go of the impatience and building them as community-driven F/OSS projects instead. Funding is the obstacle, of course. I hope good F/OSS funds like NLnet and the Sovereign Tech Fund keep expanding.
hawski | 6 hours ago
In general I agree with you, but I think sometimes it has also a good outcome, you just have to be ready for some turbulence in the future. Let them burn VC money and if the thing is a net positive there will be a healthy fork maybe with some foundation setup. But yes, the priority should go to something less flammable.
greg_loscombe | 4 hours ago
Really dislike Cloudflare these days.
sebastien | 3 hours ago
Curious why, I have personally been impressed by their growth technically, in terms of product and also just the business. They also have good people like a Kenton Varda and now the Demo team.
stephenr | 3 hours ago
You're curious why someone would be upset that a megacorporation bought out another company and immediately announces they're abandoning the open source project said company runs?
hawski | 2 hours ago
I think that if they agreed to be bought then the writing was on the wall already. If not Cloudflare there would be someone else or they would just dismantle. They probably wanted an exit. It doesn't make it any less sad or make Cloudflare any better.
stephenr | 2 hours ago
I think the point of concern is not that they were bought out, but that the buyers chose to shut down the project, rather than saying "Hey you know that project that a bunch of people are using. How about you spend some of your workday on that still. Cool? cool."
andrewrk | 5 hours ago
Did anyone not see this coming since the very beginning?
luca | 5 hours ago
I am really disappointing to see this change. I have used deno for practically as long as I've been using node. It started out with some really great ideas and features I've used deno for everything from small scripts to school projects to hobby projects that have run for years. I'd be lying if I said the VC-colored writing wasn't on the walls a long time ago, yet I still had hope :(
kraxen72 | 6 hours ago
A shame, really. I like the idea of Deno. It was supposed to be faster, more secure by default, easier to maintain with good defaults, web API compatibility, the works. I think the main issue is that it failed to deliver useful value over node. At first it was doing its own thing with deno.json, URL imports, import maps.
It quickly became apparent that people are mostly unwilling to change their ways from the node way of doing things. So, Deno started pushing node compatibility. It left it kind of in an awkward spot: Not as node compatible as node is (duh), but also not that much on top that would make people want to use it over node.
I think the most important thing that Deno did was force Node to get better: TypeScript support, built in SQLite, a permission system. I doubt those things would get merged into Node if Deno and Bun hadn't been around.
I will always I will always respect Ryan Dahl. I wish him the best in his future endeavors.
0x2ba22e11 | 3 hours ago
I haven't used Deno for anything much but I'm very grateful that the competition spurred some advances in node
brn | 4 hours ago
I'm saddened by this, and will now need to plan for some migration work in a couple of production projects. Sigh.
adamshaylor | 2 hours ago
I’m one of many people I know that was cheering on the Deno runtime development even though I didn’t quite need it… yet.
In my case, I needed to render graphics in both the browser and on a server, often in 3D. I’ve had two roles now where doing this with WebGPU has felt like it’s just on the horizon. Server-side rendering of WebGL is no picnic. It’s a pity that Deno’s death is going to more-or-leas coincide with the completion of WebGPU implementation across mainstream browsers.
andersmurphy | 7 hours ago
The conjunction of the spheres continues.