Deno Deploy Shutdown: Migrate to Cloudflare Workers in 8 Steps

Updated 22 October 2026. Deno announced on 9 October 2026 that its team is joining Cloudflare and that Deno Deploy will shut down; this guide covers the timeline, your options and a step-by-step move to Cloudflare Workers.

Deno Deploy is shutting down. On 9 October 2026, Deno creator Ryan Dahl announced that the entire Deno team is joining Cloudflare and that Deno Deploy will keep operating for six months before it shuts down. The Deno runtime gets one more year of monthly bug-fix and security releases, after which Deno will end its development of the runtime. As of 22 October 2026, Deno has not published an exact shutdown date; six months from the announcement points to around April 2027.

If you run anything on Deno Deploy, start now: back up your Deno KV data and collect your secrets this month, then choose where each app goes. The options are Cloudflare Workers, where Deno offers migration support to paying customers; your own server running the Deno runtime, which buys time but not a future; or Node.js. Apps built on Deno.serve, standard Request and Response objects and npm packages move quickly; apps that lean on Deno KV and Deno.cron take longer.

Related: DuckDB 2.0 Upgrade Guide: 12 Breaking Changes and How to Fix Them

Deno Deploy shutdown at a glance

What Deno and Cloudflare announced

Dahl's post says Cloudflare will combine the Deno team's work with its Workers and Durable Objects teams, aiming to make that programming model the default way to build servers, on Cloudflare's network or your own infrastructure. Deno will focus on that shared platform rather than a separate runtime and hosting service. The runtime stays open source, and the post welcomes others who want to continue it.

Cloudflare's joint post, by Dahl and Cloudflare's Kenton Varda and filed under Acquisitions, is about self-hosting: Dahl and Bert Belder will lead work to make self-hosted workerd, Cloudflare's open-source Workers runtime, a first-class option. Releases continue for now, with Deno 2.9.8 out on 21 October 2026, but anything you expect to run beyond 2027 needs a different home. Deno's docs gave 20 July 2026 as the shutdown date for Deploy Classic, the older platform.

Where should your Deno Deploy apps go?

For comparison, Deno Deploy's own plans are Free with 1 million requests a month, Pro at $20 a month with 5 million and Builder at $200 a month with 25 million, per its pricing page on 22 October 2026. Our comparison of VPS, serverless and managed hosting explains what each option leaves you to run yourself.

Deno 2.9 added Node.js 26 compatibility, and Node.js 26 becomes LTS on 28 October 2026, so Node.js is a natural landing spot for apps that already use npm packages. Weighing a port against a rebuild? Our guides on rewrite vs refactor and choosing a tech stack walk through the trade-offs.

How to migrate from Deno Deploy: 8 steps

1. Inventory every app and what it uses

For each app, list its custom domains, environment variables and contexts, Deno.cron jobs, Deno KV databases, Postgres connections, Cloud Connections to AWS or GCP, and anything else configured in the dashboard. Retiring apps nobody uses is the cheapest migration you will do.

2. Recover your secrets before you need them

Deno Deploy secrets are never visible in the dashboard after you create them; only application code can read them. Collect the originals from your password manager or the services that issued them. Better still, issue fresh keys for the new platform and revoke the old ones at cutover.

3. Back up Deno KV

Two routes. The Backup section of the KV tab can stream a continuous backup to your own Amazon S3 or Google Cloud Storage bucket, which the self-hosted denokv server can restore with its pitr commands. Or export with a script that connects through the database URL on your instance page and an access token in DENO_KV_ACCESS_TOKEN, like this illustrative one:

// export-kv.ts: run with deno run -A --unstable-kv export-kv.ts
// Set DENO_KV_ACCESS_TOKEN first and replace DATABASE_ID.
const kv = await Deno.openKv(
  "https://api.deno.com/v2/databases/DATABASE_ID/connect",
);
const prefixes = [["settings"], ["users"], ["orders"]];
const rows = [];
for (const prefix of prefixes) {
  for await (const entry of kv.list({ prefix: prefix })) {
    rows.push({ key: entry.key.join(":"), value: JSON.stringify(entry.value) });
  }
}
await Deno.writeTextFile("kv-export.json", JSON.stringify(rows, null, 2));
kv.close();

