Node.js EOL 2026: cuándo expira cada versión

Las fechas fin de vida Node.js EOL ya no son un tema de planificación futura: si hoy tenés Node.js 18 o 20 corriendo en producción, estás ejecutando un runtime sin parches de seguridad. Node.js 20 llegó a su End-of-Life el 30 de abril de 2026, y cualquier CVE nueva que aparezca nunca va a recibir un fix oficial para esa versión.

Ciclo de vida de Node.js: LTS vs versiones Current

Node.js es un entorno de ejecución JavaScript del lado del servidor mantenido por la OpenJS Foundation, con un ciclo de vida predefinido que determina cuánto tiempo cada versión recibe parches de seguridad y correcciones de bugs.

El sistema es simple: las versiones con número par (18, 20, 22, 24) son candidatas a Long-Term Support (LTS). Las versiones con número impar (17, 19, 21, 23) son “Current”, viven alrededor de seis meses y nunca alcanzan LTS. Si usás una versión impar en producción, ya sabés que el soporte es efímero por diseño.

Para las versiones pares, el ciclo tiene tres etapas. Primero, seis meses como Current desde el lanzamiento. Después, doce meses en LTS Activo (bugfixes, parches de seguridad, funcionalidades nuevas controladas). Finalmente, dieciocho meses en Mantenimiento (solo parches críticos de seguridad). En total: 30 meses de soporte desde el lanzamiento inicial, o más de tres años si contás desde que entra al período LTS.

¿Y qué pasa cuando termina ese ciclo? Exacto: ningún parche más, ni para vulnerabilidades críticas.

Calendario completo de End-of-Life 2023-2027

Acá están las fechas que importan. Guardá esta tabla porque cada vez que alguien en tu equipo pregunte “¿podemos seguir con Node 18?”, la respuesta está acá.

Versión	Tipo	Inicio LTS	Fin de soporte (EOL)	Estado en mayo 2026
Node.js 14	LTS	Oct 2020	30 abril 2023	EOL — sin soporte hace 3 años
Node.js 16	LTS	Oct 2021	11 septiembre 2023	EOL — acelerado 7 meses
Node.js 18	LTS	Oct 2022	30 abril 2025	EOL desde hace un año
Node.js 20	LTS	Oct 2023	30 abril 2026	EOL desde hace semanas
Node.js 22	LTS	Oct 2024	30 abril 2027	LTS activo — soportado
Node.js 24	LTS	Oct 2025	Oct 2027 (est.)	LTS activo — recomendado

Un dato que sorprendió a muchos equipos: según el análisis de endoflife.ai, Node.js 16 llegó a EOL siete meses antes de lo previsto originalmente, porque OpenSSL 1.1.1 (que 16 bundleaba) llegó a su propio fin de vida en septiembre de 2023. El Release Working Group no vio sentido en mantener una versión con criptografía sin soporte.

Riesgos de usar versiones sin soporte oficial

Ponele que tu stack corre Node.js 20 en producción. Apareció una vulnerabilidad nueva el 15 de mayo de 2026. ¿Cuándo llega el parche oficial? No llega. Nunca. Eso es lo que significa EOL.

El riesgo tiene capas. Primero, el runtime en sí: cualquier CVE que afecte el motor V8, el loop de eventos, o los módulos core de Node.js no recibe fix. Segundo, las dependencias bundleadas: Node.js 14, por ejemplo, incluía OpenSSL 1.1.1, que según la documentación oficial de Node.js llegó a su propio EOL en septiembre de 2023. Dos vectores de ataque sin parchar en el mismo proceso.

Las releases de seguridad de marzo de 2026 para Node.js, que cubrieron versiones 22.x y 24.x, dejaron fuera a Node.js 20 completamente (a pesar de que técnicamente aún tenía días de soporte en ese momento, las versiones EOL de facto ya estaban siendo ignoradas). Los equipos que corrían 20 en esa fecha tuvieron que evaluar si aplicar los mismos parches manualmente o acelerar la migración.

El impacto en producción no es teórico. Un runtime sin parches es un dato que aparece en auditorías de seguridad, en compliance SOC 2, en revisiones de DAST/SAST, y en los reportes de dependencias de las plataformas cloud. Si tu empresa tiene algún tipo de certificación de seguridad, correr un runtime EOL es una observación automática. Relacionado: en tus flujos de integración continua.

Cómo verificar qué versión de Node.js estás usando

Antes de entrar en pánico (o en negación), chequeá qué tenés instalado.

