Cloudflare Acquires Deno: Migration Guide for Deno Deploy and Runtime Users

On October 9, 2026, Cloudflare announced it is acquiring Deno, and the whole Deno team is joining Cloudflare. If you use Deno, the dates that matter are these: Deno Deploy shuts down six months after the announcement, and official development of the Deno runtime ends after one more year of monthly bug-fix and security releases. JSR, the package registry, keeps running on Cloudflare infrastructure. Deploy customers have the least time, so they should start planning now. Teams that only use the runtime can migrate more slowly, but they should still plan to move.

Below: what was announced, what it means for each Deno product, the realistic options you have, and a migration checklist.

What was actually announced

There are two primary sources, and they cover different things.

Ryan Dahl's post on the Deno blog covers Deno's products:

• The entire Deno team is joining Cloudflare and will work with the Workers and Durable Objects teams.
• Cloudflare will support the Deno runtime "for one more year" with monthly bug-fix and security releases. After that, its development of the runtime ends. The runtime stays open source, and others are welcome to continue it.
• Deno Deploy keeps running for six more months and then shuts down. Paying customers who move to Cloudflare Workers will get migration support.
• JSR keeps operating, and its infrastructure moves to Cloudflare.
• Support for rusty_v8 continues, with a goal of integrating it into Cloudflare's workerd.

The companion post on the Cloudflare blog, written by Dahl and Workers lead Kenton Varda, explains why the deal happened. The two teams are merging celld, Deno's self-hosted runtime for Workers and Durable Objects, into workerd, the open-source runtime behind Cloudflare Workers. Dahl and Deno co-founder Bert Belder will lead an effort to make self-hosting workerd "a first-class, supported way" to build and run Workers-style applications. Cloudflare says more details will come "in the coming months."

Neither post gives a price for the deal or a shutdown date for Deploy. Neither says anything about the Fresh web framework, Deno Sandbox, Subhosting, or Deno for Enterprise. If you rely on any of those, assume nothing until you hear otherwise, and ask Deno directly.

Why Cloudflare bought it

Celld is the reason. According to Byteiota's coverage of its launch, Deno released celld on August 5, 2026 under the Apache-2.0 license. It gives each Durable Object its own SQLite database, which is continuously replicated to an S3-compatible bucket. Single ownership of each object is enforced with compare-and-swap operations on S3, so there is no separate consensus service. Dahl's post on Cloudflare's blog notes that workerd only supports Durable Objects as a single local instance, which is fine for testing but not for production. Varda says Cloudflare's own production version depends on many internal services, and an earlier internal attempt to build a self-hostable one failed.

Varda also argues that having an escape hatch is good for Cloudflare's business, because enterprises are less worried about lock-in when they can leave. In a Hacker News comment quoted by Simon Willison, Dahl described the decision to wind down Deno more bluntly. He said Deno "ultimately is not solving big problems," that it had been pulled toward Node compatibility, and that he wants to build new abstractions instead.

What happens to each Deno product

The six-month and one-year dates are counted from the announcement. When Deno publishes exact dates, use those instead.

One more detail for long-time users: the Deno Deploy docs already said Deploy Classic and the v1 Subhosting API would shut down on July 20, 2026. If you moved to the newer Deploy this summer, you now face a second migration within a year.

Your options, compared

There are four realistic paths. Which one fits depends on how much your code depends on Deno-specific APIs (Deno.*, Deno KV, Deno.cron, permission flags) compared with web-standard and npm APIs.

1. Move to Cloudflare Workers (the supported path)

This is the only path that comes with official help. Deno Deploy apps written around fetch-style request handlers usually port fairly directly, because Workers also uses a web-standard fetch handler. The work is in replacing everything specific to Deno:

• Node APIs: Workers supports Node APIs through the nodejs_compat flag. According to Cloudflare's Node.js compatibility docs, projects with a compatibility date of 2026-08-04 or later get it by default. Modules such as Buffer, crypto, stream, http, net and file system are fully supported. node:child_process, node:worker_threads, node:vm and node:http2 are stubs: you can import them, but they don't work.
• Scheduled jobs: Replace Deno.cron with Cron Triggers. These are configured under triggers.crons in your Wrangler config, run in UTC, and call a scheduled() handler. Cron changes can take up to 15 minutes to propagate.
• Data: Depending on your access pattern, Deno KV data needs a new home in Workers KV, D1, or Durable Objects with SQLite storage. Workers KV is eventually consistent. If you relied on KV atomic transactions, Durable Objects are usually the better fit.

Costs, per Cloudflare's pricing page:

• Workers Paid: minimum $5 per month. It includes 10 million requests and 30 million CPU-milliseconds per month. After that, it's $0.30 per additional million requests and $0.02 per additional million CPU-ms. There are no charges for duration or bandwidth.
• Workers KV (paid): includes 10 million reads and 1 million writes per month. After that, reads are $0.50 per million and writes are $5.00 per million.
• Durable Objects (paid): includes 1 million requests and 400,000 GB-seconds per month.

