Deno Deploy Shutdown: How to Migrate to Cloudflare Workers

Deno’s team is joining Cloudflare, and the part with a deadline is Deno Deploy. It keeps running for six months from the October 9, 2026 announcement, then shuts down. The Deno runtime itself gets another year of releases. If you host anything on Deno Deploy, this post is the migration checklist: what was announced, what maps cleanly to Cloudflare Workers, and what doesn’t.

What happens to Deno Deploy

Deno Deploy will keep operating for six months after October 9, 2026, then shut down, per Ryan Dahl’s post on the Deno blog. Paying customers get migration support to Cloudflare Workers. No exact shutdown date was published, so counting forward lands around early April 2027.

The matching Cloudflare post, written by Dahl and Kenton Varda, covers the strategy. Dahl and Bert Belder will lead work to make self-hosted workerd (Cloudflare’s open source Workers runtime) a first-class way to run apps in the Workers model, merging in ideas and code from celld, the Deno team’s Rust implementation of Workers and Durable Objects. Neither post includes a step-by-step migration guide. Cloudflare says more announcements are coming “in the coming months.”

The timeline for each piece

Piece	What the announcement says
Deno Deploy	Runs six more months, then shuts down. Paying customers get migration help to Cloudflare Workers.
Deno runtime	One more year of monthly releases with bug fixes and security updates, then development ends. Stays open source; others are invited to continue it.
JSR	Keeps operating. Infrastructure moves to Cloudflare.
rusty_v8	Continued support, with work toward integrating it into workerd.
Fresh	Not addressed.

Two notes on that table. The free tier isn’t mentioned in the migration-support promise, so assume you’re on your own there. And if you were still on Deploy Classic (dash.deno.com), that was already a separate shutdown: the Deno Deploy docs say Classic and the subhosting v1 API shut down on July 20, 2026.

Who needs to move now

Three groups, three different clocks:

1. Production services on Deno Deploy. Six months is short once you count testing, DNS cutover and a rollback window. Start this month.
2. Deno running in containers, VMs or CI. You’re on the runtime’s one-year clock, not Deploy’s. Pin your version and decide by mid-2027 whether to stay, switch to Node or Bun, or follow a community fork. Our Node.js vs Deno vs Bun comparison covers the tradeoffs.
3. Products built on Deno-only features, such as the desktop packaging from Deno 2.9. Nothing here looks like a hosting problem today, which is exactly why it gets missed. Those features have one year of upstream life left.

Mapping Deno APIs to Workers

Most of a Deno Deploy app ports mechanically. Here’s the inventory I’d run against every project, with the Workers equivalent from Cloudflare’s docs.

Deno Deploy	Cloudflare Workers	Effort
Deno.serve(handler)	export default { fetch(request, env, ctx) }	Low
Deno.env.get("KEY")	env.KEY, or import { env } from "cloudflare:workers"	Low
Deno.cron(...)	Cron Triggers plus a scheduled handler	Low
npm and Node built-ins	Node.js compatibility (nodejs_compat)	Low to medium
Deno KV	Durable Objects storage, or Workers KV for read-heavy data	High
Deploy env vars and secrets	vars in Wrangler config, secrets via dashboard or Wrangler	Low

Step 1: switch to an exported fetch handler, on Deno first

You can do the first refactor without leaving Deno. The deno serve docs accept a file that exports a default object with a fetch handler:

export default {
  fetch(_req: Request) {
    return new Response("Hello world!");
  },
} satisfies Deno.ServeDefaultExport;

That’s the same shape Workers expects, so you can ship this change to Deno Deploy, confirm nothing broke, then move hosts. On Workers the handler also receives env (your bindings) and ctx:

export default {
  async fetch(request, env, ctx) {
    return new Response(`API host: ${env.API_HOST}`);
  },
};

Step 2: move environment variables and secrets

Workers read config from the env parameter, defined under vars in your Wrangler config. To read values outside a handler, the environment variables docs show import { env } from "cloudflare:workers". With Node.js compatibility, process.env is also populated by default for compatibility dates on or after 2025-04-01.

Don’t put secrets in vars, since those aren’t encrypted. Add them as Secret type in the dashboard or with Wrangler’s secrets commands, and use a .dev.vars or .env file for local development (one or the other, not both, and both in .gitignore).

Step 3: replace Deno.cron with Cron Triggers

Declare schedules in Wrangler config and handle them in a scheduled export, per the Cron Triggers docs:

[triggers]
crons = [ "*/3 * * * *", "0 15 1 * *" ]

export default {
  async scheduled(controller, env, ctx) {
    console.log("cron processed");
  },
};

Cron Triggers run on UTC, and changes can take up to 15 minutes to propagate. Check any schedule that assumed a local time zone.

Step 4: turn on Node.js compatibility if you use npm packages

Per Cloudflare’s Node.js compatibility docs, add the flag for compatibility dates from 2024-09-23 through 2026-08-03:

compatibility_date = "2026-08-03"
compatibility_flags = [ "nodejs_compat" ]

For compatibility dates of 2026-08-04 or later, Node.js compatibility is on by default and you can omit the flag. Test anything that touches the filesystem or spawns processes, since a Worker isn’t a full server.

Step 5: plan the Deno KV move carefully

This is where migrations go wrong. Deno KV on Deploy is backed by FoundationDB, always writes with strong consistency, lets reads choose strong or eventual consistency, and supports atomic transactions with check on versionstamps.

Workers KV is a different animal. Cloudflare’s How KV works page says it’s eventually consistent, changes can take 60 seconds or more to reach other locations, and it’s “not ideal for applications where you need support for atomic operations.” Code that does kv.atomic().check(...) and assumes the check holds will break quietly if you port it to Workers KV.

For that kind of data, use Durable Objects. Each object has private storage that Cloudflare describes as “durable, transactional, and strongly consistent,” with a key-value API and, on the SQLite-backed backend, a SQL API. Objects are single-threaded, which removes a class of race conditions, but the programming model is different: you route requests to a named object instead of reading a global keyspace. Our Durable Objects guide covers that model.

A workable split: config, flags and cache entries go to Workers KV; counters, sessions, inventory and anything behind an atomic check go to Durable Objects. Export your KV data before you start, and run both stores in parallel for a week if the data matters.

A cutover order that keeps a rollback

1. Inventory every Deploy project and list which Deno APIs each one calls.
2. Refactor to the exported fetch handler while still on Deno Deploy.
3. Port to Workers in a staging account and move data with a one-off export script.
4. Put the Worker behind a test hostname and replay real traffic against it.
5. Move DNS, keep the Deno Deploy project running until you’re confident, then delete it.

If you’re choosing a runtime for a new project

Without a commitment to upstream development past next year, Deno is a hard recommendation for something you plan to maintain for years. Node.js and Bun are the safer defaults. If you like the Workers model, build on Workers directly, and watch whether the self-hosted workerd work produces a real exit path. Cloudflare says that’s the goal, but nothing has shipped with a date yet.

If you want a second pair of hands on the inventory or the move itself, our engineering team takes on migrations like this.