Node.js 26 pasa a LTS: qué versión usar en tus desarrollos

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:

  1. Inventariar qué aplicaciones usan Node.js y en qué versión, incluidas las herramientas internas y los procesos de compilación de webs.
  2. Fijar la versión en cada proyecto y en sus contenedores, para que no cambie sin querer.
  3. Reservar cada otoño, cuando sale la nueva LTS, una revisión de dependencias y pruebas, y presupuestarla como parte del mantenimiento.
  4. 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

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.

About the author

Juanjo Bastarrika es CEO de Binovo, empresa de Oiartzun (Gipuzkoa) que desde 2008 implanta Odoo, soluciones de facturación Verifactu y TicketBAI, sistemas y desarrollo a medida, y del Grupo Binovo, al que pertenece Future AI, especializada en inteligencia artificial aplicada. Escribe sobre ERP, normativa fiscal e IA en la empresa desde la experiencia de implantación con clientes.

Leave a Reply