Deno Team Joins Cloudflare: Runtime Support and Deno Deploy Have End Dates

The Deno team is joining Cloudflare to focus on Workers and Durable Objects. The Deno runtime will receive support for another year, while Deno Deploy will shut down in six months.

· 4 min read · 5 comments

On October 9, 2026, the Deno team announced it was joining Cloudflare. According to the Deno announcement, the team will now work alongside the Cloudflare Workers and Durable Objects teams rather than continue developing the standalone Deno runtime and Deno Deploy service. Users of those products have been given different timelines for support and availability.

What Will Change for Deno Products

The team will support the Deno runtime for another year, with monthly releases containing bug fixes and security updates. After that, the current team will stop developing it. The code will remain open source, so other contributors can continue working on the project.

Deno Deploy will remain available for six months before the service shuts down. Paid customers have been promised help moving to Cloudflare Workers. The announcement does not say that all users will receive migration support.

Other parts of the ecosystem are taking a different path. JSR will continue to operate, but its infrastructure will move to Cloudflare. The team also intends to maintain rusty_v8 and work on integrating it into workerd. It is worth distinguishing what happens to each product: Deploy shutting down does not mean updates to the runtime itself will stop at the same time.

Why Deno Is Joining Cloudflare

The Deno team initially set out to make it easier to build server-side JavaScript applications. It rethought module distribution, runtime security, and tooling, and worked on ways to run applications as standalone executables. Node.js compatibility became an important part of that work: users wanted Deno’s capabilities without losing access to the existing JavaScript ecosystem.

Deno Deploy was meant to make deploying applications easier, but building the service showed the team how much complexity sits behind a convenient interface. Next came celld, which is based on the Cloudflare Workers programming model and designed for distributed applications. The team’s idea is that developers should not have to design scaling infrastructure separately for every application.

At Cloudflare, the team wants to develop this approach alongside the people building Workers and Durable Objects. The goal is to make it usable not only on Cloudflare’s network but also on self-hosted infrastructure. For now, this is a direction for future work, not a ready-made replacement for every Deno use case presented in the announcement.

AI agents get particular attention. Ryan Dahl links his interest in Durable Objects to their combination of serverless execution, persistent state, WebSockets, and a JavaScript interface. Those capabilities help explain why work on celld is centred on Durable Objects. The announcement gives no timeline for a new shared platform.

What This Means for Websites and Web Apps

Developers hosting applications on Deno Deploy should check which parts of their projects depend on the service and what a move would involve. Paid customers will receive help moving to Workers; everyone else should not assume the same terms will apply. The announcement itself does not provide a detailed migration plan for every project.

If an application uses the Deno runtime but is not hosted on Deploy, the question is different: how will the project team plan for future updates and support? Open-source code makes continued community development possible, but the announcement does not promise that anyone will take it on. It helps to separate a possibility from a plan you can already rely on.

Website owners and marketers do not need to understand how a runtime works. They can simply ask their developers whether the site is hosted on Deno Deploy and whether the application depends on Deno. The answers will help establish whether a migration plan or a review of long-term support is needed. This news does not affect every website—only projects that rely on Deno products.

My Take: Easy Deployment Isn’t the Whole System

As a student building my first catalogue with Django and connecting it to a simple frontend, I find it interesting to see the conversation shift from the runtime to application architecture and infrastructure. I’m learning to look beyond the page that opens in the browser: where the data lives, what runs the code, and what happens if one of the services changes.

I like the idea behind celld: I’d rather spend less effort on infrastructure and more on the application itself. But I wouldn’t mistake that goal for a solution I can already use for my own project. Even when a tool lets me get a working draft up quickly, I need to understand what it depends on and ask about future support early. That is what makes Deno’s announcement useful to me.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

  1. Deno Is Joining Cloudflare deno.com

About the author

Inês from Porto

web development student

I’m studying to become a web developer and building my first practice catalog with Django. I’m trying to connect it to a simple front end so I can understand not just the pretty picture, but the data too.

All posts by the author

Discussion 5

Leave a comment

Not published. We’ll send a link to confirm your comment.

No links or ads. Your first comment is published after review. By sending a comment you agree to the privacy notice.

  1. Daniel Borisov

    We’ve moved small client sites off hosted runtimes before, and the real work was tracing scheduled jobs and environment variables, not porting the request handlers; I’d check those dependencies well before Deno Deploy’s six-month cutoff.

    1. Utti Dahl

      @daniel.borisov, I’d be careful treating scheduled jobs and env vars as the main risk: the announcement only promises migration help to paid customers, and Deploy shuts down in six months. First I’d establish what “help” covers and whether the target Workers setup preserves the behavior those jobs depend on; otherwise, tracing dependencies is necessary but not a migration plan.

      1. Otabek Hamraev

        the migration plan probably starts with asking what “help” means, which is a fun little task to fit between the six-month countdown and the next deploy 😅

        1. Hayk Ohanyan

          😅 Have you seen whether Cloudflare has published any concrete checklist for that migration help, or is the first step still figuring out what’s included for paid customers?

      2. Noor van Beek

        one extra thing worth asking before choosing a Workers setup: can you test a small slice of the app there while Deploy is still running? That could surface differences in scheduled-job timing or env-var handling early, without assuming the promised help covers every user 🙂