⏱️ Lectura: 11 min
Cloudflare se queda con los creadores de uno de los runtimes de JavaScript más influyentes de la última década. Ryan Dahl, cocreador de Node.js y fundador de Deno, anunció este 9 de octubre de 2026 que todo el equipo de Deno se incorpora a Cloudflare para construir celld de Cloudflare, una plataforma pensada para que escalar una aplicación distribuida no dependa de infraestructura armada a mano por cada equipo.
📑 En este artículo
El anuncio llega con fechas concretas: Deno Deploy cierra en seis meses y el desarrollo propio del runtime Deno termina en un año. JSR, el registro de paquetes de Deno, sigue en pie pero cambia de infraestructura.
TL;DR
- Cloudflare incorpora a todo el equipo de Deno para construir celld de Cloudflare, su nueva plataforma distribuida.
- Deno Deploy opera seis meses más y luego cierra; los clientes de pago migran a Cloudflare Workers.
- El runtime Deno recibe un año de parches mensuales antes de que Cloudflare detenga su desarrollo propio.
- JSR sigue activo, pero su infraestructura se traslada a los servidores de Cloudflare.
- rusty_v8 seguirá mantenido y se integrará al runtime workerd de Cloudflare Workers.
Qué es celld de Cloudflare
Celld de Cloudflare es la plataforma distribuida que el equipo de Deno construye dentro de Cloudflare sobre el modelo de programación de Workers, combinando ejecución serverless, estado persistente y comunicación en tiempo real para que escalar una aplicación no dependa de infraestructura adicional armada por cada equipo.
La apuesta nace de una idea que Dahl viene repitiendo desde su post JavaScript Containers: cómputo, almacenamiento y comunicación deberían funcionar juntos sin que cada aplicación arme su propia infraestructura. En Cloudflare, esa idea se apoya en los equipos de Workers y Durable Objects, que ahora suman a los ingenieros de Deno.
Qué pasó
Dahl publicó el anuncio en el blog oficial de Deno bajo el título «Deno is joining Cloudflare». En el texto agradece a quienes contribuyeron código, construyeron negocios sobre Deno y reportaron errores durante los últimos ocho años, desde que presentó el proyecto en 2018.
La carta detalla cuatro cambios concretos. El runtime de Deno recibirá lanzamientos mensuales con parches de seguridad durante un año; después, Cloudflare deja de desarrollarlo y el proyecto queda abierto para que la comunidad lo continúe. Deno Deploy, el servicio de hosting en el borde, opera seis meses más antes de apagarse, con soporte de migración para los clientes de pago que se muden a Cloudflare Workers.
JSR, el registro de paquetes que Deno lanzó como alternativa a npm, sigue funcionando, pero su infraestructura se traslada a los servidores de Cloudflare. Y rusty_v8, los bindings de Rust sobre el motor V8 que usa Deno internamente, seguirán mantenidos con la meta de integrarlos al runtime open source workerd de Cloudflare Workers.
| Producto | Qué pasa | Plazo | A quién le importa |
|---|---|---|---|
| Runtime Deno | Parches mensuales y luego fin del desarrollo oficial | 1 año | Quienes corren Deno en producción |
| Deno Deploy | Deja de operar; migración asistida a Cloudflare Workers | 6 meses | Clientes de pago de Deploy |
| JSR | Sigue activo; infraestructura se muda a Cloudflare | Sin fecha de cierre | Publicadores de paquetes en JSR |
| rusty_v8 | Mantenimiento continuo e integración futura a workerd | Sin fecha fija | Equipos que embeben V8 vía Rust |
Contexto e historia
Dahl no llegó a esto por casualidad. Creó Node.js en 2009 y lo dejó en manos de la comunidad años después. En 2018 subió al escenario de JSConf EU a dar la charla 10 Things I Regret About Node.js, donde señaló fallas de seguridad y de diseño en el proyecto que él mismo había escrito. Deno nació esa misma noche como una respuesta: un runtime con permisos explícitos, soporte nativo de TypeScript e importación de módulos por URL en vez de un gestor de paquetes centralizado.
📌 Nota: El año de soporte no es indefinido: Cloudflare confirma parches mensuales de seguridad, pero no promete nuevas funciones para el runtime Deno durante ese tiempo.
Deno 1.0 salió en 2020. La compañía detrás, también llamada Deno, sumó después Deno Deploy para alojar esas aplicaciones en el borde y JSR como un registro de paquetes pensado para corregir errores de diseño de npm, como la ausencia de tipos y la resolución de versiones ambigua. Deno 2.0 dio después un giro pragmático: agregó compatibilidad casi total con Node.js y npm, algo que Dahl había evitado al principio por decisión ideológica.
La progresión que describe Dahl en su anuncio va de Deno a Deno Deploy y de ahí a celld de Cloudflare. Cada paso simplificó una capa: el runtime resolvió qué corre el código, Deploy resolvió dónde corre, y la plataforma celld busca resolver cómo escala sin que el desarrollador tenga que ensamblar esa infraestructura pieza por pieza.
Detalles técnicos
El mecanismo detrás de Cloudflare Workers explica por qué Dahl apuesta por este modelo en vez de mantener Deno Deploy. Un Worker no arranca un proceso ni un contenedor: ejecuta el código dentro de un isolate de V8, el mismo mecanismo de aislamiento que usa Chrome entre pestañas. Como el proceso que hospeda los isolates ya está corriendo, no hay arranque de sistema operativo que esperar en cada petición.
Durable Objects agrega estado a ese modelo. Cada objeto tiene un identificador único y Cloudflare garantiza que solo exista una instancia activa de ese objeto a la vez en toda su red, con acceso a almacenamiento persistente y a conexiones WebSocket de larga duración. Esa combinación de ejecución barata, estado consistente, WebSockets y una interfaz de JavaScript de alto nivel es, según el propio anuncio, lo que hace viables los agent harnesses: procesos de IA que necesitan mantenerse vivos y recordar contexto durante horas, no solo durante una petición HTTP.
flowchart TD
A["Cliente"] --> B["Cloudflare Worker"]
B --> C["Durable Object (id unico)"]
C --> D[("Almacenamiento persistente")]
subgraph S1["celld de Cloudflare"]
B
C
D
end
Así se ve hoy un Durable Object en Cloudflare Workers, la pieza sobre la que la plataforma celld se construye:
export class ContadorAgente {
constructor(state, env) {
this.state = state;
}
async fetch(request) {
let valor = (await this.state.storage.get("valor")) || 0;
valor++;
await this.state.storage.put("valor", valor);
return new Response(String(valor));
}
}
export default {
async fetch(request, env) {
const id = env.CONTADOR.idFromName("sesion-demo");
const stub = env.CONTADOR.get(id);
return stub.fetch(request);
}
};Cada llamada a idFromName("sesion-demo") devuelve el mismo objeto, así que el contador sube de forma consistente aunque las peticiones lleguen a distintos puntos de la red de Cloudflare. Para confirmarlo basta llamar al endpoint dos veces seguidas: la primera respuesta es 1 y la segunda es 2, sin que el estado se reinicie entre ambas. No hay forma de inspeccionar ese estado desde afuera sin agregar un endpoint propio que lo exponga: Durable Objects no publica un panel de depuración público.
💡 Tip: Para distinguir un bug de infraestructura de uno de tu propio código en un Worker con Durable Objects, repetí la misma petición con el mismo id: si el valor no persiste entre llamadas, el problema está en cómo armaste el binding, no en la red de Cloudflare.
[[durable_objects.bindings]]
name = "CONTADOR"
class_name = "ContadorAgente"Ese archivo wrangler.toml es lo único que declara la relación entre el Worker y el objeto. No hay balanceador que configurar ni base de datos externa que levantar: el objeto y su almacenamiento viajan juntos.
Impacto y análisis
Para Cloudflare, sumar al equipo de Deno refuerza su apuesta por Workers y Durable Objects justo cuando la demanda de infraestructura para agentes de IA crece. El propio anuncio lo dice sin rodeos: Durable Objects resulta particularmente útil para harnesses de agentes porque combina ejecución barata con memoria persistente, algo que un agente que corre durante horas necesita y que un contenedor tradicional no ofrece sin trabajo extra.
El movimiento no ocurre en el vacío. En 2026, varios proyectos de herramientas de JavaScript terminaron bajo el techo de laboratorios de IA o nubes grandes: Bun se sumó a Anthropic meses antes. Deno, con Cloudflare, sigue ese mismo patrón: la infraestructura de desarrollo se concentra en quienes operan los centros de datos y entrenan los modelos.
La letra chica tiene un costo real para quienes eligieron Deno Deploy precisamente para evitar depender de un solo proveedor de nube. La fusión Deno-Cloudflare resuelve ese problema cambiándolo por otro: ahora la alternativa a los grandes proveedores queda, ella misma, dentro de uno de los grandes proveedores. Seis meses es poco tiempo para reescribir una app pensada para un runtime distinto, sobre todo si usa APIs de Deno que Cloudflare Workers no replica igual.
Qué sigue
En los próximos doce meses, Deno seguirá recibiendo versiones mensuales con parches de seguridad, pero sin desarrollo de funciones nuevas por parte de Cloudflare. El anuncio deja la puerta abierta a que la comunidad continúe el proyecto una vez termine ese año, ya que el código sigue siendo open source.
Los clientes de pago de Deno Deploy tienen seis meses para migrar, con soporte directo del equipo que ahora trabaja en Cloudflare. JSR no tiene fecha de cierre: sigue operando mientras su infraestructura pasa, de forma transparente para quien publica paquetes, a los servidores de Cloudflare.
Dahl cierra la carta con una invitación puntual: cualquiera que construya agentes a gran escala y quiera correrlos en infraestructura propia puede escribirle directamente al correo publicado en el anuncio. Es una señal de hacia dónde apunta el interés real detrás de la fusión Deno-Cloudflare: no tanto el hosting tradicional, sino la infraestructura para agentes de IA que necesitan estado y tiempo de vida largo.
📖 Resumen en Telegram: Ver resumen
Si corrés algo en Deno Deploy hoy, probá levantar ese mismo endpoint como un Worker con un Durable Object en el dashboard de Cloudflare antes de que se cumplan los seis meses del aviso.
Preguntas frecuentes
¿La plataforma celld reemplaza a Deno Deploy?
Sí, en la práctica. Deno Deploy deja de operar en seis meses y Cloudflare ofrece migración asistida hacia Workers y Durable Objects, la base sobre la que se construye la plataforma celld.
¿Deno deja de ser open source tras unirse a Cloudflare?
No. El runtime sigue siendo open source y Cloudflare invita a que la comunidad continúe su desarrollo una vez termine el año de soporte oficial con parches mensuales.
¿Qué pasa con JSR después de la fusión Deno-Cloudflare?
JSR sigue operando sin fecha de cierre. Lo único que cambia es la infraestructura: pasa a correr sobre los servidores de Cloudflare.
¿Debo migrar mis apps de Deno Deploy ahora mismo?
No hay plazo inmediato, pero el reloj corre: Deno Deploy deja de operar seis meses después del anuncio del 9 de octubre de 2026, y Cloudflare ofrece soporte de migración solo a clientes de pago.
¿rusty_v8 sigue mantenido tras el acuerdo con Cloudflare?
Sí. Cloudflare confirmó que seguirá dando soporte a rusty_v8 y trabajará para integrarlo al runtime open source workerd.
Referencias
- Deno: anuncio oficial de Ryan Dahl sobre la fusión con Cloudflare.
- Cloudflare Blog: publicación conjunta de Ryan Dahl y Kenton Varda sobre celld y Durable Objects.
- Cloudflare Docs: documentación oficial de Durable Objects.
- Cloudflare Docs: documentación oficial de Cloudflare Workers.
- GitHub: repositorio de rusty_v8, los bindings de Rust sobre V8.
- JSR: registro de paquetes que sigue operando tras la fusión.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Taylor Vick en Unsplash
¿Te sirvió? ¿Te dio otro error? Contalo abajo: las preguntas se responden y le sirven al siguiente que llegue.
Dejar un comentario
0 Comentarios