Ryan Dahl’s post on the Deno blog on 9 October runs to a few hundred words, and two sentences in the middle do all the work: “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.”

The next sentence is the one to read twice: “Deno will remain open source, and we welcome others who want to continue its development.”

That is the deal as it lands on anyone running Deno in production. The entire Deno team is joining Cloudflare. Deno Deploy, the hosted platform, shuts down in six months, with migration support to Cloudflare Workers offered to paying customers. JSR, the package registry, keeps running on Cloudflare’s infrastructure. The runtime gets twelve months of patches and then an open invitation.

Cloudflare already had a runtime

In the Cloudflare side of the announcement, the word “Deno” barely matters. Kenton Varda, writing for Cloudflare, says “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.” The plan is to merge celld, the Deno team’s recent distributed-systems project, into workerd, Cloudflare’s own open-source runtime.

Cloudflare bought the people who built a runtime, and has no use for the runtime itself. The New Stack’s headline put it plainly: Cloudflare acquired a startup that “copied its serverless playbook”.

Compare the other runtime acquisition of the past year. When Anthropic bought Bun in December 2025, it said Bun would stay MIT-licensed and that it would “continue to invest” in it. Anthropic said Bun had been “key in helping scale its infrastructure” for Claude Code, so Anthropic needs Bun to live. Cloudflare ships on workerd, so Deno can stop.

Cloudflare supplies the cleaner control itself. When it bought Astro in January 2026 it wrote that “Astro will remain open source, MIT-licensed, and open to contributions, with a public roadmap and open governance”, and that the team “will continue to work on Astro”. Nine months later, the Deno team is merged into workerd and the runtime gets “we welcome others”. Same buyer, same year. The variable is that Cloudflare did not already own a web framework. This site runs on Astro, so I read that paragraph twice.

The diligence question this raises is rarely asked: who are the plausible acquirers of this vendor, and do they already own one of these? When the answer is yes, an acquisition is a shutdown with a signing bonus.

“Remains open source” is the weakest promise in software

Open source code with no employer behind it is a liability transferred to you. The thing ending in October 2027 is specifically the monthly security releases. After that, every V8 upgrade and every CVE in Deno’s Rust internals gets fixed by whoever volunteers, or by nobody.

Node.js had its version of this in December 2014, when core contributors forked it as io.js over Joyent’s handling of the project. The fork forced a foundation into existence: by Node v4.0.0 in September 2015 the two were “combined in a single codebase” under the Node.js Foundation, and the runtime stopped belonging to one company.

Deno has no foundation. It has one company, and that company now works for Cloudflare on something else. Dahl says on Hacker News that if people want to carry it forward, “I’d like that”. That is a sincere wish from a founder, and it is not a maintenance plan.

The signal was public for sixteen months

On 20 May 2025, in a post explaining why Deploy had gone from 35 regions to 6, Dahl published “Reports of Deno’s Demise Have Been Greatly Exaggerated”: “We’re not winding down. We’re winding up.” On 3 February 2026, Deno Deploy went generally available. On 25 June 2026, Deno 2.9 shipped deno desktop, halved cold starts, and taught deno install to read npm, pnpm, yarn and Bun lockfiles. On 9 October 2026, Deploy got a shutdown date eight months after GA, and the runtime got twelve months.

None of that was deceptive. Dahl’s own diagnosis, in the same Hacker News comment, is that Deno “has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does”, and that “marginal performance or UX or security benefits are not enough.” A challenger whose selling point has become compatibility with the incumbent has already lost, and the team is the only asset left to buy. The signal was that the rebuttal needed writing at all.

What to do before April

Paying Deno Deploy customers should take the migration support while there is a team to give it. Six months from 9 October is early April 2027, and the offer is a move to Workers: a different runtime and a different deployment model. Budget it as a port.

Free-tier users get the same shutdown date and no promise of help. You are moving yourself.

Teams running the Deno runtime on their own servers have vendor patches until October 2027. Pick the destination in the first half of next year, while Node has a foundation and Bun has an owner that needs it. Waiting for a community fork to appear is a bet on strangers’ weekends.

Teams on a platform built on Deno underneath have exposure they never signed up for. Supabase’s docs say Edge Functions are “developed using Deno”. Netlify’s say Edge Functions run in a “secure runtime based on Deno”. Ask your account manager, in writing, what the plan is.

Investors doing technical diligence should add one line to the checklist: for every runtime and platform in the stack, who is paid to maintain it, and what happens to that company’s product when its most likely acquirer already has one.

If a line in your Dockerfile just acquired an expiry date, jfsi can plan the move before the clock does.