Cloudflare Acquires Deno: 365 Days of Bug Fixes, 180 for Deploy, and the 13-Commit Repo at the Centre of the Deal

On 9 October 2026, Cloudflare announced it is acquiring the Deno team. The announcement arrived as two blog posts: one on Deno’s site signed by Ryan Dahl, and one on Cloudflare’s signed by Dahl and Kenton Varda. They describe the same event and almost the same plan. They do not describe the same consequences.

If you only read the Cloudflare post, you would not know that the Deno runtime has twelve months left. If you read both, the shape of the transaction becomes visible: a runtime with 108,720 stars is being wound down on a fixed calendar, and the repository Cloudflare is actually merging into its own stack shows 13 commits across 2 accounts on its default branch.

I pulled the GitHub data before writing this. The runtime was already slowing down long before anyone announced it.

What was actually announced, with dates

The Deno post contains four concrete commitments. They are short and unusually specific:

The technical plan sits in the Cloudflare post: “Ryan and Bert will be leading a new effort to make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model. This will involve merging code and ideas from celld back into workerd.”

The two posts do not say the same thing

I stripped the Cloudflare post to plain text and counted. The body is 10,583 characters. Here is what it contains:

The Cloudflare post mentions the Deno runtime exactly once, to tell readers to go read the other post. Simon Willison flagged the asymmetry on Hacker News: “I don’t like how that’s in the Deno post but gets no mention in the Cloudflare post. Seems like a pretty important detail!”

The counter-argument in the same thread is reasonable: the two posts have different audiences, and the Deno post is where Deno users will look. What the count establishes is narrower and, I think, more useful — the document that will be screenshotted by someone evaluating Cloudflare in 2027 does not contain a single date.

What Cloudflare is actually buying

Here is the repository at the centre of the plan, measured on 10 October 2026:

That contributor count deserves a caveat before anyone writes it on a slide: GitHub’s contributors endpoint resolves commits on the default branch to matched accounts, so it undercounts squashed history, co-authored work and force-pushes. What it does establish is that the public, default-branch surface of the asset being merged into Cloudflare’s runtime is very small — roughly one commit per 400 stars. Dahl’s own Hacker News account (rough-sea) is the majority author.

Why that small repository matters is spelled out by Varda, who is unusually candid about his own runtime’s gap:

“In the interest of transparency, I do have to admit that workerd has always had one big gap in its production-readiness: Durable Objects. Workerd implements them, but only in a single-instance way, good enough for local testing, but unable to scale. We have always wanted to fix this. There are TODO comments in the code going back to the original release.”

And then the admission that makes the acquisition legible: “our production implementation of Durable Object routing is simply not the implementation any self-hoster would want. It’s a beast, designed to handle hundreds of locations, with numerous dependencies on external services operated by a team of site reliability engineers… I actually made an attempt last spring, but, embarrassingly, it didn’t work.”

Cloudflare open-sourced workerd in 2022 because customers like Shopify demanded an escape hatch. Four years later the numbers say the escape hatch was never used much:

workerd has 8.2% of Deno’s stars and 4.9% of its watchers. Varda says it plainly in the post: “We released workerd genuinely intending for people to use it in production. A few have, but so far, not that many.” In the thread, when challenged that workerd users cannot run D1, KV or Queues, he replies: “Details remain to be worked out, but part of the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure. In fact, celld has already done a lot of this.”

The repository had already stopped moving

The most interesting thing I found is not in either announcement. It is the commit rate on denoland/deno’s default branch over the last 700 commits, which reach back to 15 June 2026:

That is an 88.3% collapse between July and September, months before the acquisition was announced on 9 October. In the same window, two accounts (bartlomieju and nathanwhit) produced 429 of 700 commits — 61% of all work.

Release cadence tells the same story. In the twelve months ending 9 October 2026, denoland/deno shipped 42 stable releases — a median gap of 7 days, a mean of 8.4, and a longest gap of 41 days. The last one was v2.9.7 on 17 September 2026, 23 days before the announcement, or 3.3× the median gap. November 2025 had zero releases.

Two dates outside GitHub line up with that curve. denoland/deployctl, the Deno Deploy CLI, was archived on 11 March 2026 — seven months before the post that announced Deploy’s shutdown, while Deploy was still being sold. On 20 March 2026, David Bushell published “404 Deno CEO not found”, reporting that “a good chunk of Deno employees left the company over the last week”, after $4.9M of seed capital and a $21M Series A. Dahl’s rebuttal at the time was titled “Reports of Deno’s Demise Have Been Greatly Exaggerated”.

The organisational picture is not one of a healthy 235-repository project being absorbed. It is one of a project already being wound down by hand: of the 235 repositories in the denoland organisation, 141 (60%) are already archived. The four assets named in the announcement are not obviously the four the project had left.

42 releases a year become 12

The support promise is worth converting into a number, because that is how a team under a deadline will experience it.

