Deno Deploy shuts down in 6 months: your move to Workers

When does Deno Deploy shut down?

Deno Deploy shuts down six months after the October 9, 2026 announcement, which means roughly April 2027. The date is our arithmetic, because the Deno announcement states a duration and not a day. Plan for April and treat anything later as a bonus.

Deno Deploy is a hosted platform that runs Deno programs at the edge. It is separate from the open source Deno runtime. Both are affected, but on different clocks.

Here is what the announcement says, in plain terms:

Item	What happens	Our date math
Deno Deploy	Keeps operating for six months, then shuts down	About April 2027
Deno runtime	Monthly bug fix and security releases for one year, then development ends	About October 2027
JSR	Keeps running, with infrastructure moving to Cloudflare	No end date given
Paying Deploy customers	Get migration support toward Cloudflare Workers	Not specified

Source: Deno's announcement post by Ryan Dahl, October 9, 2026.

Two details are easy to miss. The runtime stays open source, and the post invites others to continue its development. The post also makes no commitment about Node.js compatibility after the wind-down.

What does Cloudflare buying the Deno team actually change?

Cloudflare absorbs the whole Deno engineering team into its Workers and Durable Objects groups. Future work goes into a shared platform built on Cloudflare Workers, which is a serverless platform that runs JavaScript, TypeScript and WebAssembly on Cloudflare's network. DevOps.com reports that the team will fold its celld project into workerd, the open source Workers runtime.

The stated goal is to make the Workers programming model easy to run on infrastructure you own. ITdaily's coverage frames it the same way. Financial terms were not disclosed.

For a team on Deno Deploy, the practical reading is simple. Deno as a separate hosting product is ending. The people who built it are now building the product you are being asked to move to.

For a team that only uses the Deno runtime locally or in containers, the picture differs. Nothing breaks on a date. You get a year of maintenance, then a decision about whether to stay on a frozen runtime or move to Node.js or Bun. Our post, Does bun check really beat tsc 7? We timed it on 3 repos, covers one side of that choice.

Should you move to Cloudflare Workers or somewhere else?

Move to Workers if your app is a fetch handler with light state. Move to a container host if you rely on long-lived processes. Stay on Deno for self-hosted work only if you accept a one-year maintenance window.

Here is the decision as a short list:

1. Mostly HTTP handlers, cron and static files: Workers is the shortest path. The model is the same: a function that receives a Request and returns a Response.
2. Heavy use of Deno KV with transactions: Workers works, but you redesign the storage layer around Durable Objects.
3. Long-running processes, WebSockets with shared memory, or big in-memory caches: a container platform fits better than any edge function.
4. Self-hosting the Deno runtime: nothing forces a move this month. Pick a date to revisit before the maintenance year ends.

Consider a small API with three routes and one nightly job. That app moves in an afternoon. Consider a collaborative tool that keeps state in Deno KV atomic operations. That app needs a design review first.

How do you port Deno.serve to a Workers fetch handler?

You replace the Deno.serve call with a default export that has a fetch method. The routing code inside stays the same. The Request and Response objects are standard web APIs on both platforms.

This is the Deno version from the DEV Community migration guide:

// Deno Deploy
Deno.serve((req) => {
  const url = new URL(req.url);
  if (url.pathname === "/api/hello") {
    return Response.json({ message: "hello" });
  }
  return new Response("not found", { status: 404 });
});

And this is the Workers version we built and checked:

// src/worker.ts
export interface Env { PREFS: KVNamespace }

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    if (url.pathname === "/api/hello") return Response.json({ message: "hello" });
    return new Response("not found", { status: 404 });
  },
  async scheduled(_e: ScheduledEvent, env: Env) {
    await env.PREFS.put("last", String(Date.now()));
  },
};

The config file is short as well:

{
  "name": "deno-port",
  "main": "src/worker.ts",
  "compatibility_date": "2026-10-01",
  "triggers": { "crons": ["0 * * * *"] },
  "kv_namespaces": [{ "binding": "PREFS", "id": "<your-namespace-id>" }]
}

We ran npx wrangler deploy --dry-run with wrangler 4.151.0. It reported Total Upload: 0.41 KiB / gzip: 0.28 KiB and listed the PREFS binding as a KV namespace. A dry run proves the bundle builds and the bindings parse. It does not prove runtime behavior, so test in a preview environment before you switch traffic.

One behavior change matters. A Workers isolate has no long-lived process, so module-level variables can be dropped at any time. The DEV guide warns about exactly this. Anything you cached at the top of a Deno file needs real storage.

How do Deno KV and Deno.cron map to Workers?

Deno KV maps to Workers KV for read-heavy data and to Durable Object storage for anything transactional. Deno.cron maps to a Cron Trigger plus a scheduled handler. The cron move is mechanical. The KV move is a design decision.

Deno KV is a key-value database built into Deno. It uses array keys such as ["preferences", "ada"], stores JavaScript objects, and supports atomic operations with a version stamp.

The table below is our map of the common pieces. The effort column is our estimate.

Deno Deploy	Workers equivalent	Effort
Deno.serve(handler)	export default { fetch }	Rewrite one file
Deno.cron(...)	triggers.crons plus scheduled()	Config and handler
Deno KV, simple reads	Workers KV	Pick a key format
kv.atomic() transactions	Durable Object with SQLite storage	Redesign
Static files	assets block in the Wrangler config	Config only
npm: specifiers	package.json dependencies	Rewrite imports

