Deno joins Cloudflare: Deno Deploy shuts down in six months

Deno is joining Cloudflare. Ryan Dahl announced today that the whole Deno team is moving over, and the fine print is the part that matters: Deno Deploy shuts down in six months, and development of the Deno runtime ends after one more year. If you run anything on Deno Deploy, you now have a deadline. If you built on the Deno runtime, you have a slower one.

What actually happened

Per Deno's announcement, dated October 9, 2026:

• The team: the entire Deno team joins Cloudflare. Ryan Dahl and Bert Belder will lead work on self-hosting for apps built on the Workers programming model.
• Deno runtime: one more year of support with monthly releases for bug fixes and security patches. After that, development ends. The code stays open source, and Deno says others are welcome to carry it forward.
• Deno Deploy: keeps running for six months, then shuts down. Paying customers get migration support to Cloudflare Workers.
• JSR: the package registry keeps running, with its infrastructure moving to Cloudflare.
• rusty_v8: stays supported, with work toward integrating it into workerd, the open-source Workers runtime.

The technical reason is a project called celld, which builds on the Workers model and Durable Objects so distributed apps scale from day one. Code and ideas from it are headed into workerd.

The announcement does not say what happens to Fresh, Deno KV, or Deno Subhosting. If you depend on any of those, assume nothing and ask Deno directly.

Why the Deno to Cloudflare move matters for your business

This is the platform risk we keep warning about, on a calendar. A runtime with real users and a funded team can still turn into a migration project with a six-month clock.

The good news: Deno's bet on web-standard APIs (fetch, Request, Response, Web Crypto) makes the move easier than most. Code that touches those APIs ports to Workers with little change. The friction lives in the edges: Deno.* namespace calls, Deno KV, cron jobs, file system access, and anything that assumed a long-lived process.

Our order of operations:

1. Inventory. List every Deno Deploy project, its domains, env vars, and cron triggers. Note which ones use Deno KV.
2. Grep for Deno. That's your porting list. Everything else is probably fine.
3. Pick the target on purpose. Workers is the paved path, but Node, Bun, or a container on your own host are all valid. Don't migrate twice.
4. Move the paying-customer paths first. Six months goes fast when one of them is the holidays.

Sources: Deno: "Deno is joining Cloudflare", AlternativeTo.