Deno Just Joined Cloudflare. Deno Deploy Shuts Down in Six Months and the Runtime Has One Year Left. Here's the Exit Plan.
On October 9, Ryan Dahl announced that the Deno team is joining Cloudflare. The terms weren't disclosed, but the schedule was: Deno Deploy shuts down after six months, and the Deno runtime gets roughly one more year of bug and security releases before development ends. If a side project of yours deploys to Deno Deploy, you have until about April 2027. If you only run the Deno CLI locally, you have a year of breathing room and a decision to make.
What was actually announced
Cloudflare's post says the team is joining "to radically simplify self-hosting Workers and Durable Objects." In plain terms, Deno's August release of celld, a Rust binary that recreates the Workers and Durable Objects model with only an object storage bucket as an outside dependency, gets folded into workerd, Cloudflare's open-source Workers runtime. Dahl and Bert Belder will lead a push to make workerd self-hosting a supported way to run apps.
Deno's own announcement fills in the timeline. The runtime keeps monthly releases for about a year, then stops. Deno Deploy runs for six months and then closes, and paying customers get migration help toward Cloudflare Workers. The JSR package registry keeps running, with its infrastructure moving to Cloudflare. The code stays open source, and the announcement says it welcomes anyone who wants to continue development.
One thing the primary posts don't pin down is the license for the merged project. One trade-press report quotes Dahl as saying it will likely be Apache 2.0, which is what celld uses. Treat that as a stated intention, not a commitment.
Why this is the third move, not the first
This blog runs on Astro, so I have a front-row seat to the pattern. The Astro team joined Cloudflare in January 2026. VoidZero, the company behind Vite, Vitest, Rolldown and Oxc, followed in June. Now Deno. Each deal came with promises about open governance and continued support for other platforms, and so far those promises are holding for Astro. But Deno shows what the ceiling on a promise looks like: the project stays open source, and the product people were paying for still gets switched off.
I'm not claiming bad faith. Dahl's own explanation is that Deno's growing Node.js compatibility meant maintaining a second implementation of the same thing, and Deploy was "built towards the same ideals as Workers." That's a coherent reason. It's also a reason that applies to any small runtime competing with a platform company's runtime.
Who needs to move, and when
If you host on Deno Deploy, the deadline is real and the clock started October 9. Cloudflare Workers is the path of least resistance, because the Deploy team is going there and paying customers get help. But a runtime change is the moment to ask whether you want the same landlord again.
If you use the Deno CLI for scripts, tooling or a self-hosted server, nothing breaks tomorrow. Monthly security fixes continue for a year, and the MIT-licensed code means a community fork is possible. Dahl himself pointed to io.js as the precedent. A fork surviving is not a plan, though. Plenty of forks don't.
If you publish to JSR, the registry continues under Cloudflare. I'd still keep your packages publishable to npm as well.
The exit plan I'd run this week
First, find out what you actually depend on. Search your repos for deno.json, deno.lock, jsr: imports and Deno Deploy config. Most solo projects have two or three, not twenty.
Second, make each project buildable under Node. Deno has had Node compatibility for a while, so for many projects this is a small change: a package.json, a lockfile and swapping Deno.* APIs for Node equivalents. Do it on a branch and see how big the diff is. That number tells you whether you migrate now or later.
Third, put a container or a plain Node deploy target in CI as a backup. A Dockerfile that runs your app anywhere is cheap insurance against every future acquisition, not only this one.
Fourth, if you do choose Workers, read the limits and pricing before you move, because they differ from Deploy's.
Where I could be wrong
Cloudflare might ship workerd self-hosting that's actually good, and the Deno team might make that corner of the ecosystem better than it was. The "one more year" could turn into a healthy community fork. And a small team moving into a company with real infrastructure is a better outcome than a slow shutdown from running out of money. If you're already on Workers, this is probably good news.
What I'd actually do
If I were on Deploy, I'd have a Node or container version of the app building in CI by the end of November and decide on a host in January, leaving three months of margin before the shutdown. If I only used the CLI, I'd stop starting new projects on Deno, keep the old ones running, and revisit in six months when we see what the fork picture looks like. In both cases, I'd treat the third Cloudflare toolchain deal in nine months as the signal to write down which parts of my stack have a single owner.
Author
Lukas
@lukcombinator