Ryan Dahl, creator of the Deno runtime, announced on October 9, 2026 that his entire team is joining Cloudflare. The move combines Deno’s work with that of the Workers and Durable Objects teams, and marks the end of Deno as an independent runtime and hosting provider. For developers who deployed applications on Deno Deploy, the announcement sets a fixed migration deadline rather than a routine technical update.
A precise shutdown timeline
Deno Deploy, the company’s serverless hosting service, will keep running for six months before shutting down, with migration support toward Cloudflare Workers for paying customers. The open-source runtime survives longer, but not indefinitely: Cloudflare will ship monthly releases for one year, limited to security and bug fixes, before officially stopping development. The code stays open source and can be picked up by anyone who wants to continue the project.
| Component | Fate | Timeline |
|---|---|---|
| Deno Deploy (hosting) | Shutting down, migration support to Workers for paying customers | 6 months |
| Deno runtime (open source) | Monthly releases, security and bug fixes only | 1 year, then development stops |
| JSR (package registry) | Keeps running, infrastructure moved to Cloudflare | No shutdown date announced |
| rusty_v8 | Maintained by Cloudflare, targeted for integration into workerd | No timeline given |
What it means for a live deployment
A project hosted on Deno Deploy today keeps running without immediate disruption, but the six-month window is short on the scale of an infrastructure migration. Moving to Cloudflare Workers means adapting the deployment configuration, not just flipping a DNS record:
# Déploiement historique sur Deno Deploy (CLI deployctl)
deployctl deploy --project=mon-projet main.ts
# Équivalent côté Cloudflare Workers, une fois le projet migré
npx wrangler deploy
Teams whose architecture relies on Deno Deploy-specific APIs (built-in KV, Deno Deploy cron, proprietary environment variables) face a real porting effort, not a simple URL redirect. An audit of dependencies on Deno Deploy infrastructure is worth starting now, before the six-month window narrows further.
Deno Deploy will shut down in six months; the open-source runtime has only one year of maintenance left before its development officially stops.
A third runtime exits the race as a standalone product
Deno had positioned itself since 2018 as the secure alternative to Node.js, before Bun came to occupy the same ground with a performance argument. With this acquisition, two of the three modern JavaScript runtimes competing with Node.js remain in the race on their own terms: Bun on one side, and Deno’s technical core on the other, now folded into an edge platform rather than sold as a separate product. On Hacker News and Lobste.rs, the discussion centers less on the technical details than on how to read the move: consolidation of the serverless market around Cloudflare rather than genuine continuity for the Deno project. For anyone who chose Deno Deploy specifically for its independence from the big cloud providers, that argument just lost its force. Alternatives such as Firecracker micro-VM-based edge functions remain available for teams looking for serverless hosting outside the Cloudflare ecosystem.
What to do in the meantime
For a project still in development, the simplest path is to wait for the migration instructions promised to paying customers rather than act in a rush. For a site already in production on Deno Deploy, an inventory of command-line tools and platform-specific dependencies makes it possible to size the migration effort before the deadline arrives. Teams that would rather stay in control than follow a vendor can also look into self-hosting, an option that avoids living through this kind of forced switch again.
Key takeaways
The Deno team is joining Cloudflare, Deno Deploy shuts down in six months, and the open-source runtime has only one year of maintenance left before active development stops. JSR and rusty_v8 survive, folded into Cloudflare’s infrastructure. Any application hosted on Deno Deploy should start inventorying its platform dependencies without delay.
I see in this move the confirmation of a known but often underestimated risk: free or cheap serverless hosting tied to a single vendor remains a dependency, not a given. Deno Deploy customers have six months to remember that; everyone else would do well to check the real portability of their own stack now, before the next announcement of this kind — Simon Janvier.
Further reading: the official announcement on the Deno blog.
