Cloudflare adquiere Deno para que Workers pueda autoalojarse

El viernes 9 de octubre de 2026, Cloudflare anunció que adquiere Deno, la startup detrás del runtime de JavaScript y TypeScript Deno, y que todo el equipo de Deno se unirá a la compañía. La noticia llegó en una entrada conjunta de Ryan Dahl, cofundador de Deno y creador de Node.js, y Kenton Varda, ingeniero principal de Cloudflare para Workers, publicada en el blog de Cloudflare. Dahl escribió una nota equivalente en el blog de Deno. No se revelaron los términos financieros.

Lectura relacionada: Jellyfin 12.0 abandona el prefijo 10, reescribe la biblioteca y estrena un nuevo aspecto · Project Zenith de Microsoft quiere que Windows esté listo para programar. Los desarrolladores no se convencen.

La operación coloca uno de los runtimes independientes más conocidos dentro de la plataforma con la que compitió durante años. Deno nació como una reescritura de las ideas que hay detrás de Node.js: seguro por defecto, con TypeScript integrado y una biblioteca estándar incluida de fábrica. Cloudflare Workers ejecuta JavaScript en la red perimetral de la compañía en lugar de en un servidor propiedad del desarrollador. Las personas que construyeron la alternativa trabajarán ahora en el runtime de Cloudflare. TechCrunch informó de la adquisición como un intento de mejorar el modelo de programación de Workers.

Deno había recaudado 26 millones de dólares en total, incluida una Serie A liderada por Sequoia, según la cobertura de TechCrunch de 2022. Era una empresa pequeña para los estándares de la nube, y nunca convirtió su buena reputación entre los desarrolladores en un gran negocio de alojamiento. Su producto alojado, Deno Deploy, competía directamente con Workers y con otras plataformas de borde.

Qué ocurre con el runtime y su servicio de alojamiento

El runtime sobrevive, pero con un reloj encima. Cloudflare dijo que mantendrá el runtime de Deno con alrededor de 12 meses de correcciones de errores y parches de seguridad, y después pondrá fin a su propio desarrollo. Eso no cierra el código. El proyecto sigue siendo de código abierto, y cualquiera puede seguir construyendo sobre él después de que Cloudflare se detenga. Pero una rama mantenida con una fecha de final conocida es algo distinto de una que se desarrolla activamente. Los equipos que han desplegado sobre Deno tienen ahora un motivo para planear una salida, o para mantener ellos mismos una bifurcación.

Deno Deploy, el servicio alojado, se cerrará. La entrada de Cloudflare describe el foco del equipo trasladándose a Workers sin fijar una fecha, y los informes de terceros sitúan el cierre en unos seis meses, lo que lo situaría cerca de abril de 2027. En cualquier caso, el lado comercial de Deno termina mientras el lado de código abierto continúa.

Esa división es el quid de la operación. Cloudflare no está comprando un negocio de alojamiento para gestionarlo junto al suyo. Está comprando un equipo y fundiendo su trabajo en Workers, y lo dice explícitamente: los productos independientes habían llegado a su límite.

Por qué dice Cloudflare que hizo la operación

Varda presentó la adquisición como una respuesta al problema del bloqueo del proveedor. Escribió que existe «una teoría popular» según la cual Cloudflare «hizo que Cloudflare Workers funcionara de forma distinta a otras plataformas en la nube para crear 'lock-in'», y sostuvo lo contrario: «ser de código abierto y dar a la gente una vía de escape es buen negocio». Su argumento es que dejar que los clientes se marchen forma parte de lo que hace que quieran quedarse.

Ese argumento solo funciona si hay adónde ir. El catalizador fue celld, una implementación de código abierto que ejecuta aplicaciones de Workers, incluidos los Durable Objects, en las propias máquinas del desarrollador. Se distribuye como un único binario de Rust bajo la licencia Apache-2.0. Varda dijo que el equipo de Cloudflare se alegró cuando Deno lo publicó en agosto: «cuando el equipo de Deno publicó celld en agosto, nos alegramos».

Los Durable Objects son la parte con estado de la plataforma Workers y, según The New Stack, el soporte de workerd para ellos se había limitado a una sola instancia. Eso bastaba para pruebas locales, pero no para el autoalojamiento a escala, y cerrar esa brecha es para lo que se construyó celld.

Por qué el autoalojamiento es el verdadero tema

El autoalojamiento es el término al que Cloudflare vuelve una y otra vez, y es la parte del anuncio con las consecuencias más largas. Workers es un servicio gestionado: los desarrolladores suben código y Cloudflare lo ejecuta, lo que hace cómoda la plataforma y también costoso abandonarla. Ejecutar el mismo código en otro lugar ha supuesto reescribirlo, porque Workers se diferencia de otras plataformas sin servidor de formas que llegan hasta cómo se estructuran las aplicaciones. celld demostró que la diferencia no es fundamental. Ejecuta aplicaciones de Workers, Durable Objects incluidos, en hardware que el desarrollador controla, que es la prueba que Cloudflare necesitaba de que su runtime puede viajar.

Esa prueba importa a Cloudflare porque el bloqueo del proveedor es una crítica constante a las plataformas de borde, e importa a los desarrolladores porque la elección entre comodidad y portabilidad suele ser una que tienen que hacer pronto, antes de saber cómo crecerá el proyecto. Si workerd llega a poder autoalojarse como una función soportada, el mismo código podrá ejecutarse en un despliegue pequeño y en la red de Cloudflare, y la decisión de usar Workers empezará a parecer reversible.

Qué significa para los usuarios de Deno

