Según el calendario oficial del proyecto, Node.js 26 pasa a ser versión LTS (soporte a largo plazo) el 28 de octubre de 2026. Una semana antes, el 20 de octubre, Node.js 24 entró en fase de mantenimiento, en la que solo recibe correcciones de seguridad y errores críticos, y Node.js 20 está fuera de soporte desde el 30 de abril. A la vez cambia la forma de publicar versiones: Node.js 26 es la última del modelo antiguo y a partir de ahora habrá una sola versión mayor al año, y todas serán LTS. Afecta a cualquier empresa con aplicaciones, APIs, paneles web o automatizaciones que funcionen sobre Node.js.
Cómo queda cada versión
| Versión | Situación a 22/10/2026 | Fin de soporte |
|---|---|---|
| Node.js 20 | Sin soporte | 30/04/2026 |
| Node.js 22 | Mantenimiento desde el 21/10/2025 | 30/04/2027 |
| Node.js 24 | Mantenimiento desde el 20/10/2026 | 30/04/2028 |
| Node.js 26 | Current; pasa a LTS el 28/10/2026 y a mantenimiento el 20/10/2027 | 30/04/2029 |
| Node.js 27 | Fase alfa prevista desde el 28/10/2026; versión 27.0.0 en abril de 2027 | 30/04/2030 |
Las fechas proceden del fichero schedule.json del repositorio oficial nodejs/Release y coinciden con las que recoge endoflife.date, que el 22 de octubre listaba como últimas versiones la 26.12.1, la 24.22.1 y la 22.23.4, publicadas el 21 de octubre.
Qué cambia con el nuevo calendario
Hasta ahora, Node.js publicaba dos versiones mayores al año y solo las pares llegaban a LTS. El anuncio oficial, actualizado por última vez el 10 de marzo de 2026, describe el nuevo esquema a partir de octubre de 2026:
- Una versión mayor al año, en abril, que se promociona a LTS en octubre.
- Todas las versiones serán LTS. Desaparece la diferencia entre pares e impares: Node.js 27 será LTS.
- Nuevo canal alfa de seis meses para pruebas tempranas, seguido de seis meses como versión Current y 30 meses de LTS. En total, unos 36 meses de vida desde la primera versión Current.
- El número coincide con el año: 27.0.0 en 2027, 28.0.0 en 2028.
- Se mantienen la duración del LTS, el solapamiento entre versiones para migrar y el proceso de seguridad.
El propio proyecto avisa de que el calendario puede ajustarse, así que conviene consultar schedule.json antes de fijar fechas en un plan.
Qué versión usar en cada caso
- Proyecto nuevo que va a producción en las próximas semanas o meses: Node.js 26, una vez que sea LTS. Es la que más vida tiene por delante.
- Aplicaciones en Node.js 24: no hay urgencia, tienen parches hasta abril de 2028, pero conviene incluir la migración en el plan del próximo año.
- Aplicaciones en Node.js 22: les quedan unos seis meses de parches. Es el momento de planificar y probar el salto.
- Aplicaciones en Node.js 20 o anteriores: ya no reciben correcciones de seguridad. Son la prioridad.
- Alfa y Current, solo para probar. En producción, únicamente versiones LTS activas o en mantenimiento.
Y si usas n8n
Las automatizaciones con n8n también funcionan sobre Node.js. La documentación de n8n indica que, si se instala con npm, eres tú quien gestiona las versiones de Node.js, y que ese método queda obsoleto a partir de n8n 3.0; recomienda Docker Compose. En la práctica, con una instalación en contenedor la versión de Node.js viene dentro de la imagen, de modo que mantener n8n actualizado es la mejor forma de no quedarse en una versión sin soporte.
Cómo lo vemos en Binovo
Lo mejor del nuevo calendario es que vuelve predecible el mantenimiento. Para una empresa de Gipuzkoa con una aplicación a medida o varias automatizaciones, eso permite tratar la actualización de Node.js como una tarea anual más, igual que la revisión de copias de seguridad o la renovación de certificados, en lugar de un imprevisto cuando una versión se queda sin parches.
Lo que recomendamos a nuestros clientes:
- Inventariar qué aplicaciones usan Node.js y en qué versión, incluidas las herramientas internas y los procesos de compilación de webs.
- Fijar la versión en cada proyecto y en sus contenedores, para que no cambie sin querer.
- Reservar cada otoño, cuando sale la nueva LTS, una revisión de dependencias y pruebas, y presupuestarla como parte del mantenimiento.
- No saltar a la última versión el primer día: esperar a que sea LTS y a que las librerías que usas la soporten.
Es la misma filosofía que aplicamos con Odoo y con el resto de la plataforma: versiones estables y con soporte, sin prisas por estrenar ni descuidos que dejen sistemas sin parches.
Si quieres revisar tus aplicaciones, en desarrollo de software nos ocupamos de su mantenimiento y evolución. Para las automatizaciones, nuestro servicio de automatización con n8n se apoya en Future AI, empresa del Grupo Binovo y Expert Partner de n8n. Y si tienes dudas sobre tu caso, escríbenos.
Fuentes
- Node.js: Evolving the Node.js Release Schedule (actualizado el 10/03/2026)
- GitHub nodejs/Release: schedule.json, calendario oficial de versiones (consultado el 22/10/2026)
- endoflife.date: Node.js (actualizado el 22/10/2026)
- n8n Docs: Hosting n8n (consultado el 22/10/2026)
Transparencia: este artículo se ha elaborado con ayuda de inteligencia artificial a partir de las fuentes citadas y ha sido revisado y validado por el equipo de Binovo antes de publicarse.
