Deno Deploy: TypeScript en el edge sin servidor

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

Filosofía de Deno Deploy

Los pilares:

• TypeScript first-class: sin transpile step, el runtime ejecuta TS directo.
• Web APIs estándar: fetch, Response, Request, URL, crypto.subtle. No APIs propietarias.
• Seguro por defecto: permisos explícitos, no acceso a red / 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.

Arquitectura

Deno Deploy ejecuta tu código en V8 isolates (como Workers), distribuidos en ~35 ubicaciones globales. El mismo isolate puede servir múltiples requests (warm). Cold start: ~50ms.

Plataformas subyacentes:

• Fly.io: partnership reciente para algunos casos.
• Deno Cloud: infraestructura propia en expansión.

Deno Deploy no es edge pesado — no puedes ejecutar workloads largos o binarios nativos. Es más “function handler por request” como Lambda/Workers.

Hello world

// 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 via GitHub Actions con deployment automático en cada push.

Deno KV: estado persistente

Una de las diferencias con Workers: Deno KV, un 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();

// 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 replica global con consistencia eventual, consistente fuerte por región. Útil para muchos casos sin necesidad de BD externa.

Web APIs en vez de Node APIs

Lo que rompe la compatibilidad con muchas libs de npm:

• 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 (packages with npm: specifier), pero libs Node-specific siguen incompatibles. Libs que usen solo Web APIs (React Router, Hono, Zod, date-fns) funcionan sin cambios.

Frameworks sobre Deno Deploy

Modernos framework-compatibles:

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

Hono es probablemente la elección más práctica si quieres code portable entre edge runtimes.

Deno Deploy vs Cloudflare Workers

Comparación honesta:

Cloudflare tiene más piezas de infraestructura. Deno Deploy es más enfocado en “runtime JS/TS excelente”.

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: la oferta de storage es más limitada.
• Ecosistema heavy Node: falta interop para packages complicadas.
• Volumen extremo con latencia crítica: Cloudflare tiene más PoPs.

Precios

• Free: 100k requests/día, 100GB-hours compute.
• Pro: $10/mes + overage usage.
• Enterprise: custom.

Para proyectos pequeños, el free tier cubre bien. Para volumen, el pricing es competitivo pero no el más barato.

Limitaciones

Ser honesto:

• Ecosistema joven: menos plugins y ejemplos que Workers.
• Cold start 10x Workers: 50ms vs 5ms. Para apps ultra-sensibles importa.
• Pocos PoPs comparativamente.
• Tier gratuito generoso pero con límites.
• Lock-in en Deno KV si lo usas mucho: migrar a otra BD es trabajo.

Deno Deploy Playground

Un diferenciador: Deploy Playground — editor web donde puedes escribir código Deno y desplegarlo al instante globalmente. Útil para:

• Compartir demos rápidos.
• Experimentar APIs.
• Lanzar webhooks ad-hoc.
• Prototipos de fin de semana.

No reemplaza a un IDE, pero acelera iteración.

Migración desde Node / Express

Migrar una app Express a Deno Deploy no es mecánico:

• Express usa APIs Node → tienes que reescribir.
• Alternativa: usar Hono, que funciona en Deno, y portar primero a Hono en Node, luego a Deno Deploy.
• Packages: muchos funcionan con npm: specifier.
• BD: si usas Postgres, libs como deno-postgres reemplazan pg.

Proyecto pequeño: 1-2 días. Proyecto mediano: semanas.

Seguridad

Deno Deploy hereda el modelo de Deno:

• Sin acceso a sistemas de archivos por defecto.
• Sin permisos de red arbitraria.
• Sandbox de V8 a prueba de escapes.
• Secrets via env vars gestionados.

Auditabilidad y simplicidad superior a Node.

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 (R2, D1, Durable Objects), es una elección elegante. Para equipos con inversión Node existente, la migración tiene coste. El ritmo de desarrollo es fuerte — Deno Deploy compite seriamente con Workers en DX y propuesta. La elección final depende de cuánto del ecosistema Cloudflare necesitas vs cuánto valoras la ergonomía Deno.

Síguenos en jacar.es para más sobre edge computing, serverless y runtimes JavaScript.