• Versión activa: node --version — te da algo como v20.18.0
• En proyectos con nvm: revisá el archivo .nvmrc en la raíz del repo
• En package.json: buscá el campo "engines": {"node": ">=18.0.0"}
• En contenedores Docker: revisá el FROM en el Dockerfile — FROM node:20-alpine significa que estás en 20 EOL
• Dependencias nativas: corrés npx @npmcli/arborist ls --all para auditar paquetes que compilan contra la ABI de Node.js

Ojo con el caso Docker: es muy común tener la versión correcta en local pero un Dockerfile desactualizado que hace el build con Node.js 18 o 20. El pipeline pasa, el test suite verde, y nadie mira el FROM hasta que alguien audita.

Guía de migración desde versiones EOL

La buena noticia es que migrar desde versiones LTS recientes es bastante manejable. La mala es que hay que hacerlo.

Desde Node.js 14

Esta es la migración más larga. Node.js 14 fue la última versión que soportó ciertos addons nativos compilados contra el ABI de V8 de esa era. El path recomendado es saltar directo a Node.js 22, sin pasar por 16, 18 o 20 (todos EOL). Usá npx @npmcli/arborist ls --all para identificar dependencias nativas y auditá compatibilidad con ES2022+. El cambio más frecuente es la gestión de módulos CommonJS vs ESM, que se volvió más estricta en versiones posteriores.

Desde Node.js 16

Similar al caso de 14 en términos de skip: vas directo a 22. La ventaja es que 16 ya trajo la mayoría de los cambios de ESM y fetch experimental, así que la delta de APIs es menor. Lo que sí hay que revisar son los cambios de comportamiento en crypto y streams que se consolidaron en versiones posteriores.

Desde Node.js 18 o 20

Esta es la migración más común en 2026. Skip a Node.js 22 (o directo a 24 si querés ir a la versión con soporte más largo). La compatibilidad de APIs es alta: ambas versiones EOL ya tenían fetch nativo, soporte ESM maduro, y las APIs de test runner incorporadas. Los cambios de comportamiento son menores y la mayoría de los proyectos compila sin modificaciones. El punto de fricción principal son dependencias que especifican "engines": {"node": "18"} en su package.json — no bloquea, pero tira warnings.

Node.js 22 vs 24: cuál elegir en 2026

Ambas están soportadas, pero tienen perfiles diferentes.

Aspecto	Node.js 22	Node.js 24
Estado LTS	LTS activo	LTS activo (actual)
EOL estimado	Abril 2027	Octubre 2027
npm bundleado	npm 10.x	npm 11.x
V8 engine	V8 12.4	V8 12.9+
Recomendado para	Proyectos estables, migración urgente	Proyectos nuevos, mayor vida útil

Si estás migrando ahora mismo desde 20 y querés el menor riesgo posible, Node.js 22 es la ruta conservadora: la compatibilidad de APIs es prácticamente total. Si estás arrancando un proyecto nuevo o tenés tiempo de hacer una migración más cuidadosa, Node.js 24 te da más margen antes de la próxima ventana de EOL.

Node.js 24 también viene con mejoras en el test runner nativo y soporte mejorado para Web Streams API, lo que importa si tu proyecto depende de streaming de datos. No es un cambio de paradigma, pero suma.

Opciones de soporte comercial después de EOL

Hay equipos que no pueden migrar de un día para el otro. Dependencias complejas, proyectos legacy, ciclos de aprobación internos. Para esos casos existen alternativas de soporte comercial.

HeroDevs Never-Ending Support (NES) ofrece parches de seguridad para versiones EOL de Node.js, incluyendo 14, 16, 18 y 20. Según su documentación, el modelo funciona como backport de fixes críticos sobre la rama EOL, sin requerir actualización de versión. El costo-beneficio depende del contexto: para sistemas críticos donde una migración implica meses de trabajo, el soporte comercial puede ser más barato que el esfuerzo de migración inmediata.

NodeSource tiene una oferta similar con distribuciones empresariales de Node.js. Ninguna de las dos opciones reemplaza la migración a largo plazo; son puentes para equipos con restricciones operativas reales. Más contexto en con runners autohospedados dedicados.

Para la mayoría de los proyectos, el soporte comercial es un parche (sin ironía) temporal. La deuda técnica de correr un runtime EOL no desaparece con un contrato; solo se pospone a mayor costo.

Errores comunes al gestionar el ciclo de vida de Node.js

Error 1: Confundir “versión estable” con “versión soportada”

Node.js 20 es estable. Funciona perfectamente. No se rompe nada. El problema no es estabilidad sino cobertura de seguridad. Un runtime EOL puede correr sin errores durante meses mientras acumula vulnerabilidades que nadie va a parchear. La estabilidad operativa y el soporte de seguridad son dos cosas distintas.

