09 Oct 2026 · javascript, infrastructure, platforms · 4 min
Cloudflare bought Deno: the runtime has one year left
The announcement
Today, October 9, Ryan Dahl confirmed that the whole Deno team is joining Cloudflare. The post is on the Deno blog, with a second one signed by Dahl and Kenton Varda on the Cloudflare blog.
Where each component lands
| component | deadline | what happens |
|---|---|---|
| Deno runtime | 1 year | monthly releases with bug and security fixes. After that, development ends and the code stays open to whoever wants to continue |
| Deno Deploy | 6 months | shuts down. Paying customers get migration support toward Cloudflare Workers |
| JSR | no deadline | keeps running, with the infrastructure moving to Cloudflare |
| rusty_v8 | no deadline | still supported, heading toward integration into workerd |
The stated reason is not the runtime itself. Dahl wrote that the ambition was always bigger than the runtime and that the destination is the Workers model: compute, state and communication in one place, without every application assembling its own infrastructure. Varda was blunter on the Cloudflare post: the two teams will merge workerd and celld, and Cloudflare admits that Durable Objects support in workerd was single instance only, fine for local testing, unable to scale.
What changes for people who run their own server
The interesting part for self hosting is what Cloudflare says about it. The stated goal is to make the Workers model the default way to build servers, on their network or on yours. The post invites you to self host celld or workerd today. What is missing is scale: distributed Durable Objects. That is exactly the gap the Deno team was brought in to close, according to the announcement itself.
In plain terms: the Deno runtime loses priority, and Cloudflare gets an open path into application hosting, including outside its own cloud.
What I measured
I downloaded both runtimes on this VM (4 vCPU, 5.8 GB of RAM, Ubuntu 24.04, kernel 6.8) and ran the same hello world and the same minimal HTTP server. Six runs each, wall clock median, memory read from each runtime API.
| measurement | Node 22.23.3 | Deno 2.9.7 |
|---|---|---|
| hello world, median of 6 runs | 38.5 ms | 24 ms |
| RSS at script start | 41.3 MB | 28.4 MB |
| RSS with an HTTP server listening | 46.0 MB | 32.0 MB |
| binary size | 124.8 MB | 95.8 MB |
Two behaviour notes came up on the way. First: the Deno server does not start without –allow-net, and the runtime says so before running anything. In Node, the same line of code opens the port without asking. Second: when the script tried to read /proc/self/status to get its own memory, Deno refused even with –allow-read pointing exactly at that file, and only accepted full permission. That is why the memory numbers come from each runtime API instead of /proc.
How I read these numbers
Deno wins on boot time and memory in this sample, and the smaller binary is part of the explanation. None of that explains the shutdown: a runtime at 28 MB RSS on a hello world does not die from performance. What was missing was a business model, and the Organic Software post, written by someone who built products on top of Deno, says that without hedging. They add up users, libraries and services (Deno Deploy, Sandboxes, Fresh) and conclude that migrating back to Node or to Bun is straightforward, because Deno never had strong lock in.
If you depend on Deno
- Deno Deploy: shortest deadline, six months. Move to Workers or another host before that.
- Deno runtime: one year of fixes. If you need it after that, the paths are freezing the version, following forks, or migrating to Node or Bun.
- JSR: keeps working. No rush.
- Libraries: the npm ecosystem still has far more supply, and that is the path Deno itself took by accepting npm in recent years.
What I would not do: switch runtimes because of the announcement. If what you have works and is pinned, one year is time to plan a migration, not to rush a fix.