El reloj de un año del runtime está en marcha
Deno se une a Cloudflare, pero el runtime independiente de Deno no continuará bajo su equipo de desarrollo actual. Aunque el anuncio de Cloudflare destacó una visión compartida, la propia publicación de Deno confirmó un detalle crítico: el Deno runtime tiene una fecha de caducidad de un año.
Durante los próximos 12 meses, el equipo de Deno proporcionará lanzamientos mensuales, entregando correcciones de errores esenciales y actualizaciones de seguridad. Después de este período, el desarrollo oficial del runtime de Deno cesará. Esto marca un cambio definitivo para un runtime que despertó un interés significativo entre los desarrolladores.
Fundamentalmente, el runtime de Deno sigue siendo de código abierto. Los forks de la comunidad son totalmente posibles, lo que permite a los usuarios dedicados mantener sus propias versiones. Sin embargo, esto es distinto al soporte continuo del equipo central de Deno, cuyos recursos ahora se dirigen a las prioridades estratégicas de Cloudflare.
Este giro significa que cualquier proyecto construido directamente sobre Deno, o aquellos que aprovechan runtimes compatibles con Deno como Supabase Edge Functions y las edge functions de Netlify, enfrentan una fecha límite de migración estricta. El reloj avanza para un runtime que a muchos realmente les gustaba.
Cloudflare quiere la capa de escalado, no el runtime
Cloudflare no está comprando Deno por su runtime independiente; el objetivo es la solución arquitectónica de Deno para un desafío de escalado persistente. El incentivo principal se centra en Durable Objects, la primitiva serverless de Cloudflare que ofrece almacenamiento y ejecución globalmente consistentes. Imagina una sala de chat: cada canal se asigna a su propio Durable Object, un micro-servidor direccionable con almacenamiento dedicado similar a SQLite. Más canales simplemente significan más objetos, distribuidos entre máquinas, escalando de forma inherente.
¿El inconveniente? El autohospedaje de Durable Objects a escala fuera de Cloudflare ha sido notoriamente difícil. Aunque Cloudflare Workersd, el runtime de código abierto de Cloudflare Workers, admite Durable Objects de instancia única, esta configuración es útil para pruebas pero no logra escalar en producción. El arquitecto de Cloudflare, Kenton Varda, incluso admitió que sus propios intentos de construir una solución autohospedable de múltiples instancias resultaron "vergonzosos".
La respuesta de Deno es celld (anteriormente "Deno D"), una capa de orquestación basada en Rust. Este proyecto combina un binario único con un bucket de almacenamiento de objetos compatible con S3, lo que permite que las aplicaciones existentes de Cloudflare Workers y los Durable Objects se ejecuten con escalabilidad multi-máquina en infraestructura privada.
Deno diseñó la solución que Cloudflare no pudo internamente, proporcionando una pieza crítica para una estrategia de edge autohospedada más amplia. Esta adquisición no trata sobre el futuro del runtime de Deno; se trata de integrar celld en Cloudflare Workersd para desbloquear una nueva frontera de escalado para el ecosistema de Cloudflare.
El acuerdo podría remodelar dónde se ejecutan las aplicaciones con estado
La adquisición de Deno por parte de Cloudflare apunta a una brecha estratégica crítica: un camino largamente solicitado por los desarrolladores para autohospedar Cloudflare Workers y Durable Objects a escala. La compañía obtiene un equipo probado y la tecnología celld, que empaqueta la orquestación distribuida en un único binario de Rust. Esta tecnología permite Durable Objects multi-inquilino y escalables con un bucket de almacenamiento compatible con S3.
El plan implica integrar las capacidades de celld directamente en el ecosistema de código abierto Cloudflare Workersd. Este movimiento ofrece efectivamente lo que el arquitecto de Cloudflare, Kenton Varda, admitió que era difícil de construir internamente: un entorno robusto de múltiples instancias para Durable Objects fuera de la infraestructura de Cloudflare. El éxito del proyecto podría remodelar fundamentalmente cómo se despliegan las aplicaciones con estado.
El proyecto de Deno, inicialmente llamado Deno D, resuelve el problema de escalabilidad para Durable Objects al asignar identificadores únicos (como un ID de sala de chat) directamente a objetos individuales a través de máquinas. Este enfoque garantiza una escalabilidad horizontal integrada, un marcado contraste con la limitación previa de instancia única de Cloudflare Workersd para pruebas.
Para los desarrolladores, la recompensa podría ser significativa. Esta integración promete una mayor portabilidad para las aplicaciones con estado, permitiéndoles ejecutarse en infraestructura privada mientras aprovechan las potentes primitivas de borde de Cloudflare. Aunque el desarrollo del runtime de Deno llega a su fin, su innovación central (la gestión de estado distribuido) ahora ancla una plataforma centrada en Cloudflare más fuerte y flexible. Lea más sobre la transición aquí: Deno is joining Cloudflare.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Los usuarios de Deno deben planificar más allá del anuncio
El fin del runtime de Deno exige una acción inmediata por parte de su base de usuarios. Los directamente afectados son los desarrolladores que ejecutan aplicaciones en el Deno runtime independiente, junto con servicios construidos sobre runtimes compatibles con Deno. Esto incluye plataformas como Supabase Edge Functions y Netlify Edge Functions, que ahora enfrentan un cambio crítico de dependencia.
Los usuarios deben realizar un inventario rápido de sus dependencias de runtime. Sigan de cerca las fechas de soporte oficial, ya que la ventana de 12 meses para correcciones de errores y actualizaciones de seguridad se cerrará. Comiencen a probar runtimes alternativos y monitoreen a la comunidad en busca de posibles bifurcaciones de código abierto o kits de herramientas de migración.
Esta adquisición no es una consolidación típica donde las herramientas continúan bajo una nueva propiedad. Cloudflare aseguró al equipo de Deno y su tecnología de escalado de Durable Objects (celld), pero no el runtime independiente en sí. Este acuerdo sirve como un crudo recordatorio de los riesgos inherentes al depender de herramientas de código abierto respaldadas por empresas, especialmente cuando la tecnología central es absorbida en lugar de continuada.
Comparen esto con la unión de Bun a Anthropic o la adquisición de Astro por parte de OpenAI; esos proyectos mantuvieron sus trayectorias independientes. Aquí, el desarrollo del runtime de Deno está terminando explícitamente, forzando una reevaluación fundamental para miles de desarrolladores. El mercado acaba de demostrar que incluso los runtimes populares y de alto rendimiento son prescindibles en la búsqueda de una innovación estratégica en sistemas distribuidos.
Preguntas frecuentes
¿Deno va a cerrar?
No. Deno se une a Cloudflare, pero el desarrollo oficial del runtime independiente de Deno está planeado para finalizar después de un período de 12 meses de correcciones de errores y actualizaciones de seguridad mensuales.
¿Qué está adquiriendo Cloudflare de Deno?
El acuerdo trae al equipo de Deno y su tecnología para escalar Durable Objects más allá de la infraestructura de Cloudflare al ecosistema de Cloudflare.
¿Qué son los Durable Objects?
Los Durable Objects son unidades con estado direccionables individualmente que pueden combinar la lógica de la aplicación con almacenamiento persistente, como SQLite, y escalar a través de máquinas.
¿Qué deben hacer los usuarios de Deno ahora?
Revisar el cronograma de soporte del runtime, identificar dependencias en Deno y planificar el mantenimiento comunitario, la migración u otro runtime donde sea necesario.