Node.js 26 entra en LTS el 28 de octubre: qué cambia y cómo migrar sin romper el CI
El 28 de octubre de 2026 Node.js 26 deja de ser la versión Current y pasa a LTS, justo cuando Node 20 ya está sin soporte y Node 24 entra en mantenimiento. Qué cambia en Node.js 26 LTS, qué se rompe y cómo migrar sin romper el CI.
Las fechas que importan antes de tocar nada
Este post no va de novedades: va de fechas y de cosas que se rompen. Antes de cambiar un número en el Dockerfile conviene tener claro qué significa cada etiqueta del calendario.
Qué significa que Node.js 26 pase a LTS el 28 de octubre de 2026
Todas las versiones nuevas salen primero como "Current": están disponibles, pero esa etiqueta no dice "esto es lo que debes correr en producción". Seis meses después, las versiones pares pasan a LTS, que es cuando el proyecto garantiza arreglos y recomienda el salto. El 28 de octubre de 2026 le toca a Node 26: ese es el momento de migrar, no antes.
Node 20 sin soporte desde abril, Node 24 en mantenimiento desde octubre
El calendario oficial del proyecto (el archivo schedule.json del repositorio nodejs/Release) fija tres fechas. Node 20 acabó su vida útil el 30 de abril de 2026: ya no recibe parches, ni de seguridad. Node 24 entra en mantenimiento el 20 de octubre de 2026, una semana antes del cambio de Node 26: recibirá arreglos críticos, pero deja de ser la línea activa. Node 26 nació el 5 de mayo de 2026 con la Temporal API activada por defecto, V8 14.6 y Undici 8.
Lee también
Hasta cuándo tendrás parches en Node 26
Node 26 entra en mantenimiento el 20 de octubre de 2027 y termina su ciclo el 30 de abril de 2029: unos 30 meses de soporte desde que sea LTS. Hay blogs que dicen "mayo de 2029"; la fecha que manda es la del calendario oficial.
El cambio de modelo: desde Node 27, una versión mayor al año y todas LTS
Node 26 es la última versión del modelo antiguo. A partir de Node 27 el proyecto publica una versión mayor por año y todas serán LTS. Node 27 entra en fase alpha el 28 de octubre de 2026 y su versión final está prevista para el 22 de abril de 2027. La consecuencia práctica: "esperar a la siguiente" deja de tener sentido, porque ya no habrá versiones impares de usar y tirar.
Qué trae Node.js 26 que vas a notar
Temporal activado por defecto: se acabaron el flag y el polyfill
La Temporal API ya no necesita bandera ni polyfill: viene puesta. Si quieres el detalle de cómo usarla y cómo migrar desde Date, el blog ya tiene una guía práctica de la Temporal API en JavaScript. Aquí basta con saber que en Node 26 está disponible sin configurar nada.
V8 14.6 y Undici 8: qué cambia por debajo
V8 14.6 es el motor de JavaScript: trae métodos nuevos del lenguaje sin que actualices nada. Undici 8 es el cliente HTTP que sostiene fetch: si tu código depende de detalles finos de comportamiento HTTP, conviene probarlo, porque un cambio de versión mayor en el cliente se nota en los bordes.
Utilidades nuevas: Map.upsert, Iterator.concat y los helpers de util
La línea 26 fue sumando utilidades en sus versiones menores: Map.upsert para escribir o crear una entrada de un tirón, Iterator.concat para unir iteradores sin materializar arrays, y helpers como util.throttle() y util.debounce() que antes había que traer de una librería. También aparecieron crypto.parsePKCS12(), fs.openAsBlobSync() y un histograma nuevo en perf_hooks.
node:ffi: llamar a librerías nativas sin escribir un addon (experimental)
node:ffi permite llamar a librerías dinámicas desde JavaScript sin escribir un addon compilado. Llegó en la línea 26 detrás de una bandera y en 26.9.0, publicado el 16 de septiembre de 2026, pasó a estar activado por defecto. El mensaje honesto: sirve para prototipos y sigue siendo experimental, no es base para producción crítica, y con el Permission Model activo hay que conceder permiso explícito a FFI.
Lo que se rompe: APIs eliminadas y deprecadas
Eliminaciones: writeHeader() y la limpieza de APIs heredadas
Node 26 limpió APIs que llevaban varias versiones mayores avisando. El ejemplo más citado en las notas de la versión es http.Server.prototype.writeHeader(), que ya no existe: la alternativa es writeHead(). También desaparecieron módulos internos de streams que se usaban por accidente. La lista completa se confirma contra la documentación oficial de Node 26, no de memoria.
Avisos de deprecación que ya verás en los logs (url.parse y compañía)
Hay avisos que no rompen nada pero ensucian los registros. El caso típico es DEP0169, la deprecación de url.parse(), que se activa en runtime y aparece incluso cuando quien llama es una dependencia y no tu código.
Por qué un aviso de hoy es una rotura mañana
La deprecación es el único aviso previo que vas a recibir: primero sale un warning, después el comportamiento se estandariza y en una versión mayor la función desaparece. Limpiar los avisos hoy evita el writeHeader is not a function de la próxima migración.
El punto que más rompe: módulos nativos y dependencias
Qué es un binario precompilado y por qué depende de la versión de Node
Un módulo nativo es una parte del paquete escrita en C, C++ o Rust que se compila contra una versión concreta del runtime. Muchos mantenedores publican binarios ya compilados (prebuilds) para las versiones con soporte. Si no hay prebuild para la línea 26, tu instalación tendrá que compilar el módulo al desplegar, y ahí aparecen los fallos: falta una cabecera, cambia un símbolo, la imagen no trae herramientas de compilación. Todo lo que toque base de datos, criptografía, compresión o imágenes es sospechoso por defecto.
Cómo detectar el problema antes de desplegar
Revisa qué dependencias traen binarios y quién los publica:
npm ls --depth=0
npm ls --all | grep -i -E "node-gyp|prebuild|nan"Busca también el campo engines en el package.json de cada dependencia: si declara un rango que excluye Node 26, ya sabes que hay trabajo pendiente. Y prueba siempre en un contenedor limpio, sin la caché de compilación de tu máquina: en local puede compilar y en el servidor no.
Checklist de migración paso a paso
Paso 1: inventario de dónde vive la versión de Node
- El campo
enginesdelpackage.json. - El archivo de versión:
.nvmrc,.node-versiono la configuración de Volta. - La imagen base del
Dockerfile. - Las matrices de los workflows de CI.
- El panel de la plataforma donde corras el servicio (hosting gestionado, serverless).
Paso 2: probar Node 26 en local con nvm, fnm o Volta
- Instala la versión junto a la actual y cambia solo en la carpeta del proyecto.
- Corre la suite de tests y el build.
- Lee los avisos de deprecación de la salida: son el aviso temprano de lo que romperá después.
nvm install 26
nvm use 26
node -v
npm testPaso 3: revisar dependencias, engines y lockfile
- Actualiza lo que declare
enginesincompatible o no lo declare en absoluto. - Comprueba los módulos nativos y busca si ya hay prebuild para 26.
- Regenera el lockfile a conciencia: si lo tocas, revisa el diff antes de subirlo.
Paso 4: CI, Docker y el runtime de las actions
Aquí está la sorpresa que se lleva mucha gente. GitHub Actions retiró Node 20 de sus runners a finales de septiembre de 2026 y las JavaScript Actions corren sobre Node 24: es un runtime distinto del que usan tus pasos de run:, y se controla aparte. Fija la versión en la matriz y súbela también en tus pruebas, para que CI y producción no corran runtimes distintos.
- uses: actions/setup-node@v4
with:
node-version: 26Si montaste el pipeline con Laravel y GitHub Actions, el tutorial de CI/CD con GitHub Actions te sirve de base para los workflows.
Paso 5: despliegue canary, métricas y plan de rollback
- Despliega una instancia o un porcentaje del tráfico con la versión nueva.
- Mide tasa de error, latencia p95 y consumo de memoria durante un ciclo completo.
- Escribe el rollback antes de necesitarlo: volver a la imagen anterior y congelar la versión.
Errores que verás y cómo se arreglan
writeHeader is not a function
Alguien en tu cadena de dependencias llama a una API que ya no existe. Búscala en tu código y en las dependencias, y migra a writeHead(); si viene de una librería, actúlizala o cámbiala.
Logs llenos de DEP0169 (y por qué puede no ser tu código)
El aviso de url.parse() suele llegar desde una dependencia. Localiza el paquete en el stack del warning y actúlizalo; si el mantenedor no ha migrado, valora sustituirlo.
Módulo nativo que no compila en la versión nueva
Es el fallo más previsible. Antes de forzar la compilación en el servidor, busca una versión del paquete con prebuild para 26 o compila dentro de la propia imagen de Docker, con las herramientas presentes.
Plataformas que todavía no ofrecen Node 26
En entornos gestionados la decisión no es tuya: quédate en la LTS más reciente que ofrezcan. Node 24 sigue soportado y es una opción válida mientras esperas.
Conclusión: cuándo migrar y cuándo esperar
El salto es urgente si sigues en Node 20: llevas desde abril sin parches de seguridad. Si estás en Node 22 o 24 tienes margen, y ese margen sirve para lo que importa: probar las dependencias con módulos nativos sin presión. La recomendación práctica es migrar poco después del 28 de octubre y no el mismo día, para que el ecosistema publique prebuilds y las plataformas gestionadas suban la versión. Si un módulo crítico no está listo, esperar es la decisión correcta, no una derrota. Y si quieres profundizar en lo que trae el lenguaje con este runtime, en el blog tienes la guía de la Temporal API para empezar por la parte que ya puedes usar hoy.
