Node.js, Docker y Go: tres cambios silenciosos que pueden romper tu pipeline

Lo que cambió sin que tu pipeline se enterara

Algunos de los fallos más frustrantes tras una actualización vienen de cambios pequeños que nadie había previsto. Un valor predeterminado cambia. Pasa una fecha de fin de soporte. Un número de versión significa algo distinto que el año pasado.

Ilustración conceptual generada con IA de un pipeline con tres módulos enlazados. No es un diagrama de ningún sistema ni producto real.

En las dos últimas semanas llegaron tres cambios de este tipo. Node.js está cambiando cómo numera y da soporte a sus versiones. Docker Desktop cambió cómo almacena por defecto los registros (logs) de los contenedores. Y Go 1.25 dejó de recibir correcciones de seguridad justo cuando se publicó un gran lote de ellas.

Ninguno es una crisis. Cada uno es fácil de pasar por alto, y cada uno se comprueba en poco tiempo.

Los tres tienen algo en común: las fechas de soporte y los valores predeterminados. Una herramienta que no has tocado puede cambiar igualmente, porque aquello de lo que depende se movió. Este artículo repasa cada cambio por separado, explica a quién afecta y termina con una breve lista de comprobación.

Node.js: entra en vigor un nuevo modelo de versiones

El proyecto Node.js anunció a principios de este año un nuevo calendario de versiones, con una versión principal al año en lugar de dos. Ese cambio empieza ahora a aplicarse. Node.js 26 es la última versión del modelo antiguo. A partir de la versión 27 habrá una versión principal cada abril, y todas las versiones pasarán a ser de soporte a largo plazo (LTS).

LTS significa que el proyecto se compromete a seguir corrigiendo errores graves y problemas de seguridad durante mucho tiempo. Con el modelo antiguo, solo las versiones pares tenían LTS, y las impares duraban poco. Muchos equipos se saltaban las impares, pero los voluntarios que mantienen Node.js tenían que darles soporte igualmente.

El nuevo modelo elimina la división entre pares e impares. Además, los números de versión coincidirán con el año: la 27.0.0 llega en 2027, la 28.0.0 en 2028.

También hay una nueva fase de pruebas tempranas llamada Alpha. Cada versión futura pasará seis meses en Alpha, después seis meses como Current y luego 30 meses en LTS. Las compilaciones Alpha llevan nombres como 27.0.0-alpha.1. Están pensadas para pruebas, no para producción, y el proyecto advierte que su comportamiento puede cambiar de una compilación a otra.

Durante las próximas semanas, las fechas importan más que el modelo. Proceden del calendario de versiones de Node.js:

Líneas de versiones de Node.js y las fechas en que entran en soporte a largo plazo (LTS), en mantenimiento y en fin de vida, según el calendario de versiones de Node.js

Versión	Entra en LTS	Entra en mantenimiento	Fin de vida
22	29 oct. 2024	21 oct. 2025	30 abr. 2027
24	28 oct. 2025	20 oct. 2026	30 abr. 2028
26	28 oct. 2026	20 oct. 2027	30 abr. 2029

El mantenimiento (Maintenance) es la última fase antes del fin de vida. Una versión en mantenimiento sigue recibiendo correcciones críticas, pero el trabajo nuevo se detiene. Node.js recomienda que las aplicaciones en producción usen solo una versión en Active LTS o en mantenimiento, así que Node.js 24 sigue siendo una opción segura el 20 de octubre.

Según mi lectura de este calendario, durante ocho días, del 20 al 28 de octubre, ninguna línea de Node.js está en Active LTS. Node.js 22 y 24 están ambas en mantenimiento, y Node.js 26 sigue siendo Current. Eso no es un problema en sí. Pero sí significa que quien diga «usa la Active LTS y ya está» tiene que esperar hasta el 28 de octubre para tener una respuesta clara.

