Deno Deploy: TypeScript en el edge sin servidor

Actualizado: 2026-05-03

Deno Deploy^[1] es la plataforma serverless-edge del equipo que construyó Deno^[2] (Ryan Dahl, tras dejar Node.js): TypeScript nativo, Web APIs estándar (Fetch, Web Crypto, WebSockets) y despliegue global a ~35 regiones. Compite directamente con Cloudflare Workers. Esta es una mirada honesta a qué aporta, cuándo tiene sentido y qué le falta.

Puntos clave

• TypeScript se ejecuta sin transpile step; el runtime lo procesa directamente.
• Las Web APIs estándar (fetch, Request, Response, URL, crypto.subtle) reemplazan a las APIs propietarias de Node.
• Deno KV es el store integrado que da persistencia sin BD externa para casos simples.
• El cold start de ~50ms es unas 10 veces mayor que el de Cloudflare Workers (~5ms).
• La portabilidad entre Deno, Bun y browser es la ventaja diferencial frente al ecosistema más rico de Cloudflare.

Filosofía de Deno Deploy

Los cuatro pilares:

• TypeScript first-class: sin transpile step, el runtime ejecuta TS directo.
• Web APIs estándar: fetch, Response, Request, URL, crypto.subtle. Sin APIs propietarias.
• Seguro por defecto: permisos explícitos, sin acceso a red o disco arbitrario.
• ES modules: imports HTTP, npm (tras Deno 2), o jsr: (JavaScript Registry).

El contraste con Node es intencional: recuperar lo que Dahl considera errores del diseño original de Node. Conecta directamente con la filosofía de TypeScript 5.4 de hacer el lenguaje más expresivo y menos dependiente de workarounds heredados.

Hello world y despliegue

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

Deploy con el CLI deployctl:

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

O vía GitHub Actions con deployment automático en cada push.

Deno KV: estado persistente

Deno KV es el key-value store integrado que viene con la plataforma:

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();

KV replica globalmente con consistencia eventual y consistencia fuerte por región. Útil para muchos casos sin necesidad de BD externa. El lock-in es real: si lo usas intensivamente, migrar a otra BD es trabajo.

Web APIs en vez de Node APIs

Lo que puede romper la compatibilidad con libs npm existentes:

• fs de Node → no existe nativo (usar Deno.readFile).
• http de Node → usar fetch y Deno.serve.
• stream de Node → Web Streams.

Deno 2 introdujo mejor interop con npm (npm: specifier), pero libs Node-específicas siguen incompatibles. Libs que usen solo Web APIs (React Router, Hono, Zod, date-fns) funcionan sin cambios. Esta restricción es el mayor obstáculo para migrar código Express existente.

Deno Deploy vs Cloudflare Workers

Comparación honesta:

Cloudflare tiene más piezas de infraestructura. Deno Deploy está más enfocado en “runtime JS/TS excelente”. Para proyectos que necesitan el ecosistema completo de Cloudflare (R2, D1, Durable Objects), Cloudflare Workers sigue siendo la elección. Para proyectos que priorizan portabilidad y ergonomía TypeScript, Deno Deploy es elegante. Otra alternativa madura de edge es Fastly Compute.

Casos donde encaja

Buenos fits:

• API ligera multi-región.
• SSR de sitio estático Fresh / Astro.
• Microservices pequeños con foco TypeScript.
• Experimentación con Web APIs estándar.
• Proyecto que prioriza portabilidad Deno ↔︎ Bun ↔︎ browser.

Menos ideal:

• Apps con mucho estado complejo: oferta de storage más limitada que Cloudflare.
• Ecosistema heavy Node: falta interop para packages complicados.
• Volumen extremo con latencia crítica: Cloudflare tiene más PoPs.

Limitaciones honestas

• Ecosistema joven: menos plugins y ejemplos que Workers.
• Cold start 10x Workers: 50ms vs 5ms. Para apps ultra-sensibles importa.
• Pocos PoPs comparativamente.
• Lock-in en Deno KV si lo usas mucho.
• Telemetría opcional pero vale la pena verificar los settings.

Conclusión

Deno Deploy es una plataforma edge-serverless coherente con la filosofía Deno: TypeScript first, Web APIs estándar, seguro por defecto. Para proyectos nuevos que no necesitan el ecosistema complejo de Cloudflare, es una elección elegante. Para equipos con inversión Node existente, la migración tiene coste real. El ritmo de desarrollo es fuerte y Deno Deploy compite seriamente con Workers en DX; la elección final depende de cuánto del ecosistema Cloudflare necesitas frente a cuánto valoras la ergonomía Deno.

1. Deno Deploy
2. Deno