Deno se une a Cloudflare: Node vs Bun vs Deno

El 9 de octubre de 2026, Deno anunció que todo su equipo se une a Cloudflare. El título que más circula dice que "apagan" el runtime, y eso es impreciso: no se apaga mañana, pero tiene fecha de cierre. Para quien tiene Deno corriendo en un servidor propio, la pregunta útil es cuánto margen hay y a dónde mudarse.

Deno es un runtime de JavaScript y TypeScript creado por Ryan Dahl, el autor original de Node.js. Según el anuncio oficial, el runtime recibirá un año más de releases mensuales con correcciones y parches de seguridad, y después su desarrollo oficial termina. El código sigue siendo open source. Para producción en servidor propio, hoy la opción más previsible es Node.js en una versión LTS.

¿Qué anunció Deno exactamente y qué plazos hay?

Deno se une a Cloudflare: qué runtime JS elegir en tu servidor

El anuncio fija dos plazos: un año para el runtime y seis meses para Deno Deploy. Todo lo demás (JSR, rusty_v8) tiene destinos distintos. Esto es lo que dice la publicación de Deno:

Runtime de Deno: un año de soporte mínimo. La cita literal del blog oficial: "We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime." Pasado ese año no hay desarrollo oficial, aunque el proyecto queda abierto para que lo mantenga la comunidad.
Deno Deploy: cierra en seis meses. Los clientes que pagan tienen apoyo para migrar a Cloudflare Workers.
JSR sigue funcionando. El registro de paquetes continúa, con su infraestructura migrando a Cloudflare.
rusty_v8 y workerd siguen en desarrollo. El equipo trabaja en integrar ambos proyectos.

Contando desde el anuncio, el runtime tiene soporte oficial hasta aproximadamente octubre de 2027 y Deno Deploy hasta alrededor de abril de 2027. Son estimaciones mías a partir de "un año" y "seis meses"; la fecha exacta de cada cierre no figura en lo que pude verificar.

¿Por qué Deno deja de desarrollar su propio runtime?

La razón declarada es que el equipo cree que puede hacer trabajo más importante dentro de Cloudflare. Según el resumen de Simon Willison, Ryan Dahl dijo que Deno ya no es donde puede hacer el trabajo más importante, y que el proyecto quedó atrapado en la gravedad de la compatibilidad con Node: si hay que reimplementar Node, las mejoras marginales no alcanzan.

Esa lectura es consistente con lo que se veía desde Deno 2: para que la gente migrara, Deno tuvo que acercarse cada vez más a Node (especificadores npm:, package.json, APIs de Node). Un runtime que gana adopción imitando a otro compite siempre con una desventaja. Mi opinión: el diferencial real de Deno nunca fue la velocidad, fue el modelo de permisos y la experiencia con TypeScript, y Node fue cerrando esa brecha. Simon señala que Node incorporó un sistema de permisos desde la v20.0.0 (abril de 2023), aunque su control de red es más binario y no permite listas de hosts permitidos.

¿Qué es celld y qué tiene que ver con self-hosting?

celld es un proyecto open source del equipo de Deno, lanzado en agosto de 2026, que implementa el patrón de Durable Objects de Cloudflare para correr en infraestructura propia. La idea es combinarlo con workerd, el runtime open source de Cloudflare Workers, para ejecutar el mismo modelo en la nube de Cloudflare o en tus propios servidores.

Según RuntimeWire, hoy workerd solo soporta Durable Objects de instancia única, algo adecuado para pruebas locales. La integración de las capacidades multi-instancia de celld es el objetivo declarado, no algo que puedas desplegar hoy en producción. Si te interesa el modelo, seguilo como proyecto a observar; no lo uses todavía como base de un sistema crítico.

¿Qué pasa si hoy tengo Deno en producción?

No hay urgencia de emergencia: tenés aproximadamente un año de parches de seguridad. Lo que cambia es que cualquier proyecto nuevo con Deno nace con fecha de vencimiento del soporte oficial.

Si usás Deno Deploy, es lo más urgente. Son seis meses; planificá la salida a Workers o a un servidor propio.
Si corrés Deno en tu VPS o dedicado, tenés margen. Los parches mensuales siguen durante un año. Usá ese tiempo para evaluar la migración, no para improvisarla.
Si tu código usa APIs específicas de Deno (Deno.serve, Deno.readFile, imports por URL o jsr:), la migración requiere reescribir esas partes. Conviene aislarlas detrás de una capa propia.
Si tu código ya usa npm: y APIs web estándar (fetch, Request/Response, URL), el costo de pasar a Node o Bun es bastante menor.

¿Qué runtime conviene en tu propio servidor: Node.js, Bun o Deno?

Para producción en servidor propio, Node.js en una versión LTS es la opción de menor riesgo. Bun es razonable para proyectos nuevos si aceptás depender de una empresa. Deno ya no es una apuesta recomendable para proyectos nuevos de largo plazo, aunque sigue siendo funcional durante el año de soporte.

Criterio	Node.js	Bun	Deno
Respaldo	Proyecto de la OpenJS Foundation, con calendario público de releases	Anthropic lo adquirió en diciembre de 2025; sigue MIT y con su equipo al frente	Equipo absorbido por Cloudflare; desarrollo oficial termina en un año
Compatibilidad npm	Total (es la referencia)	Alta, pero verificá tus dependencias nativas	Buena vía `npm:`, con matices
Fortaleza	Madurez, ecosistema, soporte LTS	Velocidad de instalación y toolkit todo en uno (runtime, gestor de paquetes, bundler, tests)	Permisos por defecto y TypeScript nativo
Riesgo principal	Menos "baterías incluidas"	Gobernanza atada a una empresa	Fin del soporte oficial