Qué hacer. Si usas Node.js 24 en producción, no tienes problema, pero empieza a planificar el paso a la 26 cuando se convierta en Active LTS el 28 de octubre. Si usas Node.js 22, ten en cuenta que su soporte termina el 30 de abril de 2027. Si mantienes una biblioteca, añade pronto la línea Alpha a tus pruebas. El propio proyecto advierte que, si solo pruebas con LTS, te enterarás de los errores después que tus usuarios.

Docker Desktop: cambió el controlador de registro predeterminado

Este es el cambio con más probabilidades de dar una sorpresa, así que recibe más espacio.

Todo contenedor escribe mensajes en su salida. Docker almacena esos mensajes mediante un controlador de registro (logging driver). Durante años, el predeterminado en la mayoría de las configuraciones fue json-file, que escribe cada mensaje como una línea de JSON en un archivo de texto plano.

Ese archivo crece sin límite salvo que le pongas uno. Los recolectores de logs, que son programas que leen los registros de los contenedores y los envían a otro lugar, suelen leer estos archivos directamente.

Docker Desktop 4.94, publicado el 5 de octubre, cambió el predeterminado de los nuevos contenedores Linux a un controlador llamado local. Las notas de la versión dan el motivo: habilitar la rotación automática de registros. La rotación significa que los registros antiguos se eliminan o se comprimen para que no llenen el disco. Por defecto, local conserva hasta cinco archivos de 20 MB cada uno y comprime los más antiguos, lo que supone unos 100 MB por contenedor.

Es razonable, pero el controlador local no almacena los registros con la misma forma. La propia documentación de Docker dice que sus archivos están diseñados para que los use únicamente el daemon de Docker, y advierte que las herramientas externas que los toquen pueden interferir. Los archivos están en un formato binario, no en líneas JSON.

Una prueba de terceros muestra lo que esto puede suponer para un recolector que lee archivos. El equipo de DevOps Daily ejecutó Fluent Bit, un recolector de logs muy utilizado, con su configuración estándar para archivos de registro de Docker. Con contenedores json-file sin límite de tamaño leyó las 500 000 líneas de prueba. Con contenedores local no leyó ninguna, porque su patrón de archivos habitual no coincide con los archivos que escribe el controlador local.

Cuando lo apuntaron directamente al archivo de local, leyó registros, pero no pudo decodificar ninguno. Se trata de una sola prueba ejecutada en Docker Engine 29.9.0 sobre una Raspberry Pi, no en Docker Desktop, y solo abarcó Fluent Bit. No se probaron los recolectores que leen los registros a través de la API de Docker en lugar de hacerlo desde archivos.

Ya ha aparecido en el código un segundo tipo de fallo. La biblioteca de Docker para Python no devuelve nada desde containers.run() cuando el contenedor usa el controlador local, porque solo lee la salida con json-file y con otro controlador más. Una herramienta llamada DataHub se topó con esto en su comprobación de configuración y, como solución provisional, fijó json-file para su contenedor de corta duración. Se ha propuesto una corrección en la biblioteca.

Los afectados son sobre todo desarrolladores con Docker Desktop 4.94 o posterior cuya configuración local reproduce un pipeline de registros de producción. Los servidores que ejecutan Docker Engine no cambian con esta versión.

Además, el cambio solo se aplica a los contenedores nuevos. Los contenedores que ya tienes conservan el controlador con el que se crearon hasta que los vuelvas a crear.

Qué comprobar. Ejecuta esto para ver el predeterminado en tu máquina:

docker info --format '{{.LoggingDriver}}'

Y esto para ver el controlador de cada contenedor que ya tienes:

docker ps -aq | xargs docker inspect --format '{{.Name}} {{.HostConfig.LogConfig.Type}}'

