Last week, Cloudflare announced it was acquiring Deno — the JavaScript and TypeScript runtime created by Ryan Dahl, the same person who originally built Node.js. If you’re new to the platform, Cloudflare Workers is a serverless compute service that runs JavaScript code on Cloudflare’s global edge network — close to your users, without managing servers. The news sent ripples through the developer community. — the JavaScript and TypeScript runtime created by Ryan Dahl, the same person who originally built Node.js. The news sent ripples through the developer community. If you’ve been using Deno or Deno Deploy, you’re probably wondering what this means for your code. And if you’ve never tried Deno, you might be asking whether it’s worth learning now that it’s part of Cloudflare.
celld project into workerd, Cloudflare’s Workers runtime.
What does that mean for you right now? It means the best way to run Deno code on Cloudflare’s edge network is still to deploy it as a Cloudflare Worker. And that’s exactly what I’ll walk you through in this tutorial.
What You’ll Need
Before we start, make sure you have these installed:
- Deno (v1.40 or later) — the runtime itself. Install it from deno.com if you haven’t already.
- A Cloudflare account — the free tier is more than enough for this tutorial.
- Basic TypeScript familiarity — Workers are written in TypeScript, but if you know JavaScript, you’ll be fine.
If you’re developing on Windows, I’d recommend using WSL. Windows has come a long way for development work, and tools like Docker run much more smoothly in a Linux environment. I covered the state of WSL containers in my recent post on the topic — it’s worth a read if you’re setting up a new dev machine.
Step 1: Install denoflare
Cloudflare’s official CLI, Wrangler, is built for Node.js. To deploy Deno code, we use a community-created CLI called denoflare. It handles the transpilation and bundling that Deno code needs before it can run on Cloudflare’s V8-based edge network.
Install it globally with this command:
deno install --unstable-worker-options --allow-read --allow-net --global --allow-env --allow-run --name denoflare --force \
https://raw.githubusercontent.com/skymethod/denoflare/v0.6.0/cli/cli.tsThat’s a mouthful, but it’s a one-time setup. The --unstable-worker-options flag is required because denoflare uses some unstable Deno APIs under the hood. The --allow-* flags give it the permissions it needs to read files, make network requests, and run subprocesses.
Step 2: Create Your Worker Function
Create a new directory for your project and add a main.ts file. At minimum, a Cloudflare Module Worker needs to export a default object with a fetch handler:
export default {
fetch(request: Request): Response {
return new Response("Hello, world!");
},
};That’s the simplest possible Worker. It receives a Request and returns a Response. You can test it locally before deploying:
denoflare serve main.tsOpen localhost:8080 in your browser and you’ll see “Hello, world!” — your Worker is running locally. The serve command watches for file changes, so you can edit main.ts and refresh to see updates.
Step 3: Configure .denoflare
To deploy, denoflare needs your Cloudflare account credentials. Create a .denoflare file in your project root:
{
"$schema": "https://raw.githubusercontent.com/skymethod/denoflare/v0.5.11/common/config.schema.json",
"scripts": {
"main": {
"path": "/absolute/path/to/main.ts",
"localPort": 8000
}
},
"profiles": {
"myprofile": {
"accountId": "abcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"apiToken": "abcxxxxxxxxx_-yyyyyyyyyyyy-11-dddddddd"
}
}
}Replace accountId and apiToken with your actual values. You can find your Account ID in the Cloudflare dashboard under Workers — it’s on the right side of the page. For the API token, go to Cloudflare API Tokens and create one using the “Edit Cloudflare Workers” template.
Also update the path field to point to your actual main.ts file. The absolute path matters — denoflare needs to know exactly where to find your code.
Step 4: Deploy to the Edge
With your config in place, deploying is a single command:
denoflare push maindenoflare will transpile your TypeScript, bundle it into a single JavaScript file, and upload it to Cloudflare’s edge network. Once it finishes, you’ll see your Worker listed in the Cloudflare dashboard under Workers & Pages.
Your Worker is now live on a *.workers.dev subdomain. You can also bind it to a custom domain if you have one configured in Cloudflare.
Step 5: Add Real Functionality
Let’s make the Worker do something useful. Here’s an example that returns different responses based on the request path:
export default {
fetch(request: Request): Response {
const url = new URL(request.url);
if (url.pathname === "/api/status") {
return Response.json({ status: "ok", runtime: "deno", timestamp: Date.now() });
}
if (url.pathname === "/api/echo") {
return Response.json({ method: request.method, headers: Object.fromEntries(request.headers) });
}
return new Response("Not found", { status: 404 });
},
};This Worker has three routes: /api/status returns a JSON health check, /api/echo returns the request method and headers, and everything else returns a 404. The Response.json() helper is a Deno API that sets the correct Content-Type header automatically.
Save the file, run denoflare serve main.ts again, and test the routes locally. When you’re happy with the behavior, push it live with denoflare push main.
What About Deno Deploy Users?
If you’re currently running apps on Deno Deploy, you have six months before the service shuts down. Cloudflare has said they’ll provide migration support for paying customers moving to Cloudflare Workers. The good news is that the Workers programming model is very similar to Deno Deploy’s — you’re still writing TypeScript, still exporting a fetch handler, still deploying to the edge.
The main difference is the tooling. Deno Deploy had its own CLI and configuration format. With Cloudflare Workers, you’ll use either Wrangler (the official CLI) or denoflare (for Deno-specific workflows). The code itself should port over with minimal changes.
Security Considerations
Before you deploy any Worker that handles real traffic, take a moment to think about security — the same mindset I apply when configuring SSH servers applies here too. If your Worker processes user input, validate it. If it makes requests to backend services, sanitize the URLs. And if it handles sensitive data, make sure your API tokens are stored as secrets in Cloudflare’s dashboard — not unlike the privacy controls we expect from AI assistants. — not hardcoded in your source files.
The open-source ecosystem has been dealing with an unprecedented wave of supply-chain attacks and AI-generated vulnerabilities. I wrote about how AI slop forced Google to freeze its open-source bug bounty program — it’s a sign of the times. Tools like Anthropic’s OSS scanner can help you catch vulnerabilities in your dependencies before they reach production.
Wrapping Up
The Cloudflare-Deno acquisition is a big deal for the JavaScript ecosystem, but it doesn’t change the fundamentals. You can still write TypeScript, deploy to the edge, and run code close to your users. The tooling is maturing, the documentation is solid, and the community is active.
Start with a simple Worker like the one in this tutorial. Get comfortable with the deploy loop — write, test locally, push live. Once that feels natural, explore Durable Objects for stateful edge computing, KV for fast key-value storage, and the rest of the Cloudflare platform.
The edge is the future of server-side JavaScript. And now, it’s Deno’s future too.