Source: DEV Community migration guide, plus our own dry-run port.

Workers KV is globally replicated and suited to data you read often and write rarely. Keys become strings such as preferences:ada, values are JSON, and there is no compare-and-set across keys. If your code uses kv.atomic().check(...), that logic needs a home that gives strong consistency.

Durable Objects are Cloudflare's stateful compute units. Each object has private, strongly consistent storage. The migration guide recommends the SQLite-backed type for new namespaces. Use it for counters, rate limiters, sessions and any check-then-set rule.

For example, a per-user rate limiter that used a KV atomic increment becomes one Durable Object per user. A feature-flag store that was read on every request can stay in Workers KV.

What will it cost: Deno Deploy Pro or Workers Paid?

At 20 million requests a month, our model puts Deno Deploy Pro at $50.00 and Cloudflare Workers Paid at $11.40. The gap widens with volume. It narrows only if your responses are large and egress, not requests, drives the bill.

The inputs are published prices checked on October 16, 2026. Deno's pricing page lists Pro at $20 a month with 5 million requests and 200 GiB of egress included, then $2 per extra million requests. Cloudflare's Workers pricing page lists the Paid plan at $5 a month with 10 million requests and 30 million CPU milliseconds included, then $0.30 per extra million requests and $0.02 per extra million CPU milliseconds.

Method: we assumed 10 milliseconds of CPU per request, no egress overage on either side, and no add-on products. Your CPU time per request is the number to replace.

Monthly requests	Deno Deploy Pro	Cloudflare Workers Paid
5 million	$20.00	$5.40
20 million	$50.00	$11.40
100 million	$210.00	$51.40

Source: NiharDaily model from the two vendors' published prices, October 16, 2026.

The 20 million row works like this. Deno charges $20 plus 15 million extra requests at $2 per million, which is $30. Cloudflare charges $5, plus 10 million extra requests at $0.30, which is $3, plus 170 million extra CPU milliseconds at $0.02 per million, which is $3.40.

Two limits on the model. First, Workers bills for CPU time, so a request that waits on a slow database costs little CPU and a request that crunches JSON costs more. Second, we did not price add-ons such as KV reads or Durable Object requests, which add to the Workers side once you use them.

What breaks when Node-style code moves to Workers?

Most npm packages run unchanged, but code that touches the filesystem, spawns processes or holds raw sockets does not. Node compatibility on Workers is a flag, and the default depends on your compatibility date.

The DEV guide says Workers enable the nodejs_compat flag by default for compatibility dates of August 4, 2026 or later. Our config used a compatibility date of October 1, 2026, so it falls inside that range. If you pin an older date to match old behavior, add the flag yourself.

Check these four areas before you cut over:

1. Imports. Deno's npm: and jsr: specifiers have no meaning in a Workers bundle. Move them to package.json and let the bundler resolve them.
2. Permissions. Deno code written against --allow-read or --allow-env flags assumes a filesystem and environment. Workers pass configuration through bindings, not Deno.env.
3. Startup work. Anything that ran once at process start now runs per isolate, and isolates come and go.
4. Request size and time. Cloudflare lists a CPU limit of 10 milliseconds per request on the free plan and up to five minutes on Paid. Long jobs belong in a cron or queue.

This is the same class of problem we hit in NestJS 12 on AWS Lambda: the ESM crash and how to fix it. A runtime that looks like Node is not Node, and the failures show up at import time.

A migration plan that fits the six months

Start with an inventory, port one service as a pilot, run both platforms in parallel, then cut over DNS with a week of overlap. The schedule below fits inside the window with room to spare.

1. Weeks 1 to 2: inventory. List every Deno Deploy project, its KV usage, cron jobs, secrets and custom domains. Mark each KV call as read-only or transactional.
2. Weeks 3 to 4: pilot. Port the simplest service. Run wrangler deploy --dry-run, then deploy to a preview. Compare responses against the Deno version with a replay of real requests.
3. Months 2 to 3: port the rest. Move transactional KV code to Durable Objects. Set compatibility_date explicitly in every config.
4. Month 4: parallel run. Send a small share of traffic to Workers. Watch error rates, CPU time and cold-start latency.
5. Month 5: cut over. Switch DNS, keep Deno Deploy warm for a week as a rollback, then disable it.
6. Month 6: clean up. Delete unused projects and rotate any secrets that lived in both places.

If you are a paying Deploy customer, ask about the migration support the announcement promises before month two. The post gives no details on what it includes.

Is it worth staying on Deno after Deploy closes?

Staying is reasonable for self-hosted work and risky for anything you expect to grow. Deno will get monthly fixes for one more year, and then official development ends. That is enough time to finish a project, not to start a long one.

A new project started today on Deno inherits a maintenance clock. Node.js has an official schedule with dates through 2029, which we cover in our post on which Node version to run after October 28. Both Node.js and Bun have maintainers with published release plans.

For an existing Deno codebase that runs in your own containers, the cost of waiting is low this month and rises with every dependency that stops testing against Deno. Set a review date six months out. Re-check whether the community has picked up the runtime, since the announcement invites that.

The bottom line: if you are on Deno Deploy, treat April 2027 as a hard stop and start the inventory now. The port itself is small. The Deno KV redesign is the only part that can eat weeks.