Qué cambia realmente el fin de vida de Node.js 20
Node.js sigue un ciclo público: una línea par entra en Active LTS en octubre, pasa a Maintenance LTS un año más tarde y después se detiene. Node.js 20 entró en Maintenance LTS el 22 de octubre de 2024 y alcanzó su fin de vida el 30 de abril de 2026. Desde entonces, un fallo del runtime ya no se corrige aguas arriba: ni en el motor V8, ni en la biblioteca TLS integrada, ni en el analizador HTTP. El código sigue funcionando, pero cada vulnerabilidad publicada permanece abierta.
Lo que cuesta un runtime congelado
- Fallos sin corregir — las vulnerabilidades publicadas después del 30 de abril de 2026 ya no recibirán parche aguas arriba; solo una subida de versión las cierra.
- Paquetes que se descuelgan — los mantenedores elevan el campo
enginesde supackage.jsonhacia las líneas todavía soportadas; una instalación nueva acaba fallando o dejándole anclado en versiones antiguas. - Imágenes base inmóviles — una imagen
node:20ya no recibe parches, ni para el runtime ni para los paquetes de sistema que hay debajo; su análisis de vulnerabilidades lo señala en cada build. - Auditorías que se atascan — un runtime en fin de vida es un riesgo no aceptado en las revisiones de seguridad y en los cuestionarios de proveedores.
- Migración de urgencia — cuanto más crece la brecha, más cara sale la transición; llevarla a cabo hoy es un proyecto planificado, sufrirla tras un incidente ya no lo es.
Saber qué ejecutan realmente sus servidores
node -v en un shell solo cuenta una parte de la historia: el binario de su sesión no es necesariamente el que sirve la producción. Un gestor de procesos conserva la versión con la que arrancó, nvm instala varias por usuario, un Dockerfile fija la suya en un FROM node:20. Inventaríe cada fuente: pm2 jsonlist para los procesos vivos, un grep -r 'FROM node' sobre sus Dockerfiles, el campo engines de cada package.json y la versión fijada en la CI o en sus runtimes gestionados.
Migrar sin romper la producción
Levantar el inventario antes de tocar nada más
Enumere, aplicación por aplicación: la versión realmente ejecutada, el gestor de procesos, la imagen base y las dependencias nativas —
node-gyp,sharp,better-sqlite3. Son ellas las que fijan el calendario, no su código: un módulo compilado sin binario listo para la nueva línea bloquea toda la transición.Elegir la versión de destino
Node.js 24 está en Active LTS desde el 28 de octubre de 2025 y su fin de vida está fijado al 30 de abril de 2028: es el destino por defecto. Node.js 22, en Maintenance LTS desde el 21 de octubre de 2025, tiene soporte hasta el 30 de abril de 2027 — un escalón aceptable si una dependencia nativa aún no sigue el ritmo, nunca un destino. Node.js 26 no entra en LTS hasta el 28 de octubre de 2026: hoy, no en producción.
Reproducir la suite de pruebas en la versión de destino
Añada la versión de destino a la matriz de su CI antes de retirar la antigua: ambas deben ponerse en verde al mismo tiempo. Reinstale en frío (
rm -rf node_modulesy despuésnpm ci) para forzar la recompilación de los módulos nativos: ahí es donde aparecen las rupturas, rara vez en las pruebas unitarias. Lea los avisos de obsolescencia — son los errores de la línea siguiente.Cambiar un servicio cada vez
nvm install 24instala la nueva línea junto a la antigua sin retirarla. Reinicie después el daemon del gestor de procesos (pm2 update) y vuelva a crear el servicio (pm2 deletey luegopm2 start): un simplepm2 restartconserva el intérprete registrado. Regenere el script de arranque (pm2 startup,pm2 save) y compruebe conpm2 jsonlistque la versión reportada ha cambiado.Vigilar y después limpiar
Mantenga los logs de error y la curva de memoria a la vista durante 48 horas: un cambio de línea de V8 desplaza el perfil del recolector de basura más a menudo de lo que rompe una API. Una vez confirmada la transición, desinstale Node.js 20 para que ningún despliegue lo vuelva a invocar por accidente. Si prefiere partir de un servidor limpio en lugar de migrar en sitio, nuestra guía
deployer-nodejs-vpsrecorre la cadena completa.
Fijar la versión, no solo migrarla
Una subida de runtime es el buen momento para apretar lo que la rodea. Fije la versión de destino en un .nvmrc versionado junto al código y alinee el campo engines de su package.json: el servidor, la CI y los puestos de desarrollo dejan de divergir en silencio — es esa deriva la que permite que un runtime en fin de vida sobreviva a su propia migración. Ejecute la aplicación con un usuario dedicado, sin permiso de escritura sobre su carpeta de código.
Convertir el fin de vida en una cita, no en una sorpresa
El calendario de Node.js es público: una línea par pasa a LTS en octubre y se detiene treinta meses más tarde, siempre un 30 de abril. Node.js 22 se detendrá el 30 de abril de 2027 y Node.js 24 el 30 de abril de 2028: ambas fechas pueden entrar hoy mismo en su calendario de explotación. Recurrente y presupuestada, la subida de versión ocupa unos pocos días al año; sufrida con urgencia, cuesta mucho más.
