Written on 10 October 2026, about an announcement Deno published on 9 October 2026.
On 9 October 2026 Deno announced that its whole team is joining Cloudflare. Inside that announcement are two endings that sound alike and are not. One is a hosting platform closing. The other is a runtime whose development is ending. They run on different clocks, and the slower one is the one more likely to catch a business out.
This article is about the difference, and about the one question worth asking of every runtime your software depends on.
What Deno actually announced
All of the following is from Deno's own post. In its words:
- "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."
- "JSR will continue operating, with its infrastructure moving to Cloudflare."
The reason is stated plainly too: "We've decided to put our future development work into this shared platform rather than continuing to develop a separate runtime and hosting service."
Note what those time periods are. "Six months" and "another year" are durations, given by the vendor. The post does not give calendar dates, and neither will we.
Clock one: a platform closing is a deadline
Deno Deploy is a hosting service, and it "will continue operating for six months before shutting down." That is the easy kind of ending to plan for, because it is unambiguous. There is a point after which an app hosted there stops being served. You move before then, or it goes dark.
Two details matter if you are on it. The migration help Deno describes is for paying customers, and it is for moving to Cloudflare Workers specifically. If you are on a free plan, or you want to move somewhere else, plan for the move yourself.
Clock two: a runtime's development ending is not a deadline
The Deno runtime is different, and it is worth being fair about it first. Deno is not abandoning it overnight. It has committed to "another year with monthly releases containing bug fixes and security updates." During that year, the runtime is maintained.
What changes is what comes after. "After that year we will end our development of the Deno runtime." The code "will remain open source" — but open source means the source stays available. It does not, by itself, mean anyone has said they will keep shipping fixes. Deno says it welcomes others who want to continue development; the post does not name anyone who has.
That is why this ending is the harder one. Nothing breaks on any particular day. Your application keeps running exactly as it did. If a risk arrives, it arrives later and quietly — as a security vulnerability that is found after the supported year, with no one yet committed to fixing it upstream. A platform shutdown sends you an email. A runtime that has stopped receiving fixes sends you nothing at all.
The question to ask of everything you run on
Deno is just the clearest current example. The same question applies to every runtime, framework and core library underneath your software:
Who ships the next security patch — and have they said they will?
For each important piece of your stack, it helps to write down:
- Who maintains it. A company, a foundation, a handful of volunteers, or nobody in particular.
- Whether they publish a support policy. Many projects state how long each version receives security fixes. If yours doesn't, that is worth knowing.
- Which version you are actually on, and whether that version is still inside its support window.
- How hard it would be to move. Not because you should move today, but because the cost of moving is the thing you want to know before you have to.
Most of the time the answers are reassuring. The point of asking is to find the one piece where the answer is "nobody has said".
If you run software on Deno
- Find out what runs on it. Applications, scheduled jobs, internal tools and build scripts all count.
- Separate the two clocks. Anything hosted on Deno Deploy has the shorter, harder deadline. Anything that just uses the Deno runtime has the supported year.
- Use the supported year to plan, not to wait. Decide whether you will move to another runtime, rely on a community effort if one appears, or accept the risk knowingly — and write down which.
- Test before you assume. Deno's post notes that "Compatibility with Node.js became an important part of that work too", which may make some moves easier than a rewrite. Whether it does for your code is something only a test will tell you.
Not sure what your software depends on?
That is a common answer, especially for a system built a few years ago by someone who has since moved on. If you would like a clear list of what your software runs on, who maintains each piece, and which ones have no stated plan for security fixes, get in touch.
Source
- Deno, "Deno is joining Cloudflare" — deno.com/blog/cloudflare, published 9 October 2026 (read 10 October 2026)