Deno anuncia su incorporación a Cloudflare, un año de soporte para el runtime y seis meses de transición para Deploy. Explicamos qué implica.
Un cambio que afecta al software y al servicio de alojamiento
El equipo de Deno anunció el 9 de octubre de 2026 su incorporación a Cloudflare. La noticia tiene una consecuencia inmediata para quienes desarrollan con este entorno de JavaScript y TypeScript: hay un calendario de transición para sus productos. Conviene leerlo antes de interpretar la operación como una simple ampliación del equipo de Cloudflare.
Según el comunicado de Ryan Dahl, el runtime recibirá durante otro año versiones mensuales con correcciones y actualizaciones de seguridad. Después, el equipo dejará su desarrollo. Deno conservará su condición de código abierto. Deno Deploy continuará funcionando seis meses antes de cerrar, con ayuda de migración para clientes de pago que pasen a Workers. JSR seguirá operativo y trasladará su infraestructura a Cloudflare. También continuará el apoyo a rusty_v8.
Estas decisiones afectan a componentes distintos. El runtime es el programa que ejecuta el código; Deploy es un servicio que lo aloja; y JSR distribuye paquetes. Por eso, que un servicio tenga una fecha de cierre no equivale a que todas las aplicaciones escritas con ese lenguaje desaparezcan ese día. Lo que cada proyecto necesita revisar es qué piezas utiliza y quién se encargará de mantenerlas.
Por qué aparecen Workers, workerd y celld
Cloudflare explica que el trabajo común busca facilitar el alojamiento de Workers y Durable Objects en infraestructura propia. En ese contexto aparecen dos nombres: workerd, el runtime abierto de Workers, y celld, el proyecto de Deno orientado a operar aplicaciones distribuidas. La unión pretende acercar el modelo de programación de Workers a equipos que quieren administrarlo fuera de la red de Cloudflare.
El punto de partida es un problema habitual de las aplicaciones conectadas. Una demostración puede funcionar en un único servidor, pero un servicio que crece necesita distribuir trabajo, mantener datos y coordinar conexiones. La complejidad surge cuando cada una de esas tareas requiere su propio sistema, su configuración y su operación diaria. El objetivo anunciado es ofrecer piezas que encajen entre sí desde el diseño.
Qué aporta un Durable Object, explicado con un ejemplo
La documentación oficial describe los Durable Objects como unidades que combinan ejecución y estado, con identidad propia y almacenamiento persistente. Permiten coordinar a varios clientes que necesitan compartir una misma situación: por ejemplo, las personas conectadas a una sala de chat. Su utilidad está en reunir esa coordinación en un lugar identificable, en vez de repartirla entre múltiples procesos que deban ponerse de acuerdo continuamente.
Imaginemos una aplicación con cuatro salas independientes. Cada sala puede tener su objeto y sus datos. Quien entra en la sala A se comunica con el objeto A; quien entra en la B, con el B. El esquema ayuda a comprender cómo repartir el servicio por unidades de trabajo. No describe la arquitectura obligatoria de todos los chats, ni garantiza que cualquier proyecto escale automáticamente: el diseño de mensajes, permisos y datos sigue importando.
Alojarlo por cuenta propia también exige operación
Poder ejecutar un runtime fuera de una plataforma no significa disponer de todos los servicios que esa plataforma ofrece. Hay que organizar almacenamiento, copias, supervisión y recuperación ante fallos. Precisamente esa distancia entre publicar código y ofrecer una experiencia completa es parte del problema que Cloudflare reconoce en su anuncio. El trabajo sobre alojamiento propio debe juzgarse por las herramientas y compatibilidades que vaya entregando.
Para entenderlo, pensemos en un webmaster que guarda conversaciones y archivos. El programa puede arrancar en otra máquina y, aun así, necesitar una migración de datos y cambios de configuración. Una prueba útil consiste en reproducir el flujo completo: entrar, recuperar información, modificarla y volver a leerla después de reiniciar. Ese ejemplo muestra por qué cambiar el ejecutor y cambiar el servicio son tareas relacionadas, pero diferentes.
Cómo leer la noticia si ya tienes un proyecto
Nuestra lectura práctica es empezar por un inventario: runtime utilizado, servicio de despliegue, paquetes y almacenamiento. Después conviene separar las decisiones urgentes de las que admiten evaluación. Quien dependa de Deploy necesita planificar su transición dentro del periodo anunciado; quien ejecute Deno en sus propios equipos debe valorar cómo cubrirá el mantenimiento futuro. El código abierto facilita que otros puedan continuar el trabajo, pero no establece por sí mismo un compromiso de soporte de un nuevo responsable.
En una migración, el criterio útil es comprobar comportamientos: permisos, conexiones, tareas programadas y conservación de datos. También hay que revisar qué ofrece realmente la alternativa en el plan elegido. Estos son criterios generales de evaluación, no condiciones nuevas impuestas por Deno ni una promesa de que todas las aplicaciones puedan trasladarse sin modificaciones.
La incorporación abre una dirección técnica interesante para aplicaciones distribuidas y agentes con estado persistente. Para los usuarios actuales, lo esencial es el calendario concreto publicado y las funciones que utilizan hoy. La intención de simplificar el futuro no elimina la necesidad de preparar la transición de los servicios existentes.