To check the fit, run your current traffic numbers through these rates before you commit.

2. Move to Node.js or Bun on any host

If you mainly used Deno for its TypeScript-first developer experience, and your code already uses npm packages and web-standard APIs, moving to Node or Bun on whatever host you like (containers, Fly, Render, a VPS) avoids being tied to a single platform. Expect to rewrite permission flags, Deno.* calls, and any jsr: or URL imports that have no npm equivalent. Note the ownership trend that Byteiota points out: Anthropic acquired Bun in December 2025, which leaves Node.js as the only mainstream JavaScript runtime without a corporate owner. Bun remains MIT-licensed and under active development. The difference with Deno is that Deno now has an announced end date.

One thing Node doesn't fully replicate is Deno's permission sandbox. As Simon Willison notes, Node's permission model has been stable since v22.13.0 (January 2025), but it can't allow-list specific network hosts. Network access is either fully on or fully off. If you used --allow-net=api.example.com as a security boundary, you'll need to enforce that elsewhere, for example with egress rules at the container or network layer.

3. Self-host the Workers model (workerd plus celld)

Both companies say this is where the deal is headed: the same programming model as Cloudflare Workers, running on your own machines. You can already self-host celld or workerd, according to the Cloudflare post. But the merged, supported version doesn't exist yet. The cost claims also need care. Celld's own site claims 100 resident cells cost about $49 per month versus about $415 on Durable Objects, but Byteiota notes that the workload and pricing assumptions behind those numbers aren't published. Treat this as a path to evaluate and test, not one to commit production traffic to before April 2027.

4. Stay on the Deno runtime and wait for a fork

The runtime gets security patches for about a year. For internal tools and scripts, that window is enough to stay put and see whether a community fork forms. When the Byteiota and AlternativeTo pieces were published, no fork had been announced. Without a fork, an unmaintained runtime that exposes network services becomes a security liability after the final release.

A migration checklist for Deno Deploy users

Six months is tight if you have several services. Work through these steps in order:

1. Inventory everything on Deploy. List projects, custom domains, environment variables, cron jobs, KV databases, and any use of Subhosting or Sandbox.
2. Search the code for Deno-only APIs. Search for Deno., jsr:, https:// imports, Deno.openKv, and Deno.cron. The number of matches is a rough measure of how much rewriting you face.
3. Export your KV data early. Don't leave data migration until the last month. Script the export and import, test them on a copy, and decide whether each dataset belongs in KV, D1, or a Durable Object.
4. Contact Deno about migration support if you pay for Deploy. That support is promised only to paying customers moving to Workers, and neither company has said what it includes.
5. Port one low-risk service first. Set a recent compatibility date, check which Node modules you hit stubs on, and recreate the cron jobs.
6. Run both platforms in parallel. Send a share of traffic to the Workers version, compare error rates and latency, then switch DNS over.
7. Remove the Deploy dependencies well before shutdown, including webhooks, CI deploy steps, and API tokens.

AI coding assistants handle this kind of mechanical API translation well, provided you review every diff. Our AI coding assistants directory lists options worth trying for a port like this.

What this means for builders choosing a platform

The broader lesson concerns end-of-life risk for venture-funded developer infrastructure. Deno was well regarded and widely used, and it still announced an end date for its runtime and hosting product on the same day as the acquisition. When you evaluate a runtime, framework, or hosting platform, ask what happens if the company behind it disappears:

• Is the core open source, and could someone realistically fork it? Deno qualifies, which is why it has the one-year window and the possibility of a community fork.
• Do you write to standards or to proprietary APIs? Code that uses fetch, Web Streams, and standard npm packages moves easily. Code built around Deno.openKv doesn't.
• Can you export your data with your own tools? Managed KV stores are convenient, but they are where migrations are hardest.

Cloudflare is effectively answering the same question about itself. Varda's argument in the announcement is that a credible self-hosting option for Workers and Durable Objects makes the platform easier for cautious enterprises to adopt.

What to watch next

• Exact dates. Watch for a published shutdown date for Deploy and a final release date for the runtime from Deno's blog.
• The details of migration support. Find out whether it means tooling, credits, or engineering help.
• The workerd–celld roadmap. This decides whether self-hosted Durable Objects become production-ready before Deploy closes.
• Fresh, Sandbox and Subhosting. All three are currently unaddressed.
• A community fork of the Deno runtime. Watch for one with real maintainers and a security process.

If you run anything on Deno Deploy, do steps 1–3 of the checklist this month. If you only use the runtime, put a decision date on the calendar for early 2027. By then you'll know whether a fork has formed, and you'll still have time to move before security patches stop.