Cloudflare acquires Deno

> 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.So unless someone else picks up development, Deno will no longer be supported. reply: This is a wild detail to just bury at the bottom. So many companies went all-in on Deno in recent years. Some even did major migrations off Node.js. Sucks for them I guess, but that's always the risk in chasing the shiny new thing over sticking to the old and dependable.

I'm so bummed about this. Deno is by far my favourite JS runtime. I could sense this coming for a while now, but I was hopeful and just waiting to see what happened. Here we are. I'm glad I don't need to get off the runtime immediately. Sad we won't see any innovation like we did in the last 8 years or so.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.... reply:...

I loved early Deno and am sad to see it die. I invested heavily in the Deno ecosystem because of Ry’s initial vision for it.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. reply: Bun's adoption rate (because of its NPM compatibility) was the forcing function; not VC funding. Deno could pursue a slow-and-steady better-will-win approach vs. Node until another runtime competitor appeared with a more seamless node integration. In fact, the VC funding is what made the slow-but-steady strategy possible in the first place.

"Deno development effectively shut down via a Cloudflare acquihire" would be a better headline. reply: I'm trying to understand this. Cloudflare wants the people to work on different priorities or cloudflare wants deno to die?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

So the developer tooling consolidation/acquisitions continue... hmm!- 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? reply: Shopify bought Remix and Tailwind and hired the maintainer of Preact

RIP, my favorite JavaScript runtime, and thank you. You were too secure for this world.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. reply: From the Cloudflare blog post, this quote from Kenton Varda (head of Workers):> "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....

A lot of the comments are on sunsetting Deno, but the more interesting part is merging the celld model into workerd.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. reply: The plan is to bring the celld model to workerd: run a fleet of workerd instances that use a bucket for coordination and storage. Building on workerd, instead of a separate runtime means our effort isn't split and that APIs are exactly the same in both CF and self-hosted. And of course the deno team will help improve the worker runtime itself.

I feel it leaves a bitter flavor how Ryan Dahl pushed so hard for Deno and Deno Deploy for years, just to let them die within 1 year and 6 months respectively. Thankfully I don't have any codebases that heavily use Deno features, otherwise this would be a steep curve now. reply: Don’t have a strong opinion on any of this, but it’s actually super normal for anyone who helps run a business to push hard and try to grow it.Things don’t always shake out as you plan

To summarize my feelings: Shit!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?

Deno should never have been a business - there's no business model.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.

The Cloudflare side is also worth a read: https://blog.cloudflare.com/deno-joins-cloudflare/

I’m happy if this means Deno is able to get a second impulse. I use Deno daily and while it’s true that it’s in this weird position where it’s not sexy like bun or enterprise-y like node, it has a great developer experience. a no-surprises runtime that does a lot of interesting things the right way (like compile to desktop to a browser-less webgpu runtime), the vscode extension is flawless and overall the perfect balance of batteries included without bloat.of course i’m only talking about deno, the technology not deno, the cloud service.

Damn. Deno is a super old project, in 2018 the Nodejs creator did the talk "things I hate about NodeJS" and introduced Deno. It's 8 years ago now, and clearly even though the project was known by most Node users, it didn't gain any traction at all. I don't even remember "the bad parts" that Deno tries to solve, were they that bad at all ? Anyways Node will keep evolving and implement new features, new standards, optimization. I think it's super risky to move to an alternative. In the age of the LLMs, if you wanna get out of Node, you better translate all to native Go or Rust.

If Deno just took payments or at least donations, it would have thousands, or even tens of thousands of paying customers. Instead, they preferred to submit to VC and chase beehives on Deno Deploy territory.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.

Very unfortunate. I’ve been using Deno for years and recently embedding the runtime into applications/platforms for agents. I’ll continue to use it and hope a community springs up.

Insane, I'm deeply saddened and embittered, I don't want to go back to NodeJS and I don't find any advantage in Bun. I guess this is my sign to just get off of JavaScript entirely.

The first thing I look at the next time I look at a project like Deno would be its governance structure and if it can be bought by a large company. Imagine if what happened here (or MySQL) happens to Postgres!

Congrats on the exit :)Finally, the next step of forking Node is up for grabs:Node > Deno > Done (anyone?)

I think the biggest thing Cloudflare needs to buy is some sort of Postgres-database service. They've already cornered the market for everything front-end/serverless

This might not be seen in much favourable light by many but IMO Cloudflare has the most elegant serveless PaaS as I have seen to date.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.

I wonder how this will affect Bunny's competitor to Cloudflare Workers, Edge Scripting [1] -- which runs on Deno.[1] https://bunny.net/docs/scripting/

I'm very surprised they are not running with the runtime. That seemed like Deno's secret sauce? The rest of it is very aligned with Cloudflare already, deploy, kv, workers, etc seems like the lower hanging fruit.

Even if official development ends next year, the pressure Deno put on Node to modernize TypeScript support and standards was worth it

I'm very sad Deno is going away, even though I've never used it nor did I plan to use it.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?

RIP Deno. Goes into the bin, after Bun.

Big acquisition, but I hope Deno's runtime doesn't get slowly tied to Cloudflare's specific Workers primitive instead of staying standard platform-agnostic.

Didn’t they have a flashy lawsuit to free the JavaScript trademark? What happens to that now?No indication cloudflare would pursue that yet that I see.

I was rooting for Deno so much as I was fighting with node for years. Luckily I made full transition from JS last year and not comming back.