¿Cuánto soporte tienen las versiones LTS de Node.js?

Según endoflife.date, Node.js 24 recibe soporte de seguridad hasta el 30 de abril de 2028, y Node.js 26 (publicado el 5 de mayo de 2026) hasta el 30 de abril de 2029. Node.js 22 tiene seguridad hasta el 30 de abril de 2027, y Node.js 20 ya terminó su soporte el 30 de abril de 2026. Si todavía tenés Node 20 en producción, ese es un pendiente más urgente que el de Deno.

Según la misma fuente, el soporte activo de Node 24 termina el 20 de octubre de 2026. Una fuente secundaria (Codeflamme) ubica el paso de Node 26 a LTS activo el 28 de octubre. Verificá ambas fechas en el sitio oficial de Node.js antes de planificar.

¿Es seguro apostar por Bun después de lo que pasó con Deno?

Es una apuesta razonable pero con la misma lección: el futuro de tu runtime depende de las decisiones de la empresa que lo sostiene. Anthropic anunció la compra de Bun con la promesa de que sigue open source bajo licencia MIT y con el mismo equipo liderando el desarrollo. La nota oficial menciona más de 7 millones de descargas mensuales y más de 82.000 estrellas en GitHub al momento del anuncio.

Mike Krieger, Chief Product Officer de Anthropic, dijo: "Bun represents exactly the kind of technical excellence we want to bring into Anthropic". Que Bun sea hoy una pieza central de herramientas propias de Anthropic le da incentivos para mantenerlo. Aun así, ese incentivo puede cambiar, y la diferencia con Node es que Node no depende de una sola empresa.

¿Y los benchmarks que muestran a Bun muy por encima de Node?

Los números publicados en blogs comparativos varían mucho según la prueba, la versión y el hardware, así que no los tomaría como decisión. En un servidor propio el cuello de botella suele ser la base de datos, la red o tu propio código, no el runtime. Si el rendimiento te importa, medí tu aplicación real con cada runtime en la misma máquina, con la misma carga.

¿Qué puedo hacer hoy para no quedar atado a un runtime?

Lo más efectivo es escribir código portable y fijar la versión del runtime en tu imagen. Así, cambiar de Deno a Node (o a Bun) pasa a ser una tarea acotada y no una reescritura.

Apoyate en APIs estándar. fetch, Request, Response, URL y crypto.subtle funcionan en los tres runtimes. Encerrá lo específico (archivos, servidor HTTP) en un módulo propio.
Probá la migración en paralelo. Levantá la misma app con Node y con tu runtime actual detrás de un proxy inverso, y comparalas con tráfico real o un set de pruebas.
Suscribite a los avisos de seguridad. Si seguís en Deno durante el año de soporte, verificá la versión instalada con deno --version y actualizá con cada release mensual.

Fijá la versión en el contenedor. Ejemplo mínimo con Node LTS:

FROM node:24-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
CMD ["node", "server.js"]

Inventariá dónde usás Deno. Buscá APIs propias del runtime con:

grep -rnE "Deno\.|jsr:|https://deno\.land" --include=*.ts --include=*.js .

Si el objetivo es achicar la imagen resultante, en el blog ya publicamos cómo reducir imágenes Docker con Dockerfiles multi-stage, que aplica igual a cualquiera de los tres runtimes. Para correr esto en un VPS o un servidor dedicado propio no necesitás nada específico del runtime: alcanza con un Linux estable, un proxy inverso y tu proceso supervisado por systemd o por Docker.

Preguntas frecuentes

¿Deno deja de existir?

No, pero su desarrollo oficial termina dentro de aproximadamente un año. Hasta entonces habrá releases mensuales de correcciones y seguridad, y el código sigue siendo open source para que la comunidad lo continúe si quiere.

¿Cuándo cierra Deno Deploy?

Deno Deploy cierra seis meses después del anuncio del 9 de octubre de 2026. Los clientes que pagan tienen soporte para migrar a Cloudflare Workers.

¿JSR deja de funcionar?

No. Según el blog de Deno, JSR sigue operando y su infraestructura pasa a Cloudflare. Si publicás paquetes ahí, el anuncio no los afecta directamente.

¿Puedo seguir usando Deno en un servidor propio?

Sí, durante el año de soporte tenés parches mensuales de seguridad. Para un proyecto nuevo de largo plazo, conviene elegir otro runtime.

¿Qué runtime conviene para un proyecto nuevo en un VPS?

Node.js en una versión LTS es la opción más segura por madurez, compatibilidad y calendario de soporte público. Bun es una alternativa válida si priorizás velocidad de herramientas y aceptás su gobernanza actual.

¿Qué es celld?

celld es un proyecto open source del equipo de Deno que implementa el patrón de Durable Objects para correr en infraestructura propia. Se planea combinarlo con workerd, aunque esa integración todavía no está lista para producción.

¿Sirve hoy workerd para self-hosting de Durable Objects?

Solo de forma limitada. Según RuntimeWire, workerd soporta hoy Durable Objects de una sola instancia, útil para pruebas locales pero no para escalar en producción.

Fuentes: Deno, Simon Willison, RuntimeWire, endoflife.date, Anthropic.

Deno se une a Cloudflare: qué runtime JS elegir en tu servidor