Cloudflare acquires Deno
deno.com
deno.com
So unless someone else picks up development, Deno will no longer be supported.
I wouldn't be surprised if Bun is abandoned at some point as well.
(Which is why I am happy to see new runtimes but never care enough to seriously use or adopt them.)
Then I read that paragraph, and it made more sense that they're acquihiring + killing.
Companies went all-in in a barely established niche player with 1/100 the traction, instead of sticking with Node, and even better an LTS Node, and are now surprised?
Do they also do their front-end in Dart?
They should hire a few devs to develop it then.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
See https://github.com/yt-dlp/yt-dlp/issues/14404, https://github.com/yt-dlp/yt-dlp/issues/15012, and https://github.com/yt-dlp/yt-dlp/wiki/EJS.
Language really means nothing these days…
(Yeah I’m salty, I got all in on Deno a year ago.)
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?
The writing had been on the wall though, ever since Bun's rapid success with their alternate strategy. Deno quickly started removing its opinionated stances and playing catch-up on Node compatibility.
I loved their original vision, and I'm glad they tried. They had some really cool ideas for a better world of JavaScript, and I do think they placed some pressure on Node and made it better in the process. I'm also glad they're getting a buyout for their hard effort, even though it's probably more about hiring a team of skilled JS runtime engineers than about acquiring the technology.
RIP Deno
Somehow I don't believe that Cloudflare doubling down on their own runtime -workerd, which will be likely migrated to Rust soon [1]- is the right choice (since it push on semantics that can only be run on Cloudflare infrastructure). I strongly believe Node.js semantics are likely the right ones for agents.
If anyone is looking for a full-open source alternative to Node.js that can run everywhere (browsers, phones or servers), please be aware that you can rely and use Edge.js [2] (disclaimer: Edge.js is part of the company that I founded: Wasmer)
"By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure."
It does not appear they are close sourcing it. He mentions workerd is open source. Roadmap needs better communication but it appears people will be able to switch to new merged OSS version. It's just not well defined what it looks like yet.
I don't really know anything about that area, but didn't Facebook get in some trouble for purchasing Instagram in part due to them being competition.
Surely buying a company out only to close their main offering is defined as anti-competitive?
From what is likely going to happen is that Deno will be donated to the Linux Foundation to avoid this.
I hope workerd at least adopts Deno's security mechanisms so it functions as a better sandbox.
One of my favourite projects of 2026 was a configurable LLM harness built around using deno as the runtime. The idea is that the configuration builds a state machine-driven program which is bundled into a binary that can only provide access to the I/O your code explicitly needs. I used it primarily to build interactive programs for colleagues which allow some LLM magic to occur without needing to worry about what they would do with Claude Desktop handling the same data or accessing the same machines and so on. It also allowed for testing local LLMs in deterministic patterns. How do they reason about what to do next when they can evaluate the possible states they can enter, based on the current context? It was really fun. Now I don't really know how I'd rebuild it, knowing I wouldn't use Deno. Maybe that's worth learning anyway.
But I stopped because I saw this coming the moment they changed course and started putting npm compatibility as a priority. Deno’s surface area went from beautifully simple to very bloated. I think they felt the pressure of VC funding and just gave up on rebuilding Node from first principles.
The silver lining is that early Deno was so good that Node copied some of its features. So at least we have a better Node now.
The moment they took on VC funding they had to care about competitors and also had to move away from the framework to things like Deno Deploy in pursuit of money.
In the case of the latter, I'm wondering why. Most of cloudflares architecture like workers support js runtimes so wouldnt investment into deno be more strategic than other priorities
I guess this is why so much core staff left suddenly some months ago.
- Cursor -> SpaceX
- Astral/uv -> OpenAI
- Stainless -> Anthropic
- Bun -> Anthropic
- Astro.js -> Cloudflare
- Deno -> Cloudflare
- VoidZero (Vite, etc.) -> Cloudflare
- NuxtLabs -> Vercel
- Hugging Face -> NVIDIA
- ... what else?
GitHub -> Microsoft, or is this too old
replit is NOT aquired.
- Marimo -> CoreWeave
- Continue -> Cursor (xAI)
Yes open source tooling is gulped by AI companies.
What kind of business move is this for Cloudflare? celld is a more complete Cloudflare-at-home runtime than current workerd. What does Cloudflare stand to gain from commodizing Workers?
I'll say that although I'm not really a Cloudflare Workers user, I've been eyeing workerd and celld with interest. The idea of a complete backend in a box appeals to me (see also: PocketBase, Algernon). At the same time, the acquisition means that another company won't acquire Deno for celld.
> "Lock-in" actually hurts us — that's why we went open source If there were truly no escape hatch from Workers, then some of our largest customers would never have signed on with us in the first place.
> [...]
> Ryan and Bert will be leading a new effort to make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model. This will involve merging code and ideas from celld back into workerd. I'm incredibly excited for this work — I will personally be using it to host an instance of Cloudflare OS in my home.
If you live in Elixir land, there's this repo from the Phoenix team, which is quite good. It has pluggable storage, and EKV (https://github.com/chrismccord/ekv) is supported as "batteries include" type storage adapter.
https://github.com/elyase/awesome-object-storage-native#stat...
I've been following celld since it was announced. Bootstrapping both durability and coordination off object storage simplifies so many things for self-hosting. (Yes, ironic that self-hosting has a cloud dependency, but in this case I think justified because S3 has become a widely supported protocol that you can run yourself too).
Will be curious to see the details on exactly how that model makes it into workerd.
I think people are focusing on it because if you've built your business on Deno, then the "Deno will have no support in 13 months time" is a bit of an existential risk, and will be a huge time-sink for your team. So it's far more interesting to most of the people reading this page on HN, because HN is full of people who are first-adopters.
https://github.com/elyase/awesome-object-storage-native#stat...
Things don’t always shake out as you plan
Deno's ability to import directly from a package registry or even git repo in a standalone TS script without requiring a package.json or similar 'meta-data' file was actually really nice for shell scripting stuff. AFAIK node.js still can't do anything similar?
And worse for Deno - nodejs may not be great but it's good enough.
And may you never have an incumbent competitor that is is "good enough" - it will be your downfall.
of course i’m only talking about deno, the technology not deno, the cloud service.
Bad news, sorry, the article says:
> 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.
Sounds like Celld will live on within workerd, Deno is over.
From TFA: 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.
Well node and bun sought to solve the same problems after Deno demonstrated a path. They got to learn from Deno's mistakes as well.
Ironically the reason why I hated it when it was introduced was the reason why they added support for npm (i.e. absolute URLs don't support semver and therefore you will load multiple versions)
Deno Deploy offering would have never be profitable because it contradicted the very core of the Deno's technology promise: absence of lock-in and freedom to self-host.
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
I also wish they expanded jurisdiction more. I worked at companies that couldn't use Cloudflare because of specific location requirements in contracts
The design and architecture is extremely minimal to the point that all of it can be explained on a single A4 page with a 14pt font including D1 + Durable objects. And I hope that it stays that way.
It has all the primitives that you can wish for to build a software system on top of it be it queues, long running jobs, workflows, pipelines, email handlers, cron jobs and even built in AI models ready for you to be invoked.
ATM - it is extremely cheap, reliable, simpler and more capable than anything out there. Deno itself had very little scope anyway because almost no developer tooling is sellable in this environment even more so post AI. Therefore, it is going to accelerate the Cloudflare platform to be the best in class and hopefully not complex and bloated.
It is a bit hypocritical in a sense. Similar to how I was sad that a local restaurant recently closed down. In the past two years I went there maybe three times total. But I just liked having it there as an option.
Deno had a ton of good ideas but I just never felt confident that it would have the lasting power. Some of the early decisions, like their initial refusal to fully support package.json and the npm eco-system, made me unsure of their suitability as the basis for a business.
But I always wanted them to succeed. In the same way I always wanted Heroku to succeed even though I never used their service.
More options are better. But I guess "use it or lose it" applies. Did I dodge a bullet or contribute to the downfall?
No indication cloudflare would pursue that yet that I see.
[0] https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno... [1] https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno...
I feel bad for anyone that now relies on Deno. And as good as Cloudflare might be for some things, I also feel bad for anyone relying on them.
On the plus side, cloudflare will get access to some fantastic talent, who can hopefully put their effort into building a better web.
What's happening to JS platforms? I thought Deno has a much better approach to building a platform.
They took on VC funding.
I had to evaluate Deno vs. Bun vs. Node for a project two years ago, and chose Node. I think Deno has good ideas but often times these projects cannot reach escape velocity, especially when they're constrained by VC motives.
Deno's ability to run TypeScript files - stripping types - was arguably implemented in Node because of Deno. The consolidated tooling approach was a good attempt at solving tooling fragmentation that Node suffers from.
I think for Deno to succeed, it would've had to have been under a non-profit and maybe that can still happen.
Also Deno was starting to try to increase revenue with stuff like Deno Deploy. If Deno did succeed, they would be a direct competitor with Cloudflare Workers
With Bun I think it was basically a marketing ploy. To show that it can be developed by AI and still useful
I guess the positive is that at least Deno pushed Node.js to evolve.
https://blog.cloudflare.com/deno-joins-cloudflare/
TL;DR: Ryan and co. will be merging celld with workerd to create one first-class open source self-hostable runtime for Workers and Durable Objects. In the post I explain in the post why, contrary to what you might think, this is good business for Cloudflare and we're very excited about it.
But I do have a strangely high trust in the individuals involved (you, Ryan, Sunil, others), even though I am a bit perplexed by CloudFlare's incentives or economics
Which is to say: I am choosing to be optimistic :)
Caveat, am commenting before reading, mind you -- just my general reaction to mergers in a world that never cleaves :)
EDIT: though this has also probably deflated a lot of the good-faith conversations I was having with gov-adjacent Europeans about celld being a boon for the moment of heightened European sovereignty, where EU data residency isn't necessarily considered enough distance anymore.
Most of us are here because we’re curious what it means for Deno specifically and FOSS TypeScript runtimes in general, since Bun was also acquired.
edit: my reaction was too soon, it seems like they will be explicitly working on making workerd an open source self hostable runtime
I remember early into my first programming job as an intern in 2017 someone shared a very similar looking series of sketches intended to explain git with cats. I didn't understand it at the time, and then years later when I was much more comfortable with git I took a look at it again and the explanations make just as little sense to me now as it did then.
Also worth calling out that if you want to disrupt a major player, you need to be 10x better, not just 2x.
Either way, congrats team. Hope you going on to build something great at Cloudflare.
I know Node is boring but it's not going anywhere.
Another reason why standards matter. Think twice before you bet on that VC funded horse, folks.
You should choose Node.js unless you have a good reason to use something else. This is what everyone uses, and it is used widely enough that it's in the same position as Java, i.e. it will be supported forever.
Also the other runtimes only offer incremental improvements.
Regarding the blogposts, you don't read a lot about Node.js because it is mature software and there isn't a lot of drama or new things to talk about.
Deno was never going to be a thing anyways.
NodeJS for the runtime if it's not in a browser, webpack for bundling. For the frontend stack, either React if you're in for a full application or, fuck it, good old jQuery if you don't want to do type document.queryXXX all the time. You'll find a ton of developers and coding bootcamp graduates to deal with all of that, and the AI agents should all be trained well enough on them.
Everything else is just a recipe for getting rug-pulled or being the bananaware customer responsible for the ripening.
- there are companies offering serverless functions on their platforms, powered by Deno Deploy. Can this acquisition be an attempt to kill competition?
- Cloudflare now owns a huge chunck of JavaScript ecosystem, like Vercel. They are buying like countries that are arming themselves for war. What is the strategy here?
So what's the story with JSR sticking around then? Does it already see meaningful use among people using Workers, or do they just really want an escape hatch in case we see more long-term issues with GitHub and NPM?
And does it at least mean the stdlib will see continued development?
I liked its scoring system for packages and "make the Typescript docs a public part of the package page" and "focus entirely on ESM-first/ESM-only packages". None of that npm does today, so JSR is still the best way I know to find modern and up-to-date/clean packages versus npm just has a nasty swamp of things still in CommonJS for no reason or that will never get upgraded out of CommonJS because the original maintainers are long gone.
Whom did they work for before?
After Deno did layoffs we saw a consistent decline in announcements and innovation.
Sad day, but unsurprising.
will they continue that work ?
[0]: https://news.ycombinator.com/item?id=49977056
otherwise this is a proper acquisition. t
I know the runtime is in trouble, but i'm not as worried tbh b/c the principles deno championed are going to keep going.
CF has its own quirky serverless technology and has no interest in funding any competition, even/especially in such sad shape as Deno is
Extremely disappointing...
create a plan to implement a javascript runtime similar to {deno,bun,node.js,whatever} in {Rust,C++,ASM,Go,Fortran} language, use subagents @ max effort, keep building until you're done, follow instructions according to INSTRUCTIONS.md
Wait a day and you're done.
i always wondered how they were making money
I've been using deno for years and built some nontrivial services in it. When deno added support for npm packages, the early days were pretty rough. I ran into lots of issues with packages and spent a lot of time reading random github issue threads. It's been pretty smooth sailing for the last year or so though.
At least I can use ai to help migrate off of deno.
I think they ran out of money and joining Cloudflare was their only remaining option.
Especially with LLMs automating all sorts of code and operational aspects, we could do Tcl/Lua type whitelist sandboxes where the application can only call a limited set of functions.
I guess I can say that this means Deno won't ever have a much needed Python 3 moment.
I'll probably move to Rust for scripting I reckon. It's not very mature but hopefully it won't be too much longer.
Fresh was also the best web framework I've used. Oh well.
Ultimately I only trust Node.js to succeed. Bun being too deep into "shipping anything that increases usage".
Deno was a nice alternative with easy configuration and I loved KV and running it on a VPS.
Edit: Yes, but it's not named after me, which this fork fixes.
It's going to be the first JavaScript runtime to natively support Super Intelligence APIs.
I'm having an LLM replacing all occurrences of "ai" in every API with "si", in the hopes that OpenSI or SpaceXSI will acquihire me.
> The Deno team is joining Cloudflare to radically simplify self-hosting Workers and Durable Objects so developers can use the same primitives in more places.
Well, that's pretty big news actually.
I took the plunge and ripped out all my (“open source”) Magento shopfronts and reimplemented them from the ground in…… 2 hours. And it is so much more performant to boot.
(I've trademarked ENDO , feel free to DM me for a license)
> Deno people probably just want a paycheck after they spent years seeking glory and money on something that other people used but didn't pay them a cent for.
My take: Opensource-Infrastructure-as-startup-but-also-charity is a thing that is going to die along with ZIRP. I don't know why VCs ever sniffed around things like this in the first place. The younger generation that followed this business model with liberal "take my stuff" licenses and sneered at GPL etc are learning the hard way that making a nice cool thing and getting noticed is not going to earn you a good living. (And other people will make millions off your passionate work.)
So Deno is going to be unsupported and will no longer be maintained and will be discontinued.
It looks like "written in Rust" is not enough for a selling point and lost out to the fierce competition against Bun.
Though nodejs was even then quite solid in it's position, so maybe it would not have made a difference.
Just this morning I checked the Deno blog (again like so often in recent weeks) to see if they are still alive. The number of mentions in Hacker News posts and comments was zero in recent weeks. The project was basically dead or abandoned already. Sucks, because I went all-in on Deno.
Its no longer gonna be supported after 1 year
In that case Deno is not joining cloudflare, it's got eaten.
I invested a lot and use deno everywhere. Can't trust anything these days.
Lets fork it into opendeno. I like to have an all-in-one swiss army knife tool.
Uh no. The lack of users killed Deno.
Of course, that's not to say the work done on these platforms was wasted. The divide around io.js was meaningful to getting things moving faster and change the governance structure. Deno and bun both showcased things Node could be doing better and some of that was folded back in.
And in spite of all those past experiences, I still find myself using pnpm over npm today. I'm sure npm will continue to evolve and eventually the critical features of pnpm will just be part of core npm. But the gap today is massive enough that pnpm over npm feels critical. The disk usage and performance wins are life-changing for daily work and CI flows.