Historically, Deno shipped 42 stable releases in twelve months — about 3.5 per month. The commitment for the final year is monthly releases containing bug fixes and security updates. That is a 3.5× reduction in cadence, and it is the difference between a critical CVE landing in a release within days (median 7) and within weeks (up to 31). Nothing in either post commits Cloudflare to a security response time.

The phrase doing the heavy lifting in the Deno post is: “Deno will remain open source, and we welcome others who want to continue its development.” So I measured the bus factor of that offer:

Dahl himself is third on that list with 1,434 commits (9.0%). A fork of a runtime this size, maintained by whoever shows up, is a genuinely hard ask — the question asked in the thread by jflatow was the sharp one: “How can the community carry it forward without you? Will CloudFlare release the name/assets, or it will have to be forked?”

Seven products the letter does not mention

Deno’s own navigation lists eight products. The announcement names four assets, and one of those (JSR) is not even in the denoland organisation any more. Here is what the rest look like, measured today:

Fresh moved out to the freshframework organisation and is still shipping; its community reaction in the thread was blunt but warm — “Fresh was also the best web framework I’ve used. Oh well.” std — the standard library every Deno project imports — gets no separate commitment, which is exactly what commenter chaosharmonic asked about and nobody answered: “And does it at least mean the stdlib will see continued development?”

The strangest row in that table is Claw Patrol. It is listed on Deno’s own product menu as an open-source security firewall for agents, created on 28 April 2026, written in Go, pushed two days before the announcement, with 71 open issues — and one watcher. If you are running agent infrastructure and hoping Claw Patrol keeps receiving security fixes, the announcement says nothing about it either way.

How celld actually works, and what is still unproven

It is worth being precise about what is being merged, because “Cloudflare buys Deno” is a misleading summary of the actual engineering plan. From celld’s own README, the model is:

• One binary, written in Rust. “celld stores the long-term state in your S3-compatible, Google Cloud Storage, or Azure Blob Storage bucket. It needs no serving control plane or consensus service.”
• Every node embeds V8 and executes Wrangler bundles. The nodes sharing one bucket form a fleet, and that bucket holds deployments, cell state and ownership records.
• A cell is a named server with its own SQLite database. Ownership is claimed with a conditional bucket write, so exactly one node owns a cell at a time — no Raft, no membership protocol, no failure detector. Routing and replicated-log transport run over signed peer HTTP.
• KV, Queues, D1, R2, Workflows and Cron Triggers are each implemented as cells, inheriting the same lease and failover behaviour.

That is the genuinely clever part, and it is the reason the acquisition happened rather than a partnership: an object-storage bucket as the only external dependency is a far easier thing to self-host than Cloudflare’s multi-region Durable Object routing.

What is not settled is anything downstream of it:

1. The merge itself. celld is Rust; workerd is C++. Varda: “We don’t completely know what it will look like yet either, but it will absolutely be open source.”
2. Binding parity. Pluggable reference implementations for D1, KV and Queues exist in celld but have not been shown to match managed Cloudflare performance or ergonomics.
3. Whether standalone celld survives. Some readers in the thread asked the obvious question — “Does this mean that celld is dead? No more open source durable objects?” — and nobody answered it. celld’s public surface today is 13 commits, 27 watchers and a push two days before the announcement.

If you run Deno, here is the calendar

Nothing about this requires panic. Deno 2.x is MIT-licensed, works today, and — as several commenters pointed out — its heavy investment in npm compatibility makes leaving less painful than it would have been in 2022. What it requires is a decision with a date attached.

The realistic destinations, with their own signals attached:

• Node.js — 122,260 stars, 3,020 watchers (a 2.47% watcher ratio, the healthiest in this comparison), maintained under the Linux Foundation, and still the default for 99% of projects. The thread’s most-upvoted advice was simply to go back.
• Bun — 96,165 stars, 625 watchers, and owned by Anthropic since 2 December 2025 (a 2,192-point Hacker News thread). The recurring advice in the thread is to use it as an npm-compatible package manager and not to depend on its APIs: “Use bun when it’s drop in replacement of npm, never use Bun API itself.”
• Native Go or Rust — the option a surprising number of commenters said they had already taken. One team lead on the thread (cscheid, running a project built on Deno since 2022) described the reasoning: “we’re moving to a much bigger Rust core program with node for JS user extensibility… I’m not willing to risk using the deno_core crates.”
• celld / workerd self-hosting — the option the acquisition is meant to make viable, and the only one with a dependency on an announcement (“more announcements about this work in the coming months”).

There is a real irony in the deal that the thread’s best comment (ttul) put cleanly: “Fundamentally this acquisition is not about Deno the open source project. It’s about buying an amazing team that has built a self-hosted version of Cloudflare Workers that actually doesn’t suck. And that is all about commoditizing the complement.”

The year both Node challengers were absorbed

