Cloudflare Acquires Deno: Deno Deploy Shuts Down in 6 Months

On October 9, 2026, Cloudflare announced that the entire Deno team is joining Cloudflare, which is effectively an acquisition and integration of Deno. In short, Deno Deploy shuts down six months after the announcement (around April 2027), the Deno runtime gets one more year of support before development ends, and JSR keeps running. If you run on Deno Deploy, you need to pick a destination soon.

Based on two primary sources, the Deno blog post by Ryan Dahl and the Cloudflare blog post by Kenton Varda and Ryan Dahl, this article sorts out what has been decided and what is still unannounced. It also covers where to migrate from Deno Deploy, what Deno runtime users can do, and the shortest migration path. More announcements are promised "in the coming months", so always check the official blogs for updates.

The announcement has four core points: the whole Deno team joins Cloudflare, Deno Deploy shuts down, the Deno runtime ends development after one year, and workerd self-hosting gets a boost. Deno was created in 2018 by Ryan Dahl, who also created Node.js, and Deno 2 (2024) greatly improved Node/npm compatibility. The runtime itself is now on a path to retirement, but it stays open source (MIT license) and others are invited to continue its development.

Only two items carry a deadline: Deno Deploy (six months) and the Deno runtime (one year). Surrounding products such as Fresh and Deno KV are not addressed at all. "Not mentioned" does not mean "will continue", so if you depend on them, plan on the assumption that you will need an alternative.

According to Cloudflare's blog, the aim is to make the Workers programming model runnable not only on Cloudflare's network but also on your own infrastructure. Workers runs on the open-source runtime workerd, which is the same code as production. The blog explains that workerd originated when Shopify asked for an open-source runtime after Workers for Platforms was pitched in 2022.

However, workerd's Durable Objects support is currently single-instance only. That is fine for local testing, but it does not scale. This is where celld comes in: the Deno team released it in August 2026 as a Rust binary whose only external dependency is object storage, built on the Workers programming model with a focus on Durable Objects. Cloudflare plans to bring celld's distributed approach into workerd, merging the two.

For background, see our Cloudflare Durable Objects guide and the Cloudflare-only stack. The Deno team will combine its work with the Workers and Durable Objects teams, with the goal of making this model the default way to build servers, whether on Cloudflare's network or your own infrastructure. The Deno blog also lists a contact for teams running agents at scale on their own infrastructure.

- Deno Deploy users: The most affected group. You need to move to another host within six months. Paying customers can get migration support to Workers
- Deno runtime (CLI) users: Monthly bug-fix and security releases continue for one year. For local development and scripts, nothing stops immediately
- Fresh users: Not mentioned, so the future is unknown. Be cautious about new adoption and check your exit options
- Netlify Edge Functions / Supabase Edge Functions users: Both are built on the Deno runtime. Their impact and plans are not announced, so check each vendor's announcements
- JSR package authors: JSR keeps running and only the infrastructure moves to Cloudflare, so no urgent work is needed
- Deno KV users: Because it is tied to Deno Deploy, secure a way to export your data now (its future is not announced)

Choose based on code compatibility, cost, and operational preference. Cloudflare explicitly offers migration support to Workers, but other options are realistic too. The pricing and compatibility notes below are general guidance, so always check each vendor's latest pricing page.

A simple rule of thumb: if you must avoid downtime in the short term, self-host Deno on Fly.io or a VPS; if you want a path that stays maintained, choose Workers; if you already use another serverless platform, use its Functions. Treat self-hosted Deno as a temporary shelter, since development ends in a year.

Most Deno Deploy apps use Deno.serve with a fetch handler, so porting to Workers is relatively straightforward. Workers also exposes a fetch handler through export default, and requests and responses are the Web-standard Request/Response. Following this order reduces rework.

- 1. Inventory: List every use of Deno.serve, Deno.* APIs (such as Deno.env and Deno.readFile), Deno KV, and npm: or jsr: imports
- 2. Replace Deno-specific APIs with Web standards: Use the env binding for environment variables, embed files at build time or move them to R2/KV, and change Deno.serve to export default { fetch }
- 3. Clean up imports: Add npm: packages to package.json and import them normally; switch jsr: imports to an npm-compatible way of consuming them
- 4. Pick a Deno KV replacement: Choose among Workers KV, D1, and Durable Objects based on your access patterns, especially whether you need strong consistency
- 5. Verify and deploy with wrangler: Check with wrangler dev, publish with wrangler deploy, and enable the nodejs_compat flag if needed
- 6. Cut over: Validate on the new URL, then switch DNS. Keep the old Deno Deploy app until its deadline as a rollback path

The standard way to boost portability is to use Hono as your framework. Hono runs on Deno, Workers, Bun, and Node.js, so routing and middleware carry over almost unchanged. See the Hono on Cloudflare Workers guide for details. If you isolate the Deno-specific calls behind an adapter layer, future migrations get cheaper too.

If you use Deno for local scripts, CLI tools, or as a development environment, you get monthly bug-fix and security releases for a year, so there is no need to panic. Still, decide on one of three directions ahead of the end of development.

- Keep using Deno: It is MIT-licensed open source, and the announcement says others are welcome to continue development. A community fork may appear, but nothing has been announced
- Move to Node.js: Recent Node.js supports TypeScript type stripping, so you can run .ts files directly in many cases, and the whole npm ecosystem is available
- Move to Bun: It has built-in TypeScript execution and npm compatibility, so the psychological hurdle is low

Deno's "restrict permissions by default" model does not map directly onto Node.js or Bun. If you run untrusted code, compensate with containers or OS-level isolation when you migrate.

- Exact end date not stated: Deno Deploy ends "six months" after the announcement, but no specific date was given. Aim around April 2027 and leave a margin
- Fresh and Deno KV are unknown: Not mentioned. If you depend on them, design with the assumption that you will replace them
- Netlify / Supabase Edge Functions await vendor announcements: How the end of the Deno runtime affects them has not been announced
- Deno runtime continuation depends on the community: Official support is one year. Any fork or handover is not announced
- More news in the coming months: The workerd and celld merger and concrete self-hosting specs will be clarified later
- Pricing and migration terms need checking: Paying customers should confirm the details of migration support with Deno directly

This announcement is not just "Cloudflare bought Deno". It also signals Cloudflare's direction: make the Workers programming model the standard for servers, in the cloud or on your own infrastructure. For users, the biggest change is the concrete deadlines: Deno Deploy ends in six months, and the Deno runtime ends development in a year. If you are on Deno Deploy, start with an inventory, move toward a portable setup such as Hono, and migrate to Workers or another host. If you use the Deno runtime, use the one-year window to evaluate Node.js or Bun. More details are due in the coming months, so keep checking the official blogs.