Use your own top-level key prefixes. Values such as Deno.KvU64, Uint8Array or Date need converting before plain JSON can hold them, so check a sample, and keep the export after the migration.

4. Move or claim your Postgres database

If you linked your own Postgres server, nothing moves; point the new deployment at the same connection string. If Deno Deploy provisioned the database, it is Prisma Postgres, hosted by Prisma, and you can claim the instance into your own Prisma account. Deno's docs warn that claiming is permanent and cannot be undone. Rethinking the database during the move? See our PostgreSQL vs MongoDB guide, or our Firebase vs Supabase comparison for two managed options with authentication built in.

5. Port the code

Most of the work is swapping Deno-specific APIs for their equivalents:

Here is a small Deno Deploy app, a settings endpoint plus a nightly job, followed by the same app as a Worker. Both are illustrative.

// Deno Deploy version
const kv = await Deno.openKv();

Deno.cron("nightly-job", "0 3 * * *", async () => {
  await kv.set(["jobs", "last-run"], new Date().toISOString());
});

Deno.serve(async (req) => {
  const url = new URL(req.url);
  if (url.pathname === "/banner") {
    const res = await kv.get(["settings", "banner"]);
    return Response.json(res.value ?? { text: "" });
  }
  return new Response("Not found", { status: 404 });
});

// Cloudflare Workers version (src/index.js)
export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    if (url.pathname === "/banner") {
      const banner = await env.SETTINGS.get("settings:banner", "json");
      return Response.json(banner ?? { text: "" });
    }
    return new Response("Not found", { status: 404 });
  },
  async scheduled(controller, env, ctx) {
    await env.SETTINGS.put("jobs:last-run", new Date().toISOString());
  },
};

The export script stored keys such as settings:banner, which is why the Worker reads that key. To keep one codebase across runtimes during the move, use Hono: it runs on Deno with Deno.serve(app.fetch), on Workers with export default app and on Node.js through @hono/node-server.

6. Configure, load the data and deploy

A minimal wrangler.jsonc for the example above. Any compatibility date of 2026-08-04 or later turns on Node.js compatibility by default, and Cron Triggers run on UTC, as Deno Deploy's cron jobs did:

{
  "name": "my-app",
  "main": "src/index.js",
  "compatibility_date": "2026-10-01",
  "kv_namespaces": [
    { "binding": "SETTINGS", "id": "YOUR_NAMESPACE_ID" }
  ],
  "triggers": {
    "crons": ["0 3 * * *"]
  }
}

npm create cloudflare@latest -- my-app
npx wrangler kv namespace create SETTINGS
npx wrangler kv bulk put kv-export.json --binding SETTINGS --remote
npx wrangler secret put API_KEY
npx wrangler dev
npx wrangler deploy

Check where each piece of data belongs before you import it. Cloudflare says Workers KV is eventually consistent, with changes taking 60 seconds or more to reach other locations, and not ideal for atomic operations. Counters, stock levels and anything you updated with kv.atomic() belong in a Durable Object, which has strongly consistent, transactional storage. Mind the limits: Free allows 10 ms of CPU per request and 5 Cron Triggers per account; Paid allows 30 seconds by default and 250 Cron Triggers.

7. Test, then cut over your domains

Deploy to the workers.dev address or a staging hostname first and compare responses with the old version, including headers, redirects, error pages and scheduled jobs. Lower the DNS TTL a day ahead, switch the custom domain, and keep the old app running until traffic and logs look clean. Durable Objects support the standard WebSocket API; our guide to real-time apps with WebSockets covers the design questions.

8. Decommission Deno Deploy last

