Deno anunció el 9 de octubre de 2026 su incorporación a Cloudflare. Su anuncio original distingue los calendarios del runtime y de Deploy. Para quienes ejecutan herramientas o agentes, esa diferencia determina qué dependencia revisar primero.
La pista llegó a nuestro radar a través de Simon Willison; contrastamos los plazos en la fuente original. Publicamos hoy sobre un anuncio de ayer, no sobre una interrupción ocurrida esta mañana.
Tres dependencias que conviene distinguir
El runtime ejecuta JavaScript y TypeScript. Su equipo mantendrá correcciones mensuales de errores y seguridad un año; después dejará de desarrollarlo. Seguirá abierto, sin garantía de un nuevo mantenedor.
Deno Deploy, el alojamiento, continuará seis meses antes de cerrar. La ayuda anunciada para migrar a Workers se dirige a clientes de pago; no conviene asumir otras coberturas.
JSR, el registro de paquetes, seguirá operando en infraestructura de Cloudflare. Esto no prolonga por sí mismo runtime ni alojamiento.
Son plazos relativos al anuncio, sin día exacto de cierre de Deploy. No deben extrapolarse a Sandbox, Subhosting o Fresh.
Un agente puede depender de más de una capa
Imaginemos un equipo con una herramienta del Protocolo de Contexto de Modelos, MCP, ejecutada con Deno y un panel de seguimiento alojado en Deploy. Es un ejemplo hipotético, no una integración probada por Puntoes. El panel necesita un plan de alojamiento dentro del horizonte de seis meses; la herramienta requiere valorar su mantenimiento más allá del año anunciado. Compartir proveedor no convierte esos trabajos en una sola migración.
Como primer paso, recomendamos inventariar dónde se ejecuta el código, dónde se guarda el estado y qué paquetes se obtienen de JSR. Después, identificar dependencias específicas del runtime: permisos de archivos y red, interfaces de programación propias y tareas que no se puedan trasladar sin adaptación.
Antes de sustituir un componente, sería útil ensayar un flujo conocido y comprobar que los accesos permitidos y denegados siguen comportándose como se esperaba. Para un panel con conexiones persistentes, también interesa comprobar reconexiones y recuperación del estado. Son propuestas de verificación, no pruebas realizadas aquí ni una receta de migración validada.
Cambiar el entorno de ejecución no cambia automáticamente el modelo de IA ni conserva sus controles de acceso. La separación entre lógica, datos y efectos ayuda a delimitar qué debe volver a comprobarse.
El plan de alojamiento propio sigue siendo un plan
En su anuncio conjunto, Cloudflare y Deno explican la intención de integrar celld y workerd para facilitar ejecutar Workers y Durable Objects en infraestructura propia. Estos últimos combinan ejecución y estado persistente; el texto reconoce que su soporte actual en workerd está limitado a una instancia.
Esa dirección puede resultar interesante para agentes que necesitan conservar estado entre acciones. No demuestra que la integración futura esté completada ni que cualquier aplicación pueda trasladarse hoy sin cambios. Para decisiones inmediatas, conviene partir de las dependencias existentes y de los plazos confirmados, y tratar las promesas de integración como trabajo anunciado.