Para cualquiera que ejecute Deno hoy, el anuncio fija un calendario más que un final. El runtime sigue recibiendo parches de seguridad durante aproximadamente un año, lo que cubre el riesgo inmediato de que una vulnerabilidad conocida quede sin corregir. Lo que no cubre es todo lo demás que hace que un runtime merezca ser elegido: nuevas API, trabajo de rendimiento y el flujo constante de correcciones que mantienen utilizable un runtime de lenguaje frente a un ecosistema cambiante.

El diseño de Deno suaviza el aterrizaje. El proyecto se lanzó con una biblioteca estándar y un conjunto de API estándar de la web, así que los proyectos construidos sobre él no están atados a un framework propietario. Buena parte de ese código ya se ejecuta en otros runtimes, y los usuarios de Deno Deploy pueden pasarse a Workers o a otro host de borde. La migración es trabajo, no una reescritura desde cero, que es la diferencia entre un inconveniente y una crisis.

Un runtime de código abierto bajo un solo proveedor

El plan de Varda es concreto. Dahl y el cofundador de Deno Bert Belder liderarán un nuevo esfuerzo para hacer de workerd, el runtime de Workers de código abierto de Cloudflare, una forma de primera clase y soportada de construir y ejecutar aplicaciones de Workers. El trabajo fusionará código e ideas de celld de vuelta en workerd. Desde el punto de vista de un desarrollador, esa es la sustancia de la operación: la vía de escape pasa de un experimento de terceros al runtime principal.

Dahl expuso la ambición sin rodeos. «Nos unimos a Cloudflare para convertir el modelo de programación de Workers en una forma convencional de construir servidores», escribió.

«Nos unimos a Cloudflare para convertir el modelo de programación de Workers en una forma convencional de construir servidores». — Ryan Dahl, cofundador de Deno

La promesa de código abierto pesa en el planteamiento de Cloudflare, así que conviene ser preciso sobre qué abarca. workerd ya es de código abierto, y Cloudflare dice que la vía de autoalojamiento fusionada también lo será. Pero ejecutar la plataforma de Cloudflare en tu propio hardware no es lo mismo que una plataforma independiente. Reduce el riesgo de quedar varado; no restaura a Deno como competidor.

Un patrón de compras de herramientas para desarrolladores

Deno es la tercera adquisición de herramientas para desarrolladores que Cloudflare ha anunciado en 2026, señaló The New Stack. En enero compró Astro, el framework web. En junio compró VoidZero, el equipo detrás de Vite, Vitest, Rolldown y Oxc. En octubre compró Deno. Las tres comparten una forma: equipos pequeños con una influencia desmedida sobre cómo construyen los desarrolladores de JavaScript, absorbidos por una empresa que quiere a ese público en su plataforma.

Ese patrón es la razón de que la operación con Deno se lea como estrategia y no como rescate. El negocio central de Cloudflare es vender una red, y Workers es cómo vende cómputo en esa red. Poseer la cadena de herramientas a la que los desarrolladores recurren primero le da a Cloudflare voz en los valores por defecto. Astro, Vite y ahora Deno se sitúan todos al principio de la vida de un proyecto, que es cuando se toman decisiones y se forman hábitos. Comprar a los mantenedores es una vía más barata hacia esa influencia que intentar desplazarlos.

No todos los desarrolladores leerán la operación así. El runtime que eligieron los usuarios de Deno está ahora controlado por Cloudflare, y Cloudflare decidirá cómo es la próxima versión. El código abierto zanja la cuestión de la licencia, no la de la gobernanza: quién fija la hoja de ruta, cuyas correcciones entran y qué comportamiento cuenta como error.

Salvedades

Algunas partes de la historia son firmes y otras no. La adquisición en sí, el traslado del equipo, la ventana de mantenimiento de unos 12 meses y el estatus de código abierto del runtime proceden todos de la propia entrada de Cloudflare. Las fechas exactas de final, incluida la del cierre de Deno Deploy, proceden de informes de terceros y no de Cloudflare, que describe la dirección sin comprometerse con cada fecha.

El precio es desconocido, así que es imposible juzgar si los inversores de Deno, Sequoia entre ellos, ganaron dinero con la venta. El trabajo de autoalojamiento se describe como un esfuerzo futuro, no como una función ya lanzada. Cloudflare dijo que tendrá más que anunciar en los próximos meses, una promesa sin fecha adjunta.

También hay una brecha entre el destino del runtime y las necesidades de sus usuarios. Doce meses de parches mantienen en marcha las aplicaciones existentes de Deno a corto plazo. No financian nuevas funciones ni responden qué ocurre con los errores y problemas de seguridad que afloren después de que se cierre la ventana. Una bifurcación comunitaria es posible, pero si alguien la financia es una pregunta distinta de si alguien la quiere.

Qué hay que vigilar

La señal más clara será cuándo y si workerd pasa a poder autoalojarse como vía soportada. Si Cloudflare lo lanza, la línea de trabajo de celld se convierte en una vía de escape real y el argumento contra el bloqueo del proveedor tendrá algo detrás. Si el esfuerzo se queda interno o se retrasa, la adquisición se parecerá más a una compra de talento con un barniz de código abierto.

La segunda señal es el último año del runtime. Hay que observar cuánto mantenimiento recibe realmente el proyecto y si la comunidad organiza un sucesor antes de que se agote la ventana. La tercera es qué compra Cloudflare después. Tres adquisiciones de herramientas para desarrolladores en un año son una dirección, y el próximo anuncio mostrará si Deno fue el final de la secuencia o un paso más dentro de ella.

Por ahora, el hecho más claro es el que Cloudflare enunció primero: el equipo de Deno se une a la compañía que construyó el runtime que Deno pretendía mejorar.

Imagen de portada: HaeB, Wikimedia Commons, CC BY-SA 4.0.