On 2026-10-09 Ryan Dahl published "Deno is joining Cloudflare". The whole Deno team is moving to Cloudflare. From now on their work goes into one shared platform instead of a separate runtime and a separate host. The post landed at the top of Hacker News, at 1341 points in this week's trend bank, and for good reason: it comes with two clocks attached.
This post covers what the announcement says, what each piece of the Deno world is getting, what you need to change if you deployed on Deno Deploy or wrote code against Deno.* APIs, and what is still unknown.
What happened
Dahl's post is short, and it is specific about the timelines:
- Deno Deploy keeps running for six months, then shuts down. Paying customers get migration support to Cloudflare Workers.
- The Deno runtime gets one more year of monthly bug-fix and security releases. After that its development ends. The code stays open source, and the post invites others to carry it on.
- JSR keeps operating. Its infrastructure moves to Cloudflare.
- rusty_v8 stays supported, with work under way to fold it into
workerd, the open-source runtime behind Workers.
No price or deal terms are published. The post points to a joint post by Dahl and Kenton Varda on the Cloudflare blog for the Cloudflare side.
The post also explains why the move happened, and that part is worth reading if you build agents. Dahl describes a progression from Deno to Deno Deploy to a project called celld. It is for building distributed applications from the start, and it "focuses on Durable Objects". At Cloudflare the team will combine its work with the Workers and Durable Objects teams. Dahl calls Durable Objects particularly useful for agent harnesses. So this is not a story about a runtime losing. It is a team betting that the interesting problem has moved from "run JavaScript at the edge" to "keep state for long-running, distributed programs", and agents are one of those programs.
The context: some developers had already left
Six days before the announcement, David Bushell published "Friendship ended with Deno, now Node is my best friend". He moved his projects from Deno to Node and listed why: broken ZSH integration, 429 responses from JSR, and bugs with concurrent requests. After a minimal migration he measured builds 15% faster.
One developer's migration is not a trend, and the post does not claim to be one. But it is the most useful document anyone wrote about Deno this month, because it is a migration checklist written before anyone knew a migration would be needed.
What each kind of Deno code has to do
The six-month and one-year clocks apply to different things, so sort your code first.
Code deployed on Deno Deploy has the short clock. A lot of small AI demos, webhooks and edge functions ended up there, because it was the fastest way to put a TypeScript function on the internet. The post gives two routes: Cloudflare Workers, with migration help for paying customers, or any other host you choose. Six months is enough time, but only if the move is planned in the first month and not the last.
Code that runs on the Deno runtime somewhere else has the long clock. Security releases continue for a year. Nothing breaks on the day of the announcement, and nothing breaks next month either. But "development ends" means new web APIs, new TypeScript versions and new npm compatibility work stop arriving. A year is a deadline for choosing, not a grace period to ignore.
How hard the move is depends on which APIs you used, not on which runtime you used. Code that sticks to web-standard Request, Response and fetch moves almost unchanged, because Workers, Node and Deno all speak those. Code that calls Deno.* APIs, uses Deno KV, or depends on Deno Deploy specifics is the part that needs rewriting.
Bushell's list is a good starting map for the rewrite:
Deno.servebecomes a server adapter. He used Hono's Node adapter, and Hono also runs on Workers, so the same handler can target either.- Deno's file system calls become
node:fs. @std/pathbecomesnode:path.
A practical way to size the job: search your repository for Deno. and for imports from Deno-specific modules. The number of hits is roughly your migration list. Everything else is code you do not need to touch.
Why someone building web apps with AI should care
Three reasons, from most to least direct.
First, deployed demos have a deadline. If you shipped an AI feature as a Deno Deploy function, such as a streaming chat endpoint, a webhook that calls a model, or a small RAG API, it has a fixed window to move. Put the date in your calendar now.
Second, Supabase Edge Functions run on the Deno runtime. Plenty of Next.js apps use them for exactly the AI glue work this post is about: embeddings, webhooks, calls to model APIs. Dahl's post does not mention Supabase at all, so what changes there is unknown. Nobody should migrate on a guess. But it is worth knowing which of your functions use Deno.* calls before anyone asks you to move them.
Third, the reason behind the move points at agents. The team that built a JavaScript runtime now says the platform for long-running, stateful work is where its effort should go, and names agent harnesses as the case. If you are deciding where an agent's state should live, that is a signal about where the tooling investment is heading.
What is not known yet
- Exact dates. The post gives durations, six months and one year, but no calendar dates for the Deploy shutdown or the runtime's end.
- Fresh and Deno KV. The post mentions neither. If your app depends on either, there is no primary answer yet.
- Supabase and other products built on the Deno runtime. Nothing primary says whether they change course.
- Deal terms. None are published.
When any of these get a primary answer, it will come from Deno, Cloudflare or the product's own changelog, not from a summary of a summary.
My take
I checked my own code before writing this. My admin app has one Supabase Edge Function, the one that generates search embeddings (commit bbb2d049). It makes exactly one Deno.* call: Deno.serve. Everything else in it is a web-standard Request and Response.json, plus Supabase's own AI session API, which belongs to Supabase, not to Deno. So if Supabase ever moves off the Deno runtime, my migration is one line plus whatever Supabase changes about its own API. That is the best case, and I got it mostly by accident: the function is small.
The lesson I take is not "avoid Deno". Deno pushed web-standard APIs on the server harder than anyone, and that push is the reason so much Deno code will move easily now. The lesson is that the runtime-specific call is the expensive line, wherever it lives. I would rather write Deno.serve once, at the edge of a function, than spread Deno.* calls through the business logic. The same goes for Node-only or Workers-only APIs. Keep the platform at the border and the handler in the middle, and a decision like this one becomes a small edit instead of a rewrite.