Si encuentras local y tu recolector lee archivos de registro, tienes dos opciones. Puedes cambiar a un recolector que lea a través de la API de Docker. O puedes configurar json-file con un límite de tamaño, lo que mantiene el formato de archivo antiguo. Eso sí, el límite descarta las líneas más antiguas:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Configúralo en los ajustes del daemon de Docker y luego vuelve a crear tus contenedores para que lo apliquen. Para un solo servicio, puedes definir las mismas opciones en un archivo de Compose.

Una breve nota sobre otra versión distinta. Docker Engine 29.9.1, publicado el 14 de octubre, es una actualización independiente de Docker Desktop 4.94. Actualiza containerd, el componente que ejecuta los contenedores, a la versión 2.4.2.

Eso corrige un fallo que hace caer containerd al descargar una imagen cuyo descriptor lleva un digest de anotación mal formado (CVE-2026-95839), y otros dos problemas que un registro hostil podría aprovechar para hacer caer containerd o llenar un disco. Si ejecutas Docker Engine en servidores, esa es la actualización que debes programar.

Go: la versión 1.25 ya no recibirá correcciones

El 8 de octubre, el equipo de Go publicó las versiones 1.27.2 y 1.26.9. Entre las dos corrigen 15 problemas de seguridad. La mayoría están en el código de servidor y cliente web de la biblioteca estándar, en net/http. El anuncio de Go enumera ocho ahí, y otros en crypto/tls, el comando go, las plantillas HTML, el análisis de texto y de contenido multipart, y uno para Windows.

El que más equipos van a oír mencionar es CVE-2026-97032. En un servidor HTTP/2, dos partes del código modificaban la misma tabla al mismo tiempo sin coordinarse. Un cliente hostil puede aprovecharlo para hacer caer el servidor. Una caída provocada por un cliente remoto se llama denegación de servicio.

Lo notificó RyotaK, de GMO Flatt Security. La corrección está en Go 1.26.9, en Go 1.27.2 y en la versión 0.60.0 del paquete golang.org/x/net para los programas que usan directamente su código HTTP/2.

Go da soporte a cada versión principal hasta que existen dos versiones principales más recientes. Go 1.27.0 se publicó el 19 de agosto, así que Go 1.25 queda ahora fuera de ese periodo. Su última versión lleva la misma fecha. Eso significa que estas correcciones no se incorporarán a Go 1.25.

El registro de la vulnerabilidad no dice si Go 1.25 está afectado por el problema de HTTP/2. No necesitas averiguarlo. Un servicio con un runtime sin soporte tampoco recibirá correcciones para el próximo problema.

Dos advertencias antes de actualizar. Algunas de estas correcciones cambian el comportamiento a propósito:

• El cliente y el servidor HTTP/1 ahora cierran la conexión después de cualquier solicitud CONNECT.
• El proxy inverso de net/http/httputil ahora responde a las solicitudes CONNECT entrantes con 405 Method Not Allowed.
• Las funciones auxiliares integradas para servir archivos ahora ignoran las solicitudes con más de 200 rangos de bytes en un encabezado Range. Un ajuste llamado GODEBUG=httpservecontentmaxranges=0 desactiva este comportamiento.

Si ejecutas proxies o cualquier cosa que maneje CONNECT, haz pruebas después de actualizar. Para todos los demás, es una actualización rutinaria.

Qué comprobar. Ejecuta go version en tus máquinas de compilación y en tus imágenes de contenedor. Si indica 1.25 o una versión anterior, planifica la migración. Si puedes, ejecuta la herramienta govulncheck de Go sobre tu código: solo informa de los problemas conocidos a los que tu código llama realmente.

Cuánto necesitas saber

Conocer. Todo desarrollador debería saber que las fechas de soporte y los valores predeterminados cambian, y que existen estos tres cambios. No necesitas los detalles de cada uno.

Usar. Quienes son responsables de un pipeline, una imagen base o un runtime necesitan un conocimiento práctico. Eso significa saber qué línea de Node.js usas, qué controlador de registro de Docker usan tus contenedores y con qué versión de Go se compilaron tus servicios.

