Deno Deploy is shutting down after six months, and the Deno runtime itself loses its developers after a year. Both come from Deno's own announcement that the Deno team is joining Cloudflare. We read both clocks as starting on the 9 October 2026 announcement, since the post gives no calendar dates. If anything in your estate runs on Deno or Deploy, you now have two clocks, no stated migration pricing, and no exact date.
What Deno and Cloudflare announced
Deno's post gives three dated terms. The runtime gets support "for another year with monthly releases containing bug fixes and security updates", and then "we will end our development of the Deno runtime." Separately, "Deno Deploy will continue operating for six months before shutting down." Deno will "remain open source", and the team says it welcomes "others who want to continue its development."
Cloudflare's post covers the other side of the deal. The Deno team is joining Cloudflare, and the two companies are merging workerd and celld. Ryan Dahl, creator of Node.js and Deno, and Bert Belder, of the Deno team, will lead a new effort to make workerd self-hosting a first-class supported way to build and run apps.
Timeline
| When | What happens | What isn't stated |
|---|---|---|
| 9 October 2026 | Deno team announces it is joining Cloudflare | Deal terms |
| Six months from 9 October 2026 | Deno Deploy shuts down | The exact shutdown date |
| Over the next year | Monthly runtime releases with bug fixes and security updates | Anything beyond fixes and security |
| A year from 9 October 2026 | Deno ends its development of the runtime | Whether anyone continues it |
| Ongoing | JSR keeps operating, its infrastructure moving to Cloudflare; Deno stays open source | Long-term JSR terms |
What is not decided yet
Neither post gives an exact Deploy shutdown date, so plan against the six-month mark, not a calendar day you've inferred. Neither gives pricing for the migration or for Deploy. Cloudflare says more announcements about the workerd self-hosting work are coming in the coming months. Neither post says whether migration terms will be covered, so don't treat them as final.
Support is thin on detail. Deno says it will "provide migration support for paying customers moving to Cloudflare Workers." That's the whole commitment. It doesn't say what the support includes, how long it lasts, or whether customers moving elsewhere get anything. The posts we're working from also don't say what happens to Deno Subhosting, so if you use it, ask Deno in writing and keep the answer.
Which parts of your estate are exposed
Sort what you run into three buckets before you debate targets.
Anything hosted on Deno Deploy is on the six-month clock. That's the urgent bucket. In our judgment it's often the smallest bucket by service count and the easiest to miss, because edge functions and internal tools get deployed once and forgotten.
Anything running the Deno runtime elsewhere (your own servers, containers, CI jobs, scripts, developer tooling) is on the year clock. It keeps getting fixes and security updates until then. It doesn't stop working on day one.
The third bucket is Deno-specific dependencies: packages from JSR, which keeps operating, and any use of Subhosting, whose fate isn't stated. Ask each owning team to list what they depend on. Don't trust a repository search alone, since runtime choice often lives in a Dockerfile or CI config.
The three exits
| Exit | What the vendors say | What drives effort (our judgment) | Main risk |
|---|---|---|---|
| Cloudflare Workers | Migration support for paying customers; an effort to make workerd self-hosting first-class (not yet delivered) | Deno-specific APIs in your code, number of services, test coverage | Support terms and pricing aren't published |
| Node.js on your own hosting | No stated vendor commitment | Same drivers, plus choosing and running your own hosting | You own the platform work Deploy did for you |
| Stay on open-source Deno | Open source, others welcome to continue it | Close to nothing now | Neither post names a maintainer after the year ends |
Workers is the only path with a stated vendor commitment, and it's the natural default if you're a paying customer. But "migration support" is an undefined phrase today, so don't count it as capacity in your plan.
Staying on the open-source runtime is a bet that someone forks and funds it. That might happen. Nothing in either post says it will. Treat it as acceptable for internal tooling and a poor choice for revenue-bearing services. If you're watching Cloudflare's other cost changes before committing, see Cloudflare's observability pricing change.
Sizing the staffing decision
Size the work by counting services per bucket, by who owns each one, and by how much automated test coverage each has. A well-tested service with one owner moves faster than a large untested one nobody remembers writing. These are editorial judgment, not measured effort, and no source we have gives migration hours.
A workable shape for one quarter: finish the inventory in the first two weeks, pick the exit per bucket by week four, move low-risk services first to learn the real cost, and freeze new Deploy work well before the six-month mark. If your team has no one with the capacity, that's the decision to make now. If the target is Node.js and you'll need extra hands, hiring Node.js engineers covers how to do it. For a parallel runtime end-of-support plan, see the Python 3.10 end-of-life guide.
What to decide before Deno Deploy shuts down
You need three decisions, in this order.
First, name one owner for the migration this week. A shutdown with no owner risks becoming an outage in month six.
Second, commit to an exit for everything on Deploy within roughly the first month, and ask Deno in writing what its migration support covers and what happens to Subhosting. The offer's terms aren't published, so get them in writing now.
Third, decide your runtime strategy inside the one-year window: move off Deno everywhere, or keep it only where you can accept maintaining it yourself. Don't leave self-hosted Deno services to drift. In our judgment, a runtime with no upstream development becomes a security-patching liability over time.
For the wider pattern of vendor deadlines like this one, Platform and language release notes: what breaks and what to fix tracks the platform changes that force these calls.
FAQ
Is Deno dead?
Not yet. Deno says it will support the runtime for another year with monthly releases containing bug fixes and security updates, then end its own development. Deno stays open source, and the team welcomes others continuing it, but neither post names anyone who has committed to doing so.
When exactly does Deno Deploy shut down?
Not stated. Deno says Deploy will keep operating for six months before shutting down. The post gives no calendar date, and we read the clock as starting from the 9 October 2026 announcement.
Do I have to move to Cloudflare Workers?
No. Workers is the path Deno names, with migration support for paying customers. Node.js on your own hosting and staying on the open-source runtime are alternatives, with the trade-offs in the exits table above.
Will Deno stay open source?
Deno says so directly: it will remain open source, and it welcomes others who want to continue its development. JSR will also keep operating, with its infrastructure moving to Cloudflare.