En 2018, Ryan Dahl subió a un escenario y dio en la JSConf EU una charla titulada "10 Things I Regret About Node.js". Al final presentó la respuesta a esos arrepentimientos. Se llamaba Deno.
Deno es un runtime open source de JavaScript y TypeScript, escrito en Rust sobre V8, que Ryan Dahl presentó en 2018 como alternativa a Node.js.
Ocho años después, el 9 de octubre de 2026, el mismo Ryan Dahl firma otro post. Esta vez se titula "Deno is joining Cloudflare". Cloudflare compra Deno, el equipo entero se va con ellos y el runtime tiene fecha de fin de desarrollo.
Si tienes algo corriendo en Deno, la pregunta no es si es una buena noticia para la industria. La pregunta es qué haces el lunes.
En corto: Cloudflare compra Deno e incorpora a todo su equipo. El runtime recibirá un año de parches de seguridad y bugs, y después Deno dejará de desarrollarlo; Deno Deploy cierra en unos 6 meses. Lo que Cloudflare compra de verdad es el equipo y celld, el modelo para que Workers y Durable Objects se puedan alojar en tu propia infraestructura con workerd.
¿Qué anuncia exactamente Cloudflare al comprar Deno?
La operación es una incorporación del equipo de Deno a Cloudflare con fin programado del runtime: un año de mantenimiento, cierre de Deno Deploy a los 6 meses y fusión de su tecnología de self-hosting (celld) en workerd, el runtime open source de Workers.
La frase clave del anuncio de Deno es esta, literal:
"We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development."
El post de Cloudflare, firmado por Ryan Dahl y Kenton Varda, cuenta la otra mitad: "We're joining Cloudflare to make the Workers programming model a mainstream way to build servers." El esfuerzo pasa de un runtime y un hosting propios al modelo de Workers.
Las condiciones económicas no se han publicado. Con su Serie A de 2022, Deno había levantado 26 millones de dólares en total, según TechCrunch.
Qué pasa con cada pieza: runtime, Deno Deploy, JSR, celld y workerd
Cada pieza tiene un destino distinto. Esto dice el anuncio y esto haría yo:
| Pieza | Estado según el anuncio | Plazo aproximado | Qué hacer | Riesgo |
|---|---|---|---|---|
| Runtime Deno | Releases mensuales de bugs y seguridad, luego fin del desarrollo | Unos 12 meses (hasta ~octubre 2027) | Inventariar usos de Deno.* y planificar |
Medio: sin parches tras el año salvo fork |
| Deno Deploy | Sigue operando y luego cierra | Unos 6 meses (hasta ~abril 2027) | Migrar ya; los clientes de pago tienen ayuda para ir a Workers | Alto: es el plazo más corto |
| JSR | Sigue funcionando; su infraestructura pasa a Cloudflare | Sin fecha de cierre | Seguir publicando, vigilar cambios | Bajo a corto plazo |
| celld | Su código e ideas se fusionan en workerd | "In the coming months" | No construir nada nuevo encima de celld suelto | Medio: API en transición |
| workerd | Pasa a ser la apuesta de self-hosting de primera clase | Más anuncios en los próximos meses | Probarlo hoy en local | Bajo: es el código que Cloudflare corre en producción |
El plazo que manda es el de Deno Deploy: seis meses pasan rápido si tienes que tocar dominios, secretos y observabilidad.
¿Qué es celld y por qué es lo que Cloudflare quería?
celld es una implementación open source de Workers y Durable Objects, compatible con la de Cloudflare, pensada para alojarla tú mismo y escalar. Deno la lanzó en agosto de 2026.
Cloudflare la describe así: "one binary, written in Rust, with object storage as its only external service dependency". Un binario. Una sola dependencia externa, un bucket de object storage. Varias instancias de celld apuntan al mismo bucket y se coordinan entre ellas.
Un Durable Object es un singleton distribuido con su propia base SQLite, que ejecuta en un solo hilo, puede mantener WebSockets y se direcciona de forma individual. Es la pieza que convierte Workers en algo más que funciones sin estado.
Ese es el agujero que celld tapa. workerd implementa hoy los Durable Objects solo como instancia única: sirve para tests en local, pero no escala. Y el routing de producción de Cloudflare es demasiado pesado para alojarlo en tus servidores.
Ryan Dahl y Bert Belder liderarán ahora el trabajo para "make workerd self-hosting a first-class supported way to build and run apps". Lo resumió el propio Kenton Varda en Hacker News: el plan es fusionar celld con workerd para tener un único runtime open source y alojable para Workers y Durable Objects.
Mi tesis: Deno no muere como código, muere como apuesta
El código de Deno no desaparece. Lo que desaparece es la apuesta de que un runtime independiente, con su propio hosting, podía sostenerse como negocio frente a Node.
Cuando Cloudflare compra Deno, no compra un runtime. Compra al equipo que ya resolvió el problema más incómodo de su plataforma: que nadie podía ejecutar Workers con Durable Objects fuera de Cloudflare de forma seria.
Eso es un arma directa contra el argumento del lock-in. Cloudflare rechaza esa teoría y asegura tener ex-clientes que migraron fuera usando workerd. Si celld entra en workerd, ese argumento se vuelve mucho más fácil de demostrar.
El usuario ryanrasti lo resume bien en el hilo: lo interesante no es el cierre, sino llevar el modelo de celld a workerd, porque apoyar la durabilidad y la coordinación sobre object storage simplifica mucho el self-hosting.
Cómo reaccionó la comunidad
El hilo de Hacker News superó los 1.300 puntos y los 680 comentarios.
bennett_dev expresa lo que muchos sienten: le deja un sabor amargo que Ryan Dahl empujara tanto Deno y Deno Deploy durante años para dejarlos morir en un año y seis meses respectivamente.
sholladay dice que lo vio venir cuando Deno priorizó la compatibilidad con npm, y apunta el lado bueno: Node copió funciones de Deno.
Y gen2brain hace la pregunta que importa: si empiezo un proyecto nuevo de JavaScript o TypeScript, ¿qué elijo y por qué?
Con Bun adquirido por Anthropic en diciembre de 2025 y Deno camino de Cloudflare, los dos runtimes alternativos a Node ya pertenecen a empresas con su propia agenda.
Migrar de Deno: qué hacer según tu caso
No es lo mismo tener una API en Deno Deploy que usar deno fmt en un repo.
| Tu caso | Urgencia | Qué haría |
|---|---|---|
| App en Deno Deploy | Alta (~6 meses) | Migrar este trimestre. Si pagas, pide la ayuda de migración a Workers; si no, evalúa Workers o un contenedor con Node |
| Runtime Deno en producción, otro hosting | Media (~12 meses) | Aislar Deno.* detrás de interfaces y probar el código en Node o workerd |
| Deno solo como tooling o scripts | Baja | Seguir usándolo; planificar reemplazo antes de que falten parches |
| Publicas paquetes en JSR | Baja | Seguir publicando; JSR continúa y su infraestructura pasa a Cloudflare |
| Proyecto nuevo | Decisión de arquitectura | Escribir sobre Web APIs estándar y no atarte a ningún runtime |
Cuanto menos dependas de APIs propietarias del runtime, más barata sale la migración. Haz un inventario: busca Deno. en tu código y cuenta las llamadas (ficheros, entorno, KV, permisos). Ese número es el coste real de tu migración. Si es alto, mete esas llamadas detrás de una interfaz propia. Escribir primero el contrato y después la implementación es la idea central del libro de Spec-Driven Development, y aquí se aplica tal cual: define qué necesita tu app del runtime antes de elegir runtime.
Código portable: el mismo handler en Deno, Workers y Node
Separa tu lógica del punto de entrada. Si tu handler recibe un Request y devuelve un Response, ya hablas el idioma común de Deno, Workers y Bun; en Node solo te falta un adaptador.
// handler.ts — solo Web APIs estándar
export async function handle(request: Request): Promise<Response> {
const url = new URL(request.url);
if (url.pathname === "/health") {
return Response.json({ ok: true });
}
return new Response("Not found", { status: 404 });
}
En Deno, el punto de entrada es una línea:
// main.deno.ts
import { handle } from "./handler.ts";
Deno.serve(handle);
En Cloudflare Workers (y en workerd), el equivalente es un módulo con fetch:
// worker.ts
import { handle } from "./handler.ts";
export default {
async fetch(request: Request, env: unknown, ctx: ExecutionContext): Promise<Response> {
return handle(request);
},
};
El tipo ExecutionContext viene de @cloudflare/workers-types. handler.ts no cambia: solo migras el fichero de entrada.
En Node necesitas un adaptador, porque node:http no habla Request/Response. Con @hono/node-server es una línea:
// main.node.ts
import { serve } from "@hono/node-server";
import { handle } from "./handler.ts";
serve({ fetch: handle, port: 3000 });
Si quieres routing y middleware sin perder portabilidad, Hono corre en Deno, Bun, Node y Workers con el mismo código. Y si te planteas Bun como destino, aquí analizo cuándo Bun reemplaza a Node en backend con TypeScript.
Una cosa más: en el borde del runtime es donde entran datos que no controlas. Validar el request.json() con un schema te protege cambies de plataforma o no; es justo lo que trabajamos en el curso de Zod.
Lo que todavía no sabemos
Primero, el anuncio no menciona Fresh ni Deno KV. No sabemos qué pasará con ellos. Si tu app depende de Deno KV en Deno Deploy, es la incógnita más grave que tienes, y no tiene respuesta pública todavía.
Segundo, el fork comunitario es hipotético: hoy no hay ningún proyecto anunciado. Mantener un runtime con V8 y Rust exige un equipo, no un par de voluntarios.
Tercero, los plazos los fija Cloudflare. Seis meses y un año es lo que dice el anuncio del 9 de octubre de 2026. Pueden cambiar, y las fechas exactas de cierre no están publicadas.
Cuarto, la fusión de celld con workerd todavía no existe. Cloudflare promete más anuncios "in the coming months". Hasta entonces, el self-hosting serio de Durable Objects es una promesa, no un producto.
Quinto, el handler portable no resuelve los bindings. Durable Objects, Deno KV o el modelo de permisos de Deno no tienen equivalente estándar: ahí migrar es reescribir, no cambiar el fichero de entrada.
Qué hacer hoy
Si estás en Deno Deploy, pon la migración en el roadmap de este trimestre. Si no, aísla las APIs del runtime y deja tu lógica sobre Request y Response. La lección de esta compra no es "elige el runtime correcto". Es que tu código no debería saber en qué runtime corre.
Si estás construyendo producto con agentes de IA y quieres que el código generado respete esa separación desde el principio, es justo el enfoque del curso Construye con IA.
Preguntas frecuentes
¿Por qué Cloudflare compra Deno?
Por el equipo y por celld. Ryan Dahl y Bert Belder liderarán el trabajo para que alojar workerd en tu propia infraestructura sea una forma de primera clase de ejecutar Workers y Durable Objects, fusionando celld en workerd. Las condiciones económicas de la compra no se han publicado.
¿Deno va a desaparecer?
No como código. Deno seguirá siendo open source y recibirá releases mensuales con correcciones y parches de seguridad durante un año. Después, el equipo original dejará de desarrollarlo. Su continuidad dependerá de que alguien lo mantenga.
¿Cuándo cierra Deno Deploy?
Según el anuncio del 9 de octubre de 2026, Deno Deploy seguirá operando unos 6 meses y después cerrará, lo que sitúa el cierre alrededor de abril de 2027. Los clientes de pago que migren a Cloudflare Workers recibirán ayuda de migración.
¿Qué pasa con JSR?
JSR sigue funcionando. Su infraestructura se traslada a Cloudflare. El anuncio no fija fecha de cierre, así que puedes seguir publicando paquetes.
¿Qué es celld?
celld es una implementación open source de Workers y Durable Objects, compatible con la de Cloudflare y pensada para self-hosting. Es un único binario en Rust cuya única dependencia externa es un object storage. Su código e ideas se fusionarán en workerd.
¿Debo migrar a Node o a Bun?
Depende de tu caso. Si estás en Deno Deploy, migra pronto. Si usas el runtime en tu propia infraestructura, tienes un año de parches. Si escribes sobre Web APIs estándar, el destino (Node, Bun o Workers) cambia poco tu código.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
Leave a Reply