Deno se une a Cloudflare y la noticia va bastante más allá de un cambio de oficinas o de inversores. El equipo completo que desarrolla Deno trabajará dentro de Cloudflare, Deno Deploy cerrará dentro de seis meses y el runtime independiente recibirá actualizaciones mensuales durante un año antes de que ese equipo deje de desarrollarlo. Para quien tenga una aplicación en producción, son dos relojes distintos y conviene no confundirlos.
El anuncio se publicó el 9 de octubre de 2026 en los blogs oficiales de ambas compañías. No presenta todavía un sustituto automático ni una migración de un clic. Lo que sí fija es la dirección: combinar celld, el proyecto distribuido de Deno, con workerd, el runtime abierto de Cloudflare Workers, para llevar el modelo de Workers y Durable Objects también a infraestructura propia.
Qué cambia realmente cuando Deno se une a Cloudflare
La explicación oficial de Deno separa el futuro del ecosistema en cuatro piezas. El runtime Deno seguirá recibiendo correcciones de errores y seguridad cada mes durante doce meses. Después continuará siendo código abierto, pero el actual equipo dejará de impulsar su desarrollo. Que otra comunidad lo mantenga es posible, aunque hoy no hay una gobernanza sucesora anunciada.
Deno Deploy tiene un plazo más corto: funcionará seis meses más y después se apagará. Los clientes de pago recibirán ayuda para trasladarse a Cloudflare Workers. La compañía no promete en el anuncio la misma asistencia para cuentas gratuitas, así que no conviene darla por hecha.
JSR, el registro de paquetes orientado a JavaScript y TypeScript, seguirá operativo y su infraestructura pasará a Cloudflare. También continuará el soporte de rusty_v8, con la intención de integrarlo en workerd. En otras palabras, no desaparecen todas las piezas de Deno a la vez: se conserva parte del trabajo, mientras el foco comercial y técnico cambia de plataforma.
Deno Deploy exige actuar antes que el runtime
Si tu proyecto usa el ejecutable de Deno en un servidor propio, un contenedor o una máquina virtual, no tiene el mismo problema inmediato que una aplicación alojada en Deploy. El software no dejará de arrancar al cumplirse el año. El riesgo es otro: a partir de entonces ya no habrá compromiso del equipo actual con nuevos parches, compatibilidad o evolución.
En cambio, una aplicación en Deno Deploy sí depende de un servicio con cierre anunciado. Ahí la prioridad es preparar un inventario antes de tocar código:
- rutas, variables, secretos y dominios asociados al despliegue;
- uso de KV, colas, cron, bases de datos o almacenamiento persistente;
- APIs específicas de Deno y permisos del runtime;
- límites de CPU, memoria, red y WebSockets que afecten al comportamiento;
- pipeline de pruebas, publicación y reversión.
El destino obvio es Workers porque es la ruta que ofrecerá el proveedor a clientes de pago, pero no debe tratarse como una equivalencia perfecta antes de probarla. La aplicación puede compartir estándares web y buena parte de su código, mientras que el almacenamiento, la observabilidad o la forma de desplegar cambian. La decisión sensata es montar una réplica pequeña, ejecutar las pruebas críticas y medir las diferencias antes de mover tráfico.
Qué persigue Cloudflare con celld y workerd
La versión conjunta publicada por Cloudflare explica el objetivo con bastante claridad: fusionar el trabajo de celld y workerd para que el modelo de Workers y Durable Objects pueda ejecutarse con más facilidad fuera de la red de Cloudflare. La promesa interesante no es solo ejecutar JavaScript, sino unir cómputo, estado, comunicación y escalado en una abstracción más sencilla.
Durable Objects asigna a cada objeto una identidad estable, ejecución de un solo hilo y almacenamiento local. Eso encaja con salas de chat, sesiones colaborativas, coordinación en tiempo real o agentes de IA que necesitan conservar estado. Celld nació para llevar una idea parecida a entornos autogestionados. La unión de ambos equipos puede reducir duplicidades, pero el anuncio no aporta todavía una versión final, una fecha de disponibilidad ni una tabla de compatibilidad.
Ese matiz importa. Deno se une a Cloudflare con un plan de producto, no con una plataforma terminada que sustituya hoy a Deno Deploy. Si un proyecto está en producción, debe migrar según las capacidades disponibles y verificadas, no según lo que quizá llegue después.
Una lista práctica para decidir sin precipitarse
Para equipos que ya usan Deno, el primer paso es identificar de qué Deno dependen. Si solo consumen paquetes publicados en JSR, el anuncio no exige una reescritura. Si ejecutan el runtime en infraestructura propia, tienen margen para fijar versiones, revisar dependencias y estudiar alternativas. Si alojan en Deploy, el calendario de seis meses manda.
También conviene separar portabilidad y comodidad. Workers puede ser la transición con menos fricción, sobre todo si la aplicación ya se apoya en APIs web. Node.js o Bun pueden tener sentido cuando la prioridad sea evitar una dependencia fuerte del proveedor, pero una migración de runtime implica revisar permisos, módulos nativos, resolución de paquetes y comportamiento en producción.
Antes de decidir, resulta útil convertir la migración en una revisión técnica acotada: registrar las rutas críticas, crear pruebas que reproduzcan el tráfico real y definir cómo volver atrás. Es la misma disciplina que ayuda a evaluar herramientas nuevas en eventos como DevFest 2026 o a interpretar benchmarks como ReviewBench para revisión de código: primero se comprueba qué mide y qué resuelve; después se adopta.
Nuestra lectura: continuidad de ideas, ruptura del producto
La operación tiene una lógica técnica reconocible. Deno llevaba tiempo intentando simplificar no solo el runtime, sino la infraestructura distribuida que rodea a una aplicación. Cloudflare ya dispone de red, Workers, Durable Objects y un runtime abierto. Juntar los equipos evita mantener dos caminos paralelos y concentra el trabajo en una plataforma con más alcance.
Para la comunidad, sin embargo, el coste es real. Deno Deploy tiene fecha de salida y el runtime pierde dentro de un año el respaldo directo de quienes lo crearon. El código abierto permite continuidad, pero no la garantiza por sí solo. Faltan detalles sobre gobernanza, mantenedores, financiación y compatibilidad futura.
La conclusión práctica es sencilla: Deno se une a Cloudflare, pero no todo Deno desaparece ni todo se conserva. Los usuarios de Deploy deben empezar la migración; quienes usan el runtime pueden evaluar con más calma; y quienes dependen de JSR deberían vigilar el traslado sin asumir un cierre. Dos calendarios, tres riesgos distintos y una plataforma futura que aún tiene que demostrar su compatibilidad.
Transparencia editorial: este artículo se basa en los anuncios oficiales de Deno y Cloudflare publicados el 9 de octubre de 2026. No contiene enlaces de afiliado ni afirma pruebas propias de las plataformas.
