Deno Is Joining Cloudflare: What the 12-Month Clock Means for Your Runtime
Deno Deploy shuts down in six months, and the runtime gets one more year of fixes. Here is how to sort your projects by risk.
On this page 7 sections
Deno is joining Cloudflare. Announced October 9, 2026, the deal means Deno Deploy shuts down in about six months, while the open-source Deno runtime gets one more year of monthly bug fixes and security updates. After that, Cloudflare ends development, though the code stays open for anyone to continue.
This explainer covers what the announcement says, what it leaves out, and how to sort your projects by risk. It is written for developers running Deno in production, teams hosting on Deno Deploy, and anyone choosing a runtime for a new project. Backtrace covers runtime and language changes by asking what an upgrade or migration actually breaks, and this one breaks plans.
What Did Deno and Cloudflare Announce?
The entire Deno team is joining Cloudflare, which will focus future work on a shared platform built around Workers and Durable Objects. Cloudflare will support the Deno runtime for another year, then end development. Deno Deploy will run for six months before shutting down.
In Ryan Dahl's announcement, he writes that Deno will remain open source and that the team welcomes others who want to continue its development. Paying Deno Deploy customers get migration support to Cloudflare Workers.
The post also covers two smaller pieces. JSR, the JavaScript registry, will keep operating, with its infrastructure moving to Cloudflare. The rusty_v8 bindings will continue to be supported, with work toward integrating them into workerd, Cloudflare's open-source Workers runtime.
The announcement introduces a new project called celld, built on the Workers programming model. Secondary coverage describes it as a Rust binary that runs Workers apps, including Durable Objects, on your own servers. Treat that description as unconfirmed until you read the primary Cloudflare post.
Some things are not addressed at all. The announcement does not mention Fresh, the Deno web framework, or Deno Subhosting. If you depend on either, you have no stated timeline, which is a risk in its own right.
Is the Deno Runtime Dead?
Not yet, but its future is limited. Cloudflare will ship monthly bug fixes and security updates for a year, which runs to roughly October 2027. After that, official development ends. The code stays open source, so a community fork could carry on, though none has been announced.
Wikipedia's entry for Deno records the same summary: Dahl pledged runtime fixes and security updates for one more year, then a permanent end to development in 2027. The stable release at the time of writing was 2.9.8, dated October 21, 2026.
A year of security patches is a real window, and not an emergency. A script that runs on a laptop can sit on a pinned Deno version for a long time. A public-facing service is different, because it needs a maintained runtime for as long as it serves traffic.
There is also the community question. Open source runtimes survive when enough companies depend on them and a few maintainers have time. Deno has a loyal user base, but its core team is moving to a different product, and the biggest paying customer of the code is now going to be Cloudflare itself.
How Should You Sort Your Deno Projects by Risk?
Sort projects into three groups: things that depend on Deno Deploy, production services that run on the Deno runtime, and local scripts or tools. Deploy users have the shortest deadline at roughly six months. Runtime users have a year. Local scripts have the least urgency.
The table below lays out the three groups and a reasonable first move for each.
| Project type | Deadline | Risk | First move |
|---|---|---|---|
| Hosted on Deno Deploy | About six months | High | Pick a new host and test a deploy |
| Production service on the Deno runtime | About a year | Medium | Plan a move to a maintained runtime |
| Local scripts and tools | No hard deadline | Low | Pin the Deno version |
| Fresh or Subhosting users | Unstated | Unknown | Ask the vendor and watch announcements |
Start with an inventory. Search your repositories for deno.json, deno.lock, and imports that use the jsr: or npm: specifiers. Then list every service that is deployed through Deno Deploy, including preview environments that nobody remembers.
For each item, record what it needs from the platform: KV storage, cron jobs, queues, custom domains, or a particular region. Those features decide how hard the move will be. A stateless HTTP handler is easy to relocate. A service that leans on Deno KV queues is not.
Where Can Deno Deploy Projects Go?
The announcement points paying customers toward Cloudflare Workers, and that is the most direct path. Other edge platforms are options too. The right choice depends on what your app uses. Check each platform's storage, queue, and cron support before committing, because those features rarely map one to one.
Deno's own migration guide, written for its older Deploy Classic service, shows how different platforms behave. It notes that the new Deploy has two regions, US and Europe, compared with six on Classic, and that Deno KV queues are not supported on the new service. It is a reminder to check region and storage differences before you migrate anything.
That guide covers an earlier transition, so do not read its dates as the new timeline. Its deadlines applied to Deploy Classic, not to the six-month window announced on October 9. Use it for the lessons about moving environment variables, custom domains, and KV data, not for the schedule.
Custom domains deserve particular care. The guide recommends adding the new ACME challenge record, switching your CNAME or ANAME records, and allowing up to 48 hours for DNS propagation before removing the domain from the old host. Plan a low-traffic window for the cutover and keep the old deployment live until traffic has moved.
What Should You Move Production Services To?
For services that run on the Deno runtime itself, the lowest-risk target is usually a runtime with a large maintainer base, such as current Node.js releases. Node now supports native TypeScript execution in recent versions, which removes one of the main reasons people chose Deno. Test your own code before assuming parity.
Deno's design helps here. Deno supports npm packages through npm: specifiers and Node modules through node: specifiers, so much of your dependency code already speaks the Node ecosystem. Imports from JSR or Deno-specific APIs are the parts that need rewriting.
If you are moving to Node, review the supported release lines first. Backtrace's checklist on upgrading to Node.js 26 before the LTS date on October 28 covers what changed in the latest line and what to test. It is a useful starting point for picking a target version.
Package management is the next question. Deno handles dependencies in its own way, so a move to Node means choosing a package manager and lockfile format. Backtrace's package manager speed comparison can help you decide, and it shows how install times differ across the main options.
Other options exist. Bun is a common alternative runtime, and some teams will move workloads to Workers or another edge platform. Whichever target you pick, run the same test suite on both runtimes during the transition, and compare behavior around streams, file system access, and permissions, where Deno's model is strict.
Edge runtimes and WebAssembly are part of this story too. If you are weighing a lighter-weight target, Backtrace's analysis of whether WebAssembly is production ready in 2026 is relevant to that choice.
What Is a Sensible Migration Timeline?
A workable plan runs in three phases. Spend the first month on inventory and decisions, the next three months moving Deploy workloads, and the remaining months moving runtime services. Leave a buffer, because migrations always find surprises. Pin versions on everything you do not move.
Here is a timeline you can adapt to your own team:
- Weeks one to four: inventory projects, record platform features used, choose targets.
- Months two to four: rebuild and test Deploy workloads on the new host, then cut over.
- Months five to nine: port runtime services, running both runtimes in parallel.
- Months ten to twelve: retire Deno from production, and keep a pinned copy for scripts.
Pinning is the cheap insurance. Backtrace's local dev environment setup guide explains how to lock tool versions so a script written today still runs next year. Do that for every Deno script you keep.
Finally, watch for forks and community news. The announcement invites others to continue development, and the next few months will show whether any group steps up. Do not plan around a fork that does not exist yet, but do check back before you make a final call on a low-risk project.
Conclusion
Deno joining Cloudflare shortens the life of a runtime that many teams adopted for its security model and tooling. Deploy users have about six months, runtime users about a year, and script authors can pin a version and move on. Inventory your Deno usage this week and choose targets before the deadlines get close. Backtrace will track forks and migration guides as they appear.