Dominar. Los responsables de plataforma que definen la política de versiones para muchos equipos necesitan entender los compromisos. Eso incluye cuánto tiempo quedarse en una versión en mantenimiento, cuándo fijar un valor predeterminado para que no pueda cambiar y cómo probar pronto con compilaciones Alpha o candidatas a versión final (release candidate).

Qué puedes ignorar por ahora

Puedes saltarte la Alpha de Node.js 27 salvo que mantengas una biblioteca. Puedes saltarte los detalles de cada problema de Go salvo que ejecutes servidores HTTP/2 expuestos a internet. Y puedes ignorar los cambios de registros de Docker si tus contenedores se ejecutan en Docker Engine y tus registros ya pasan por la API de Docker.

Qué hacer a continuación

Elige las tres líneas que te correspondan y ejecútalas esta semana:

• node -v, y compara el resultado con la tabla anterior.
• docker info --format '{{.LoggingDriver}}', y revisa tu recolector.
• go version, y busca 1.25 o una versión anterior.

Si tu equipo no tiene una lista de las versiones de runtime que usa, ese es el verdadero hallazgo. Una tabla breve de «qué usamos y cuándo termina» detectará el próximo cambio silencioso antes de que te sorprenda a ti.

Para seguir leyendo, consulta GitHub Actions está cambiando (en inglés), que trata otro cambio de plataforma que afecta a los pipelines, y OpenTelemetry: por qué importa ser dueño del canal de telemetría, que analiza hacia dónde deberían fluir los registros y las demás señales.

Para profundizar

• Evolving the Node.js Release Schedule, proyecto Node.js. La descripción oficial del nuevo modelo. Consultado el 18 de octubre de 2026.
• Node.js release schedule, Node.js Release Working Group. La fuente de las fechas de la tabla anterior. Consultado el 18 de octubre de 2026.
• Node.js previous releases, proyecto Node.js. La recomendación de que las aplicaciones en producción usen solo versiones Active LTS o Maintenance LTS. Consultado el 18 de octubre de 2026.
• Docker Desktop release notes, Docker. Versión 4.94.0, 5 de octubre de 2026. Consultado el 18 de octubre de 2026.
• Local file logging driver, documentación de Docker. Valores predeterminados y la nota sobre el acceso exclusivo del daemon. Consultado el 18 de octubre de 2026.
• Docker Engine 29.9.1 release, proyecto Moby. La actualización de containerd y las correcciones de seguridad. Consultado el 18 de octubre de 2026.
• docker-py issue 3455, proyecto docker-py. containers.run() devuelve None con el controlador local; abierta el 13 de octubre de 2026, con una corrección de una línea en la pull request 3456. Consultado el 18 de octubre de 2026.
• DataHub pull request 20403, proyecto DataHub. Fija el controlador json-file para el contenedor de comprobación de configuración; fusionada el 13 de octubre de 2026. Consultado el 18 de octubre de 2026.
• Moby local logger documentation, proyecto Moby. Describe los registros codificados con protobuf que escribe el controlador local. Consultado el 18 de octubre de 2026.
• Go release history, proyecto Go. Las versiones 1.27.2 y 1.26.9, y la política de soporte. Consultado el 18 de octubre de 2026.
• Go 1.27.2 and Go 1.26.9 security announcement, equipo de Go, publicado el 8 de octubre de 2026. Las 15 correcciones de seguridad y los cambios de comportamiento. Consultado el 18 de octubre de 2026.
• GO-2026-6617 (CVE-2026-97032), base de datos de vulnerabilidades de Go. La condición de carrera en la tabla de HTTP/2 y las versiones corregidas. Consultado el 18 de octubre de 2026.
• docker-log-driver-check, DevOps Daily. La prueba de terceros con Fluent Bit descrita más arriba. Una sola ejecución, en Docker Engine. Consultado el 18 de octubre de 2026.