Error 2: Migrar solo el runtime y olvidarse del Dockerfile

Actualizás tu máquina local a Node.js 22, los tests pasan, todo bien. Pero el Dockerfile dice FROM node:20-alpine y el CI/CD sigue generando imágenes con la versión EOL. Pasa más seguido de lo que parece (sí, en serio). La migración de Node.js tiene que incluir una búsqueda en todos los archivos de configuración: Dockerfile, docker-compose.yml, archivos de CI como GitHub Actions o GitLab CI, y cualquier script de build que pise la versión.

Error 3: Asumir que “funciona en CI” implica compatibilidad total

El test suite verde en Node.js 22 no garantiza ausencia de problemas en producción con cargas reales. Hay diferencias de comportamiento en garbage collection, en el manejo de backpressure en streams, y en cómo se resuelven ciertos edge cases de async/await que solo aparecen bajo concurrencia alta. La migración exige pruebas de carga, no solo tests unitarios.

Preguntas Frecuentes

¿Cuándo expiró el soporte de Node.js 18 y 20?

Node.js 18 llegó a EOL el 30 de abril de 2025. Node.js 20 lo hizo el 30 de abril de 2026. Ambas versiones están sin soporte oficial: no reciben parches de seguridad ni correcciones de bugs desde esas fechas. Si las estás usando en producción hoy, estás expuesto a cualquier CVE que aparezca.

¿Mi versión de Node.js ya no recibe actualizaciones de seguridad?

Depende de la versión. Cualquier versión 20 o menor ya está fuera de soporte oficial. Node.js 22 y 24 siguen recibiendo parches activamente. Podés verificar el estado exacto en endoflife.date/nodejs, que mantiene el calendario actualizado en tiempo real.

¿A qué versión LTS debería migrar en 2026?

Node.js 22 o Node.js 24, ambas con LTS activo. Para migraciones urgentes desde 18 o 20, Node.js 22 ofrece la menor fricción por alta compatibilidad de APIs. Para proyectos nuevos o con margen de tiempo, Node.js 24 es preferible por tener más vida útil (EOL estimado octubre 2027 vs abril 2027 de Node.js 22).

¿Qué riesgos tiene usar Node.js fuera de soporte en producción?

El riesgo principal es la acumulación de vulnerabilidades sin parche: cualquier CVE nueva en el runtime, el motor V8, o los módulos core no recibe fix oficial. A esto se suman los riesgos de las dependencias bundleadas (OpenSSL, libuv) que tampoco se actualizan. En términos de compliance, correr un runtime EOL es una observación automática en auditorías SOC 2, PCI DSS, e ISO 27001.

¿Existe soporte de seguridad para versiones EOL de Node.js?

Sí, de terceros. HeroDevs ofrece su programa Never-Ending Support (NES) con backports de parches críticos para versiones EOL incluyendo 14, 16, 18 y 20. NodeSource tiene una oferta similar. Estas opciones son para equipos con restricciones de migración, no un reemplazo permanente: el costo y la cobertura son inferiores al soporte oficial, y la deuda técnica no desaparece.

Conclusión

El 30 de abril de 2026 no fue una fecha teórica: Node.js 20 llegó a EOL y ahora está en la misma categoría que Node.js 14, 16 y 18. Si tu producción corre cualquiera de esas versiones, el riesgo de seguridad es real y acumulativo.

La migración a Node.js 22 o 24 es el paso concreto. Para la mayoría de los proyectos que vienen de 18 o 20, la compatibilidad es alta y el trabajo es manejable. El obstáculo real suele ser burocrático: aprobaciones internas, equipos sobrecargados, sistemas legacy con dependencias complicadas. Para esos casos, el soporte comercial de HeroDevs o NodeSource compra tiempo, aunque no resuelve el problema de fondo.

Si manejás infraestructura Node.js en donweb.com o en cualquier entorno de producción, este es el momento de auditar versiones, actualizar Dockerfiles y ajustar los engines en package.json. La próxima ventana de EOL para Node.js 22 es abril de 2027: suficiente tiempo para planificar bien la siguiente migración sin apuro.

Fuentes

• Node.js — Calendario oficial de End-of-Life (OpenJS Foundation)
• endoflife.date — Estado actualizado de todas las versiones Node.js
• endoflife.ai — Análisis completo del schedule EOL de Node.js (mayo 2026)
• HeroDevs — Node.js EOL dates y opciones de soporte extendido
• Node.js — Security releases marzo 2026