The Deno team joins Cloudflare: Deno Deploy shuts down in six months
On October 9, 2026 Ryan Dahl, who created Deno, announced that Deno's whole team is moving to Cloudflare. The Deno Deploy hosting service will run for six more months and then close. The Deno runtime gets a year of monthly bug and security fixes, after which the team stops developing it. The JSR package registry stays online.
Deno's team combines its work with the Workers and Durable Objects teams
The news arrived in two places on October 9, 2026. On the Deno blog, Ryan Dahl wrote that the whole team is moving to Cloudflare, and Cloudflare published a joint post on its own blog the same day, signed by Kenton Varda and Ryan Dahl. Dahl says the team will work alongside Cloudflare's Workers and Durable Objects groups. The aim is to turn the Workers programming model into the standard way to write server software, regardless of whether an app lives on Cloudflare's network or on a company's own machines.
Cloudflare filed its post under the Acquisitions tag on its blog. Both posts, however, describe the move as the team joining Cloudflare, and neither gives a price or deal terms. Dahl presents it as a decision about focus: instead of maintaining a separate runtime and a separate hosting product, the team will put its future work into the platform it now shares with Cloudflare. He also openly acknowledges that the change carries serious consequences for those who built products and businesses on Deno.
The timeline: six months for Deno Deploy, one year for the runtime
The Deno post lists the practical consequences one by one. The Deno runtime will receive monthly releases with bug and security fixes for one more year. Dahl is blunt about what follows: "After that year we will end our development of the Deno runtime." Deno stays open source, and others are welcome to carry it forward. Deno Deploy keeps running for six more months and then closes, with migration help offered to paying customers who move to Cloudflare Workers. The JSR package registry keeps operating, and its infrastructure is being moved onto Cloudflare. The team will also keep maintaining rusty_v8 and work on bringing it into workerd, Cloudflare's open-source runtime. The announcement does not address the future of the Fresh framework, Deno Sandbox or Subhosting.
At the technical core sits celld. According to Varda, the Deno team released celld in August; it is an open-source, self-hostable implementation of the Workers and Durable Objects model. Dahl describes it as a single Rust binary whose only outside dependency is object storage. Varda, for his part, admits that workerd's Durable Objects support has so far been limited to one instance, fine for local testing but unable to scale. The plan is to fold celld's code and ideas back into workerd. Ryan Dahl and Bert Belder will lead a new effort to make self-hosting with workerd a first-class, supported option, and Varda says more announcements on this will come in the coming months.
Serverless JavaScript is regrouping around infrastructure for AI agents
Deno Deploy users feel this first. Anyone running a site, an API or backend jobs there now has a six-month window to move, and paying customers have been promised help migrating to Cloudflare Workers. Teams running the Deno runtime on their own servers have a year of security updates ahead of them. After that the project remains open source, but further development will depend on whoever chooses to take it on rather than on the Deno team.
Dahl writes that the need for better abstractions is especially pressing with AI. In his view, Durable Objects combine low-cost serverless compute, durable state, WebSocket support and a high-level JavaScript API, a mix he finds especially useful for the harnesses that run AI agents, which is why celld centres on Durable Objects. Varda, meanwhile, answers the criticism that Workers' unusual design locks customers into Cloudflare: he writes that workerd was open-sourced after customers such as Shopify said in 2022 that they could not build on Workers for Platforms without an open runtime, and that some former customers have since used workerd to leave. We covered another of Cloudflare's agent-oriented products in our Kitesurf story.
The sources say nothing about Türkiye, so this section is commentary
Neither source mentions Türkiye. There is nothing on how many businesses or developers in Türkiye use Deno Deploy, no separate migration schedule for paying customers there, and nothing on Turkish-language support or any regional infrastructure change. What follows is therefore not a fact drawn from the sources but UNALSOFT's own commentary.
Our view: teams in Türkiye running a small site, a form backend or a webhook on Deno Deploy should plan the move now. Six months is not long once testing, domain routing and rebuilding environment variables are counted in. For internal tools that depend on the Deno runtime, the direction should be settled before the one-year update window closes: move to the Workers model, switch to another runtime, or follow a community-maintained version.
The UNALSOFT view
We read this as a reminder that a platform choice can turn into a business risk. When a hosting service closes, most of the work usually sits outside the code itself: domain settings, environment variables, scheduled jobs and monitoring that were wired to that provider. That is why, in our web design projects, we treat documenting how much an application depends on each service, and keeping the hosting layer portable, as part of the delivery. Because the sources contain no data about Türkiye, this piece does not propose a local timeline.
Is your site tied to a platform that is closing?
A short call is enough to map your hosting dependencies together and pin down a migration plan.