Andy Garcia · dev freelance
FRENES
Volver al blog
Código abierto

Cloudflare se queda con el equipo de Deno. Deno Deploy tiene seis meses, y el runtime de Deno un año de correcciones

19 de octubre de 2026 6 min de lectura

El viernes 9 de octubre de 2026, Ryan Dahl, que creó Node.js y después Deno, anunció que todo el equipo de Deno se une a Cloudflare. Su entrada en el blog de Deno dice lo que eso significa en cuatro líneas. El runtime de Deno recibe un año más de versiones mensuales con correcciones de errores y actualizaciones de seguridad, y después el equipo termina su desarrollo; sigue siendo de código abierto, y otros pueden continuarlo. Deno Deploy, el servicio de alojamiento, sigue funcionando seis meses y luego cierra, con apoyo a la migración para los clientes de pago hacia Cloudflare Workers. JSR, el registro de paquetes, sigue funcionando, sobre una infraestructura que pasa a Cloudflare. Y rusty_v8 sigue con soporte, con trabajo para integrarlo en workerd, el runtime de Workers de código abierto de Cloudflare.

Ese mismo día, Dahl y Kenton Varda, de Cloudflare, publicaron una entrada conjunta en el blog de Cloudflare. workerd y celld, la versión autoalojada de Workers de Deno, se están fusionando, y Dahl y Bert Belder liderarán el esfuerzo para que autoalojar workerd sea «una forma de primera clase con soporte oficial» de ejecutar aplicaciones con el modelo de Workers. Ninguna de las dos entradas usa la palabra adquisición ni menciona un precio. The New Stack describió la operación como la compra de la startup por parte de Cloudflare e informó de que no se revelaron las condiciones.

Yo oriento mi trabajo en Claude Code, que se distribuye como ejecutable de Bun, así que lo que le pasa a un runtime de JavaScript cuando su empresa cambia de manos no es una pregunta abstracta para mí. Leí las dos entradas, la página de precios de Deno Deploy, la documentación de migración y el historial de versiones. Los relojes están claros. Los datos no se mencionan.

Lo que se lleva Cloudflare

El activo de esta historia es celld. Deno publicó su primera versión en GitHub, la v0.1.0, el 5 de agosto. Es un demonio escrito en Rust que ejecuta una aplicación de Cloudflare Workers en tus propias máquinas, a partir del wrangler.json que ya tienes: Workers, Durable Objects, KV, Queues, D1, R2, Workflows y Cron Triggers. Su estado a largo plazo vive en un bucket compatible con S3, Google Cloud Storage o Azure. La licencia es Apache 2.0.

Eso llena un hueco que Varda admite en su mitad de la entrada. Cloudflare abrió el código de workerd después de ofrecer Workers for Platforms a clientes como Shopify en 2022, pero sus Durable Objects se ejecutan «solo en una única instancia, suficiente para pruebas locales, pero incapaz de escalar». El enrutamiento de producción de Cloudflare es, en sus palabras, «una bestia» que ningún autoalojador querría. Le explicó a The New Stack por qué la solución importa a Cloudflare: «Si el modelo es exclusivo nuestro, eso reduce nuestro TAM [mercado total direccionable] y, al final, nos hace menos competitivos frente a las nubes tradicionales».

El runtime de Deno no forma parte de ese plan, y Dahl no finge lo contrario. En un comentario de Hacker News citado por Simon Willison, escribió que Deno «ha sido absorbido por el pozo gravitatorio de la compatibilidad con Node, que lo obliga a comportarse exactamente como Node. ¿Por qué reimplementar Node? Funciona».

Dos runtimes, dos compradores

El 2 de diciembre de 2025, Bun anunció que había sido adquirido por Anthropic. Su entrada prometía que Bun sigue con licencia MIT y «extremadamente bien mantenido», y daba la razón en dos frases: «Claude Code se distribuye como ejecutable de Bun a millones de usuarios. Si Bun se rompe, Claude Code se rompe».

El runtime de Deno también tiene licencia MIT; el archivo de licencia del repositorio sigue diciéndolo. La licencia no predijo la diferencia entre los dos desenlaces. Lo que la predijo es si el comprador distribuye su propio producto sobre el runtime. Anthropic distribuye Claude Code sobre Bun. La plataforma Workers de Cloudflare corre sobre workerd.

En septiembre escribí sobre DuckDB, cuyos creadores vendieron su empresa a Amazon mientras la licencia y una fundación sin ánimo de lucro aparte se quedaban donde estaban. Deno es la versión de esa historia en la que las personas se van y el código se queda atrás, con una fecha pública de fin de mantenimiento.

Los relojes, con fechas

