โ† Blog ยท Guides

The Deno Deploy Shutdown Has Two Clocks, and Only One Comes With Help

October 9, 2026

Written 10 October 2026, one day after the announcement.

On 9 October 2026 Ryan Dahl announced on the Deno blog that the Deno team is joining Cloudflare. The headline is a hire. The part that matters to anyone running an app is three sentences further down, and they describe a shutdown with two different clocks.

In Deno's own words: "Deno Deploy will continue operating for six months before shutting down. We will provide migration support for paying customers moving to Cloudflare Workers." And, on the runtime: "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."

Those facts come from Deno's post, not Cloudflare's. Cloudflare's same-day post says only that the team is joining and that workerd and celld are being merged, and points readers to the Deno blog for the rest. If you are quoting the shutdown to your team, quote Deno.

Two clocks, not one

Read the two statements side by side and they are not the same kind of promise.

WhatDeno's statementWhat it does not say
Deno Deploy (the hosted service)"will continue operating for six months before shutting down"A calendar date. Six months is a duration counted from an announcement, not a deadline you can put in a ticket. Until the vendor publishes a date, you do not have one.
Migration help"migration support for paying customers moving to Cloudflare Workers"Anything about the free tier, or about moving anywhere other than Workers. The post is silent on both. Silence is not a refusal, but it is not a plan either.
The Deno runtime"another year with monthly releases containing bug fixes and security updates", then "we will end our development"New features. Bug-fix-only is the stated scope for the year; after it, development by Deno ends.
After that year"Deno will remain open source, and we welcome others who want to continue its development"Who those others are. "Remain open source" means the code stays available. It does not mean the code stays maintained. Those are two different things, and the vendor used two different sentences for them.
JSR (the package registry)"will continue operating, with its infrastructure moving to Cloudflare"Nothing missing here; this is the one component with a continuity statement.

The practical asymmetry is the second row. The free tier of a hosting product is where hobby projects start, and some of those projects become production without anyone deciding that they should. The migration support Deno has promised is scoped to paying customers. If your Deno Deploy app has never had a bill, you are not in that sentence.

What this is not

It is worth being precise, because "platform shutting down" is a phrase that gets attached to the wrong companies. Deno Deploy is a case where the vendor used the words "shutting down" about its hosted product. That is different from a platform entering a maintenance phase. Heroku, for example, has published a "sustaining engineering model" focused on stability and security, and has stopped offering Enterprise contracts to new customers. It has not announced a shutdown. Treating the two as the same situation would be unfair to one and dangerously relaxed about the other.

If you run something on Deno Deploy

  1. Write down what you actually depend on. Deploy-specific APIs (KV, queues, cron, the deployment pipeline) are the part that goes away with the service. Code that only uses the Deno runtime has a longer runway: a year of fixes, then community maintenance if someone takes it up.
  2. Find out which tier you are on, now. The offered migration path is for paying customers moving to Cloudflare Workers. If that is you, ask Deno what the support covers. If it is not, you are planning your own move, and the sooner you know that the better.
  3. Do not plan against an invented date. "Six months" from 9 October is an estimate you made, not a commitment the vendor made. Build your plan to be done comfortably inside it, and watch for the published date.
  4. Decide where you are going before the clock matters. Workers is the sponsored path. A container host, your own server, or another managed platform are all possible. The deciding question is the same one you should have asked of Deno Deploy, below.

The questions this should make you ask of any managed platform

None of this is specific to Deno. Every managed platform can be acquired, refocused or closed, and the time to learn how a vendor winds down is before you need to know. Ask these before you build, and ask them again once a year:

  • What is the notice period, in writing? Six months is what Deno chose. Your contract, or the terms of service, may say less. Know the number.
  • Who gets migration help? Paying customers, every customer, or nobody. If the answer depends on tier, your free-tier side project is not covered, and a side project that quietly became production is the usual casualty.
  • How much of my app is the platform's proprietary API? Count the imports. A platform-specific KV store, queue or cron is convenient right up until the day it is the thing you have to rewrite under a deadline.
  • Can I get my data out, in a format something else can read? Try it now, while nothing is wrong. An export that only works into the vendor's own next product is not an exit.
  • What happens to the open-source runtime without the company? "Open source" answers whether you can read the code. "Who fixes the next security bug" is a separate question, and today, for Deno, the honest answer after the first year is "whoever volunteers".
  • Is the shutdown language actually a shutdown? Learn the difference between "sustaining engineering", "maintenance mode" and "shutting down". They are not synonyms, and vendors choose their words carefully.

Deno Deploy's users have six months and a clear statement of who gets help. That is more than many platforms have given. The lesson is not to avoid managed platforms. It is to know, on the day you sign up, what the last day looks like.

Sources, read 10 October 2026: Ryan Dahl, "Deno is joining Cloudflare", Deno blog, 9 October 2026 (deno.com/blog/cloudflare); Cloudflare, "Deno is joining Cloudflare", 9 October 2026 (blog.cloudflare.com); Heroku, "Introducing Team Authorizations", 30 September 2026, and "October 2026 Update", 7 October 2026 (heroku.com/blog).