Deno Deploy: TypeScript at the Edge Without a Server

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

Deno Deploy Philosophy

The 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).

The contrast with Node is intentional: recover what Dahl considers Node’s design errors.

Architecture

Deno Deploy runs your code in V8 isolates (like Workers), distributed across ~35 global locations. The same isolate can serve multiple warm requests. Cold start: ~50ms.

Underlying platforms:

• Fly.io: recent partnership for some cases.
• Deno Cloud: own infrastructure expanding.

Deno Deploy isn’t heavy edge — you can’t run long workloads or native binaries. More “function handler per request” like Lambda/Workers.

Hello World

// 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

Or via GitHub Actions with automatic deployment on each push.

Deno KV: Persistent State

One difference with Workers: Deno KV, an integrated key-value store included with the platform:

const kv = await Deno.openKv();

// Write
await kv.set(["users", "123"], { name: "Ana", email: "ana@ex.com" });

// Read
const user = await kv.get(["users", "123"]);

// Atomic transactions
await kv.atomic()
  .check({ key: ["counter"], versionstamp: null })
  .set(["counter"], 1)
  .commit();

// Queue messages (durable)
await kv.enqueue({ type: "email", to: "ana@ex.com" });

// Real-time watches
for await (const entry of kv.watch([["users", "123"]])) {
  console.log(entry);
}

KV globally replicates with eventual consistency, strong per-region. Useful for many cases without external DB.

Web APIs Instead of Node APIs

What breaks compatibility with many npm libs:

• Node fs → no native (use Deno.readFile).
• Node http → use fetch and Deno.serve.
• Node stream → Web Streams.

Deno 2 introduced better npm interop (packages with npm: specifier), but Node-specific libs remain incompatible. Libs using only Web APIs (React Router, Hono, Zod, date-fns) work without changes.

Frameworks on Deno Deploy

Modern framework-compatible:

• Fresh: Deno’s own web framework, islands architecture.
• Hono: multi-runtime micro-framework (Deno, Bun, Workers, Node).
• Oak: middleware-style, Express-like.
• React Router v7 / Remix: via adapters.
• Astro: via Deno adapter.

Hono is probably the most practical choice for portable code between edge runtimes.

Deno Deploy vs Cloudflare Workers

Honest comparison:

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.

Pricing

• Free: 100k requests/day, 100GB-hours compute.
• Pro: $10/mo + usage overage.
• Enterprise: custom.

For small projects, free tier covers well. For volume, pricing is competitive but not cheapest.

Limitations

Honestly:

• Young ecosystem: fewer plugins and examples than Workers.
• 10x cold start vs Workers: 50ms vs 5ms. For ultra-sensitive apps it matters.
• Few PoPs relatively.
• Generous free tier but with limits.
• Deno KV lock-in if you use it heavily: migrating to another DB is work.

Deno Deploy Playground

A differentiator: Deploy Playground — web editor to write Deno code and deploy globally instantly. Useful for:

• Quick demo sharing.
• API experimentation.
• Ad-hoc webhooks.
• Weekend prototypes.

Doesn’t replace an IDE, but accelerates iteration.

Migrating from Node / Express

Migrating an Express app to Deno Deploy isn’t mechanical:

• Express uses Node APIs → rewrite required.
• Alternative: use Hono, which works in Deno, port first to Hono on Node, then Deno Deploy.
• Packages: many work with npm: specifier.
• DB: if using Postgres, libs like deno-postgres replace pg.

Small project: 1-2 days. Mid-size: weeks.

Security

Deno Deploy inherits Deno’s model:

• No filesystem access by default.
• No arbitrary network permissions.
• V8 escape-proof sandbox.
• Managed secrets via env vars.

Auditability and simplicity superior to Node.

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 complex ecosystem (R2, D1, Durable Objects), it’s an elegant choice. For teams with existing Node investment, migration has cost. Development pace is strong — Deno Deploy competes seriously with Workers on DX and proposition. Final choice depends on how much Cloudflare ecosystem you need vs how much you value Deno ergonomics.

Follow us on jacar.es for more on edge computing, serverless, and JavaScript runtimes.