# Deno Joins Cloudflare — and the Runtime Has One Year Left

> The Deno team is moving to Cloudflare, Deno Deploy closes in six months, the runtime gets one more year of fixes. What exactly was announced, who is affected and what you should check now.

Source: https://www.jpkc.com/db/en/blog/deno-cloudflare/

At the end of August I wrote here about [Bun and Anthropic](https://www.jpkc.com/db/en/blog/bun-anthropic-claude-code/): the runtime inside the Claude Code binary has belonged to an AI company since December 2025. Not quite six weeks later comes the next piece of news of this kind, and it is considerably harder. On 9 October 2026 Ryan Dahl announced that the entire Deno team is moving to Cloudflare. The sentence that drew the most attention in the discussion afterwards sits far down in his post: after one more year, development of the Deno runtime ends.

Exactly two years to the day after Deno 2.0, this is not an acquisition in which a product carries on under a new roof, but an orderly exit. In this article I sort out what exactly was announced, why Dahl is taking this step, who is affected beyond direct Deno users — the list is longer than you might think — and what you should check now. Where I give deadlines that are not official, I say so.

## The short version

| What | What happens | Until when |
|---|---|---|
| **Deno runtime** | Monthly releases with bug fixes and security updates, then the team ends development; stays open source (MIT) | one year, so roughly until October 2027 |
| **Deno Deploy** | Keeps running and is then shut down; paying customers get migration support to Cloudflare Workers | six months, so roughly until April 2027 |
| **JSR** | Keeps running, its infrastructure moves to Cloudflare | no end date given |
| **rusty_v8** | Continues to be supported and is to be integrated into Cloudflare's runtime `workerd` | no end date given |
| **celld** | Is being merged with `workerd` | more "in the coming months", according to Cloudflare |

The month figures in the last column are my own arithmetic from 9 October. At the time of writing there is no concrete shutdown date for Deno Deploy and no migration guide to Workers yet.

## What exactly was announced

There are two primary sources, and both are worth reading: Dahl's post ["Deno is joining Cloudflare"](https://deno.com/blog/cloudflare) on the Deno blog and the joint post by Dahl and Kenton Varda, the technical lead behind Cloudflare Workers, on the [Cloudflare blog](https://blog.cloudflare.com/deno-joins-cloudflare/). Cloudflare files it there under the tag "Acquisitions"; neither side names a price.

The core is a sober list in Dahl's post. 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." On Deno Deploy: the service runs for six more months and is then shut down; paying customers will be helped with the move to Cloudflare Workers. The package registry **JSR** keeps running, with its infrastructure moving to Cloudflare. And **rusty_v8**, the Rust binding to the V8 engine that Deno is built on, will continue to be maintained and is to flow into `workerd`.

Dahl explains this as a decision about focus: the team will put its future work into a shared platform rather than continuing to develop a separate runtime and hosting service. He writes himself that this is a consequential change for everyone who has built on Deno.

What is **not** in either post: what becomes of Deno KV, Deno Sandbox, the Subhosting offering for platform operators and the web framework Fresh. If you use any of these, you simply lack the information for now.

## Why Dahl is taking this step

Dahl tells the reasoning in the Cloudflare post as an arc that starts with his first Node.js demo, and it holds together better than the headline "Deno gives up" would suggest.

Long ago, he writes, he stood in a Berlin warehouse and introduced Node.js with an IRC server in about 500 lines of JavaScript — that was JSConf EU in 2009. What always bothered him about that demo: it was a single server, a single thread even. Scaling IRC takes several machines sharing the channels, plus storage for history and user accounts. In 2018, again at JSConf EU, came his talk "10 Things I Regret About Node.js" and out of it Deno — a runtime with a permission model, TypeScript without a build step and a built-in toolchain. Dahl writes today that Deno did improve the experience of writing JavaScript, but did not fundamentally change what developers have to assemble around the runtime: distribution, state, storage, scaling.

By his own account he found the answer in Cloudflare's **Durable Objects**. A Durable Object is a small, individually addressable server with its own SQLite database; its JavaScript runs single-threaded, it handles WebSockets, and it accesses its local database synchronously. Build a chat with one Durable Object per channel and you have sharded your data and connections automatically — the scaling sits in the programming model, not in the infrastructure.

The problem: outside Cloudflare this model was hard to run. Cloudflare's runtime `workerd` has been open source since 2022, but supports Durable Objects only as a single instance. So the Deno team built **celld**, first released in August 2026: a single binary written in Rust that provides [self-hosted, distributed Durable Objects](https://celld.dev/) and needs an object store as its only external dependency. Existing Cloudflare apps are meant to run on it unchanged, provided they only use the supported APIs. Dahl writes that operating Deno Deploy showed him how entangled cloud infrastructure can become; celld is the opposite.

Kenton Varda is remarkably candid in his part of the post. He admits that Cloudflare neglected the ecosystem around `workerd` — it released the runtime and hoped the community would adapt it to every environment, and that did not happen. Scalable Durable Objects support for self-hosters was always missing, with TODO comments dating back to the first release. celld was exactly what Cloudflare itself had wanted to build. Ryan Dahl and Deno co-creator Bert Belder are now to make self-hosting `workerd` a fully supported path, merging code and ideas from celld into `workerd`.

Varda also uses the post to rebut an accusation that, according to Varda, is commonly made around the internet: that Workers was deliberately built differently to lock customers in. His counter-argument is that large customers like Shopify would never have signed without an open-source runtime, and that there are former customers who left using `workerd`. Whether you read that as an all-clear on lock-in depends on how far you trust that self-hosting really becomes equivalent.

## Who is affected — more than Deno users

At first glance the announcement affects only two groups: Deno Deploy customers, who have to move by roughly April 2027, and developers who use Deno as a local runtime or for `deno compile` binaries. The second group has more time, but no perspective beyond October 2027 unless someone steps up to continue development.

More interesting is who uses Deno *indirectly*, without knowing it:

- **Supabase Edge Functions** run on Supabase's own [edge runtime](https://github.com/supabase/edge-runtime), which is based on Deno. A Supabase employee wrote in the [Hacker News discussion](https://news.ycombinator.com/item?id=50031340) that Supabase operates its own infrastructure and does not depend on Deno's hosting. The goal is to make its successor product **Supabase Compute** — according to the [Supabase website](https://supabase.com/compute) currently in a private alpha — available for existing Edge Functions "well before Deno's support window closes"; there is no public timeline yet.
- **Netlify Edge Functions** are described in Netlify's [documentation](https://docs.netlify.com/build/edge-functions/overview/) as running in a "secure runtime based on Deno". According to a Netlify employee in the same discussion, Netlify no longer uses Deno's managed infrastructure, but still uses the Deno runtime.
- **Slack** relies on a [Deno SDK](https://github.com/slackapi/deno-slack-sdk) for its "Run on Slack" apps. I had not found a reaction from Slack at the time of writing.
- **yt-dlp**, the widely used video downloader, recommends Deno as the [JavaScript runtime](https://github.com/yt-dlp/yt-dlp/wiki/EJS) for its YouTube challenges and enables it by default. If Deno is installed on your machine and you do not remember why — this might be the reason.
- **Val Town** runs its users' code on the Deno runtime, according to its own [documentation](https://docs.val.town/reference/runtime/).

None of these platforms has an acute problem. Supabase and Netlify run their runtimes themselves, and a year of security updates is a decent transition period. But each of them now has to decide whether to maintain a fork, switch to something else or hope for a community takeover. If you run functions on one of these platforms, it is worth keeping an eye on their announcements over the coming months.

You can stay relaxed about **JSR** — the registry keeps running, and packages there are meant for several runtimes anyway — and about everything you get through npm.

## What you should do now

1. **Take stock.** Where does Deno run for you? Directly in projects, as a `deno compile` binary, in CI pipelines, indirectly through Supabase, Netlify, Slack or Val Town, locally through yt-dlp?
2. **Deno Deploy first.** That is the shortest deadline. If you are a paying customer, wait for the announced migration support, but start planning now: Workers is not Deno, and anything that depends on Deno-specific APIs — `Deno.serve`, Deno KV, file system access — has to be reworked.
3. **Count your Deno-specific APIs.** Code that uses only web standards (`fetch`, `Request`, `Response`, web streams) and npm packages can be brought to Node.js, Bun or Workers with manageable effort. The more `Deno.*` calls, the bigger the rework.
4. **Keep applying updates.** The monthly releases are security updates — during the wind-down phase in particular you should not skip them.
5. **Do not start new projects on Deno** as long as no credible community continuation has been announced.

## My take

With this news, the teams behind two of the three big server-side JavaScript runtimes work for companies whose main business is something else: Bun at Anthropic, the Deno team at Cloudflare. Bun lives on as a product, Deno does not. Node.js remains the only one under the roof of a neutral foundation, the OpenJS Foundation.

That is no verdict on the quality of Bun or Deno. Deno noticeably moved the JavaScript ecosystem forward — permissions, TypeScript without a build step, web-standard APIs on the server; much of that has since arrived in Node.js too. But it shows that the question "Who owns the runtime, and what happens when their priorities change?" is part of the technology decision. In the Bun article I described governance as the point I find most robust: no foundation, no fallback commitment in case the owner changes direction — and the fork right of the MIT licence as the actual insurance. With Deno that case has now happened, and not because of a lack of money or bad technology, but because the team can pursue a bigger goal better at another company.

For this site, nothing changes directly. It builds with Eleventy on Node.js, secured the way I described in [my Node.js setup](https://www.jpkc.com/db/en/blog/nodejs-npm-absichern/): Socket Firewall, exactly pinned versions, `npm ci`. And it does not sit behind Cloudflare, as I mentioned in the post on the [crawler defaults](https://www.jpkc.com/db/en/blog/cloudflare-crawler-defaults/). The fork question from the Bun article is no longer theoretical with Deno, though: whether someone turns up to maintain a runtime made of V8, Rust and a complete toolchain for years will show how much that insurance is worth in practice.

I still find the technical idea behind the move convincing. If Workers and Durable Objects really can be self-hosted without compromises, that would be a genuine gain: a programming model that makes distributed applications simple without tying you to one provider. Whether it succeeds will be decided not in announcements but in the releases of the coming months.

## FAQ

### Is Deno being discontinued?

Development by the Deno team ends after one more year, during which there will be monthly releases with bug fixes and security updates. The code stays open source under the MIT licence; Dahl explicitly invites others to continue development. Whether anyone will is open.

### When will Deno Deploy be shut down?

According to the announcement of 9 October 2026, Deno Deploy runs for six more months, so arithmetically until around April 2027. Deno has not named a concrete date yet. Paying customers are to receive support moving to Cloudflare Workers.

### What happens to JSR?

JSR keeps running, its infrastructure moves to Cloudflare. Packages you have published there or install from there remain available.

### What is celld?

An open-source server from the Deno team that runs Cloudflare's Durable Objects and Workers self-hosted and distributed across several machines. It consists of a single Rust binary and needs an object store such as S3 as its only external dependency. celld is to be merged with Cloudflare's open-source runtime `workerd`.

### What about the "JavaScript" trademark dispute?

In November 2024 Deno petitioned the US trademark office to cancel Oracle's "JavaScript" trademark. According to the case docket, the proceeding has been suspended since 28 August 2026 on a consented motion because the parties are negotiating a settlement. Neither announcement mentions the topic.

## Further reading

The story of the other acquired runtime is in [Anthropic and Bun](https://www.jpkc.com/db/en/blog/bun-anthropic-claude-code/). How I secure Node.js projects against supply chain attacks is described in [Working Securely with Node.js and npm](https://www.jpkc.com/db/en/blog/nodejs-npm-absichern/), and why this site is built with Eleventy at all in [Why 11ty](https://www.jpkc.com/db/en/blog/warum-11ty/).

The original sources: Ryan Dahl's post ["Deno is joining Cloudflare"](https://deno.com/blog/cloudflare) with all the deadlines, and the joint post by Ryan Dahl and Kenton Varda on the [Cloudflare blog](https://blog.cloudflare.com/deno-joins-cloudflare/) with the technical reasoning.