Deno Deploy[1] is the serverless-edge platform from the team that built Deno[2] (Ryan Dahl, after leaving Node.js): native TypeScript, standard Web APIs (Fetch, Web Crypto, WebSockets), and global deployment to ~35 regions. It competes directly with Cloudflare Workers. This is an honest look at what it offers, when it fits, and where it falls short.

Key takeaways

  • TypeScript runs without a transpile step; the runtime processes it directly.

  • Standard Web APIs (fetch, Request, Response, URL, crypto.subtle) replace Node’s proprietary APIs.

  • Deno KV is the integrated store providing persistence without an external DB for simple cases.

  • The ~50 ms cold start is roughly 10x greater than Cloudflare Workers (~5 ms).

  • Portability between Deno, Bun, and the browser is the differential advantage over Cloudflare’s richer ecosystem.

Deno Deploy philosophy

Four pillars:

  • First-class TypeScript: no transpile step, runtime executes TS directly.

  • Standard Web APIs: fetch, Response, Request, URL, crypto.subtle. No proprietary APIs.

  • Secure by default: explicit permissions, no arbitrary network/disk access.

  • ES modules: HTTP imports, npm (after Deno 2), or jsr: (JavaScript Registry).

Hello World and Deployment

// main.ts
Deno.serve((req: Request) => {
  const url = new URL(req.url);
  if (url.pathname === "/") {
    return new Response("Hi from Deno Deploy");
  }
  return new Response("Not found", { status: 404 });
});

Deploy with deployctl CLI:

deno install -Arf jsr:@deno/deployctl
deployctl deploy --project=my-app main.ts

Deno KV: persistent state

Deno KV is the integrated key-value store included with the platform. It replicates globally with eventual consistency and strong consistency per region, useful for avoiding an external DB. The lock-in is real: migrating heavily used Deno KV to another DB is work.

Web APIs instead of Node APIs

What can break compatibility with existing npm libraries:

  • Node’s fs → not available natively (use Deno.readFile).

  • Node’s http → use fetch and Deno.serve.

  • Node’s stream → Web Streams.

Deno 2 introduced better npm interop (via the npm: specifier), but Node-specific libraries remain incompatible. Libraries using only Web APIs (React Router, Hono, Zod, date-fns) work without changes. This restriction is the biggest barrier when migrating existing Express code.

Deno Deploy vs Cloudflare Workers

Aspect Deno Deploy Cloudflare Workers
Runtime Deno (V8) V8 isolates
Native TypeScript Yes Via wrangler
KV Deno KV (integrated) Workers KV
R2 / Objects N/A R2
D1 (SQL) N/A D1
Durable Objects N/A Yes
Regions ~35 300+
Entry price $0 free tier, $10/mo $0 free, $5/mo
Cold start ~50 ms ~1-5 ms
Ecosystem Emerging Large

Cloudflare has more infrastructure pieces. Deno Deploy is more focused on "excellent JS/TS runtime".

Where it fits

Good fits:

  • Lightweight multi-region API.

  • Fresh / Astro static SSR.

  • Small microservices with TypeScript focus.

  • Experimentation with standard Web APIs.

  • Project prioritising portability Deno ↔︎ Bun ↔︎ browser.

Less ideal:

  • Apps with complex state: storage offering more limited.

  • Heavy Node ecosystem: missing interop for complex packages.

  • Extreme volume with critical latency: Cloudflare has more PoPs.

Honest limitations

  • Young ecosystem: fewer plugins and examples than Cloudflare Workers.

  • Cold start 10x Workers: 50 ms vs 5 ms matters for latency-sensitive apps.

  • Fewer PoPs: ~35 vs Cloudflare’s 300+.

  • Deno KV lock-in: heavy usage makes migration to another DB expensive.

  • Telemetry is optional but worth reviewing the settings.

Conclusion

Deno Deploy is an edge-serverless platform coherent with Deno philosophy: TypeScript first, standard Web APIs, secure by default. For new projects not needing Cloudflare’s full stack, it is an elegant choice. For teams with existing Node investment, migration has real cost. Development pace is strong and Deno Deploy competes seriously with Workers on developer experience; the final choice comes down to how much Cloudflare infrastructure you need vs how much you value Deno ergonomics.

Frequently asked questions

Can I move an existing Express app to Deno Deploy without rewriting it?

Not without work: Deno Deploy relies on standard Web APIs instead of Node's: fs is not available natively (use Deno.readFile), http gives way to fetch and Deno.serve, and stream to Web Streams. Deno 2 improved npm interop through the npm: specifier, but Node-specific libraries remain incompatible. Libraries that only use Web APIs, such as React Router, Hono, Zod or date-fns, work unchanged. That restriction is the biggest barrier when migrating Express code.

How long is a Deno Deploy cold start compared with Cloudflare Workers?

Around 50 ms, versus roughly 1-5 ms on Cloudflare Workers, so about 10x longer. For a lightweight API or static SSR it rarely shows, but it matters for latency-sensitive apps. On top of that, Deno Deploy runs in ~35 regions while Cloudflare has 300+ PoPs, so for extreme volume with critical latency Workers keeps the edge.

Do I need an external database to keep state on Deno Deploy?

For simple cases, no: Deno KV is the key-value store built into the platform, replicating globally with eventual consistency and strong consistency per region. The cost is lock-in: if you use it heavily, migrating to another database later is real work. For apps with complex state the storage offering is more limited than Cloudflare's, which also has R2, D1 and Durable Objects.

Sources

  1. Deno Deploy
  2. Deno