Deno is not an isolated event. Bun joined Anthropic on 2 December 2025. Deno effectively stops being developed on 9 October 2027. Within ten months, the two runtimes that spent this decade arguing that Node was leaving performance, security and tooling on the table were absorbed by the two companies best positioned to sell agent infrastructure.

wiseowise drew the investment conclusion: “this would’ve happened to Bun if it hadn’t found its killer app (Claude Code)… Think twice before you bet on that VC funded horse, folks.” syrusakbary framed the market consequence: “I’m a bit concerned that there are very few independent Node.js runtimes.” And zem stated the structural problem with the “community will maintain it” handover: “however distributed an open source project is in theory, in practice it needs a single entity to steward it, otherwise it will die.” One reply suggested the OpenTofu model — a consortium of the companies that depend on the runtime.

Varda’s response to the acquihire accusation is worth reading rather than paraphrasing. Asked about the claim that Cloudflare “had plans to buy out a company with the explicit intent to shut down their main product”, he replies: “I understand why it looks that way, and we knew it would be hard to combat this perception. But it’s simply not true. The actual story is simply this: The Deno team made a strategic decision to refocus on celld.”

The measured timeline supports that framing to a point: the commit collapse, the archived Deploy CLI and the layoffs all predate the deal by months. Dahl’s own explanation is that he agrees with the decision — “It has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough.” He also says what he will not do: “We’ll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I’d like that.”

Both things can be true. Cloudflare did not have to invent a shutdown; Deno was already failing to fund its own runtime. But the consequence is the same for anyone who chose Deno for the reason it existed: the clean break from Node is over, and the license is all that is left of it.

Audit method

All numbers measured on 10 October 2026 from the GitHub REST API (/repos/{owner}/{repo}, /repos/{owner}/{repo}/releases, /repos/{owner}/{repo}/commits, /repos/{owner}/{repo}/contributors, /orgs/denoland/repos, /search/issues), plus Hacker News via the Algolia API and the two announcement posts fetched directly. Known limits: open_issues_count includes pull requests; the contributors endpoint reflects default-branch commits matched to accounts; commit-rate months are bounded by the 700-commit sample (15 June – 6 October 2026), so June and October are partial. Star counts move, so treat the ratios rather than the absolutes as the finding.

FAQ

Is Deno dead? No, but it has a calendar. The runtime keeps receiving monthly bug fixes and security fixes for twelve months from 9 October 2026, then Cloudflare ends its development. It stays MIT-licensed and the source stays public. deno 2.x will keep running for years; what stops is upstream improvement and predictable security response.

What happens to my Deno Deploy deployment? Deploy shuts down after six months (~9 April 2027). Cloudflare’s commitment covers “migration support for paying customers moving to Cloudflare Workers”. Free-tier users are not mentioned in either post.

Is celld going to survive as a standalone project? Unclear, and the announcement does not say. The plan is to merge celld’s ideas and code into workerd, which means the standalone daemon’s future depends on Cloudflare’s roadmap — a roadmap Varda describes as “details remain to be worked out”. If self-hosted Durable Objects matter to you, watch celld’s commit history and treat 13 commits / 27 watchers as the baseline to beat.

Can I keep using Deno for CLI scripts and internal tools? Yes, and the npm-compatibility work of the last three years makes exit easier than it was. Pin your exact version (v2.9.7 is the latest stable as of this writing), vendor your dependencies, and do not plan new architecture around Deno-only APIs such as KV, Deploy or deno compile if you have a multi-year horizon.

What about JSR? It survives and moves to Cloudflare’s infrastructure — the one asset in the announcement with no deadline. Note its measured adoption signals: 2,976 stars, 13 watchers (0.44% of stars), 236 open issues. Commenters in the thread questioned whether a registry whose main differentiator was Deno-native TypeScript publishing has a future without the Deno runtime as a first-class consumer.

Did Cloudflare buy Deno in order to kill it? The data does not support a simple version of that story: commit velocity, an archived Deploy CLI and reported layoffs all predate the acquisition. It also does not support the innocent version. Cloudflare is paying for a team and an asset (celld) that makes its own runtime self-hostable; the runtime that team used to maintain has a year of maintenance releases and one line of text about the community continuing it.

The bottom line

The interesting number in this acquisition is not 108,720 stars or the rumoured price nobody has published. It is the 13 commits in celld’s public history, the 88.3% drop in Deno’s commit rate between July and September, and the zero occasions on which Cloudflare’s own post mentions that the runtime it is acquiring has a year left.

If you are on Deno, you have a deadline and a licence, not a steward. If you are evaluating Cloudflare Workers with self-hosting in mind, the thing to watch is not the announcement but the merge: whether celld’s object-storage-backed cell model actually lands inside a C++ runtime, whether the pluggable bindings catch up with the managed ones, and whether a repository that currently fits on one screen grows into the escape hatch the last four years failed to produce.