After a week or two of clean running, revoke the old tokens and keys, store your KV export and database dump safely, then delete the apps and cancel any paid plan. Delete the Deno KV database last: Deno's docs warn that this removes all Deno KV databases and their data.

A realistic migration timeline

Dates after October 2026 are our suggested plan and estimates, not dates Deno has published. Existing scripts and internal tools can stay on the Deno runtime for now, but do not start new production projects on it.

If you would rather hand the move to someone else, porting Deno apps to Workers or Node.js, moving the data and cutting over domains is the kind of fixed-price web development project we take on. Tell us what you run on Deno Deploy and we will map out the move. Our app maintenance cost guide covers what keeping the new setup healthy costs.

Deno Deploy shutdown FAQ

When will Deno Deploy shut down?

Deno said on 9 October 2026 that Deno Deploy will continue operating for six months before shutting down. As of 22 October 2026 it has not published an exact date, so six months from the announcement, around April 2027, is the working assumption. Back up Deno KV and collect your secrets now, and aim to finish moving production apps by early 2027.

Is Deno being discontinued?

Partly. Deno Deploy is shutting down, and Deno will end its development of the runtime after one more year of monthly bug-fix and security releases. The runtime stays open source, and Deno says it welcomes others who want to continue its development. For planning, treat the Deno runtime as unmaintained by its creators from about October 2027.

Will my Deno KV data be deleted?

Assume so once Deno Deploy shuts down, since the KV databases are hosted on it and the announcement gives no separate plan for them. Back up now, either with continuous backup to your own S3 or Google Cloud Storage bucket from the KV tab, or with a script that reads your keys through the database URL and an access token.

Do I have to move to Cloudflare Workers?

No. Cloudflare Workers is where Deno offers migration support, and only to paying customers, but you can also run the Deno runtime on your own server for now or port the app to Node.js. Workers suits APIs and sites that fit its request model and limits. Node.js suits long-lived services and apps that depend on the wider npm ecosystem. Decide app by app.

Can Deno code run on Cloudflare Workers without changes?

Rarely without any changes. Code built on standard Request, Response, fetch and Web Crypto moves easily, but Deno.serve becomes a fetch handler, Deno.env becomes environment bindings, Deno.cron becomes a Cron Trigger and Deno.openKv becomes Workers KV or a Durable Object. Many Node.js APIs work by default on Workers with a recent compatibility date, which helps apps that import npm packages.

What happens to JSR and Fresh?

JSR keeps operating, and Deno says its infrastructure is moving to Cloudflare, so packages published there stay available. Fresh is not mentioned in the announcement. Because Fresh runs on the Deno runtime, plan as if it shares the runtime's timeline: fine for now, with no promise of development after about a year, so start new projects elsewhere.

Sources

• Deno: Deno is joining Cloudflare (9 October 2026)
• Cloudflare: Deno is joining Cloudflare
• Deno blog (Deno 2.9 release summary)
• Deno runtime releases on GitHub
• Deno Deploy documentation (Deploy Classic sunset)
• Deno Deploy pricing
• Deno Deploy: Deno KV backups
• Deno Deploy: Deno KV reference
• Deno KV: Operations
• Deno KV: Overview
• Deno Deploy: Cron
• Deno Deploy: Databases
• Deno Deploy: Environment variables and contexts
• denokv: self-hosted Deno KV
• Cloudflare Workers: Get started
• Cloudflare Workers: Node.js compatibility
• Cloudflare Workers: Cron Triggers
• Cloudflare Workers: Secrets
• Cloudflare Workers: Pricing
• Cloudflare Workers: Limits
• Cloudflare Workers KV: Get started
• Cloudflare Workers KV: How KV works
• Cloudflare Workers KV: Read key-value pairs
• Cloudflare Workers KV: Wrangler KV commands
• Cloudflare: What are Durable Objects?
• Hono: Getting started on Deno
• Hono: Getting started on Cloudflare Workers
• Hono: Getting started on Node.js