Cloudflare and Deno: What Shuts Down and What Keeps Running

Find the Deno-Specific Code

Start by searching your project for the Deno global and for jsr: and npm: specifiers, which Node.js and Workers don’t understand:

grep -rnE 'Deno\.|jsr:|npm:' --include='*.js' --include='*.ts' \
  --exclude-dir=node_modules .

Check the imports field in deno.json too. Deno projects often map a plain name like @std/ulid to jsr:@std/ulid@1 there, so an import can look portable in your code and still point at JSR.

If your app is written in TypeScript, Deno runs it directly. Current Node.js versions also run .ts files, but only by stripping the types, so features that need compiling, such as enum, fail. Wrangler, Cloudflare’s CLI, compiles TypeScript when it bundles your app for Workers.

Replace jsr: Imports and Deno.serve()

This small Deno app uses a jsr: import and Deno.serve():

import { ulid } from "jsr:@std/ulid@1";

Deno.serve({ port: 8000 }, () => {
  return new Response(`Hello! Your id: ${ulid()}\n`);
});

Node.js and Workers don’t understand the jsr: prefix, so the import fails before anything runs. Install JSR packages through npm with npx jsr add, which writes an .npmrc file that tells npm where JSR packages live. After that, you import the package by its plain name.

Deno.serve() doesn’t exist outside Deno either. On Node.js, the same app starts its server with createServer() from node:http:

import { createServer } from "node:http";
import { ulid } from "@std/ulid";

createServer((req, res) => {
  res.end(`Hello! Your id: ${ulid()}\n`);
}).listen(8000);

On Workers, the app exports an object with a fetch() method instead of starting a server. Workers calls fetch() for each request, and the Response code carries over unchanged:

import { ulid } from "@std/ulid";

export default {
  fetch(request) {
    return new Response(`Hello! Your id: ${ulid()}\n`);
  },
};

Wrangler bundles your packages from node_modules when you deploy, so the npx jsr add install works on Workers too.

Replace Deno Deploy Features

If you’re on Deploy, two more features need a replacement on your new host:

On Deploy, a scheduled job lives in your code:

Deno.cron("clean up sessions", "0 * * * *", async () => {
  await cleanUpSessions();
});

On Workers, the schedule moves into your Wrangler config file, wrangler.jsonc:

{
  "triggers": {
    "crons": ["0 * * * *"]
  }
}

The job itself goes in a scheduled() handler, next to fetch() in the same exported object:

export default {
  async scheduled(controller, env, ctx) {
    await cleanUpSessions();
  },
};

On Node.js, you’d run the job from your system’s cron or with a package such as node-cron.

Move Your Deno KV Data

No published tool moves Deno KV data off Deploy, and Deno’s docs say outside access to KV on the current Deploy is “not currently exposed.” You can still get a copy through continuous backup and the open-source denokv server:

1. In the Deno Deploy dashboard, open your project’s KV tab and set up a backup to an S3 or Google Cloud Storage bucket in the Backup section. The status changes to Active once the first copy is done.

2. Set AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION to your bucket’s credentials, and pull the backup into a local SQLite file:

   Language: Shell

   denokv --sqlite-path ./denokv.sqlite pitr sync \
     --s3-bucket <bucket> --s3-prefix <prefix>/<database-id>/
   

   Replace the placeholders with your bucket name, the prefix you set in the dashboard, and your database’s ID.

3. Run denokv --sqlite-path ./denokv.sqlite pitr list to see the recovery points, and denokv --sqlite-path ./denokv.sqlite pitr checkout <point> to load the latest one into the file.

4. Start the server with denokv --sqlite-path ./denokv.sqlite serve --access-token <token>.

On Node.js, your app then connects with @deno/kv, which reads the token from the DENO_KV_ACCESS_TOKEN environment variable:

import { openKv } from "@deno/kv";

const kv = await openKv("http://localhost:4512");

The protocol that denokv speaks doesn’t include enqueue() or listenQueue(), so if your app uses KV queues, you’ll need a separate queue, such as Cloudflare Queues on Workers. If you’re moving to Workers KV or D1 rather than a self-hosted server, a one-off Node.js script can read every entry with kv.list() and write it into the new store.