Deno Deploy en su forma actual pasó a disponibilidad general el 3 de febrero de 2026, bajo la promesa «Sin adaptadores. Sin configuración de build. Sin archivos de configuración específicos de un proveedor». El 19 de octubre, la documentación de Deno todavía incluía la guía para migrar a él desde Deploy Classic, que debía cerrar, junto con la API de subhosting v1, el 20 de julio de 2026. Esa guía advertía de que los datos de KV existentes no se migraban automáticamente y de que las colas de Deno no tenían soporte en la nueva plataforma.

Los equipos que dejaron Deploy Classic este verano afrontan ahora una segunda migración. El anuncio no da ninguna fecha de calendario para el cierre. Seis meses después del 9 de octubre es hacia el 9 de abril de 2027. El año del runtime llega hasta octubre de 2027, más o menos.

El historial de versiones muestra lo que significa «mensual». Deno publicó ocho versiones en GitHub en las doce semanas que van de la 2.9.0 el 25 de junio a la 2.9.7 el 17 de septiembre. Mientras escribo, el 19 de octubre, la 2.9.7 sigue siendo la última etiqueta. Una versión al mes, solo correcciones y seguridad, es mantenimiento, no desarrollo.

La aritmética de la mudanza

La factura de alojamiento no es el obstáculo. Toma una aplicación que sirve 8 millones de peticiones al mes a 7 milisegundos de CPU cada una, la cifra por petición que Cloudflare usa en sus propios ejemplos de precios.

En Deno Deploy Pro, 20 $ al mes incluyen 5 millones de peticiones, y después 2 $ por millón: 20 $ + 3 × 2 $ = 26 $. La CPU es 8 millones × 7 ms = 56 millones de ms, unas 15,6 horas, dentro de las 50 horas incluidas, suponiendo que el tiempo de memoria también se mantenga dentro de su cupo.

En Workers Paid, el mínimo mensual de 5 $ incluye 10 millones de peticiones y 30 millones de milisegundos de CPU, y después 0,02 $ por cada millón adicional de milisegundos de CPU. La CPU por encima del cupo es 56 millones menos 30 millones, o sea 26 millones de ms, así que 26 × 0,02 $ = 0,52 $. Total 5,52 $, y Cloudflare no cobra la salida de datos.

Solo en peticiones y CPU, el destino es más barato. KV, el almacenamiento y, en Workers, los Durable Objects se miden aparte, así que tómalo como un suelo, no como un presupuesto. El coste real es el código. Un manejador de peticiones escrito en TypeScript se porta en su mayor parte. Deno.openKv, Deno.cron y los métodos de cola de KV son API de Deno; en Workers, los equivalentes (bindings de KV y Queues, Cron Triggers) se declaran en la configuración y tienen sus propias interfaces. Y el apoyo a la migración se promete a los clientes de pago. La entrada del 9 de octubre no dice nada de las aplicaciones del plan gratuito, de hasta 1 millón de peticiones al mes.

Qué haría este mes

Si tuviera una aplicación de Deno en producción, cinco cosas, en este orden.

Haz el inventario de las llamadas específicas de Deno. Busca en el código Deno.openKv, Deno.cron, enqueue y listenQueue, el SDK @deno/sandbox y cualquier script de deployctl. Cada coincidencia es un punto de migración. Todo lo demás es TypeScript.

Exporta los datos de KV mientras el servicio todavía responde. La documentación de Deno describe cómo abrir una base de datos KV gestionada desde una aplicación CLI de Deno local con el ID de la base y un token de acceso en DENO_KV_ACCESS_TOKEN. Un script corto que liste cada clave en un archivo que controlas vale más que un ticket de migración abierto en marzo. La misma página dice que los datos de KV se almacenan en Estados Unidos, con su región principal en el norte de Virginia (us-east4), algo que conviene saber antes de que un cliente pregunte.

Fija tu propia fecha, anterior a la suya. Finales de marzo de 2027 para Deploy. Para el runtime, decide antes de la primavera si pasas a Node, a Bun o a un fork de la comunidad. Si los indicadores de permisos de Deno fueron la razón de tu elección, el modelo de permisos de Node se añadió en la v20.0.0 y se declaró estable en la v23.5.0 y la v22.13.0; Simon Willison señala que todavía no puede permitir hosts de red concretos.

Elige el destino según adónde van los datos, no según la factura. Workers con la ayuda a la migración de Cloudflare, una flota autoalojada sobre celld o workerd, o un proveedor genérico que ejecute un runtime estándar. Si eliges Workers, ten celld presente como vía de salida. El propio argumento de Varda es que el runtime abierto es la salida de emergencia, y escribe que Cloudflare tiene antiguos clientes que se fueron así.

Añade una pregunta a tu due diligence de proveedores. Como CTO, es la que haría ahora sobre cada runtime y cada proveedor de alojamiento bajo un producto: ¿quién paga a las personas que lo mantienen, y distribuyen su propio producto sobre él? Una licencia te dice que el código sobrevivirá. La respuesta a esa pregunta te dice si alguien cobrará por mantenerlo funcionando.

Deno sobrevivirá al interés de su empresa por él. Planifica el año intermedio.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos