GitHub fijó el 23 de septiembre de 2026 como la fecha en la que Node 20 será eliminado de los runners de GitHub Actions. El plazo importa porque las JavaScript actions no usan necesariamente la versión de Node que el workflow instala para la aplicación: se ejecutan con el runtime incluido en el propio runner, según el campo runs.using de los metadatos de la action. Desde el 16 de junio de 2026, Node 24 ya es el valor predeterminado para estas actions; el 23 de septiembre, Node 20 dejará de existir como opción en el runner.
En la práctica, el riesgo no se limita a los workflows que mencionan “Node 20” de forma explícita. Un archivo YAML puede parecer actualizado y seguir llamando a una action antigua cuyo action.yml declara node20. Por eso, la auditoría debe localizar dependencias de actions, probar el conjunto completo con Node 24 y corregir runners incompatibles antes del corte.
Qué cambia el 23 de septiembre
El calendario oficial de GitHub se ajustó varias veces. La nota editorial del 25 de agosto de 2026 movió la fecha final de eliminación al 23 de septiembre. Node 20, por su parte, llegó al fin de vida en el proyecto Node.js el 30 de abril de 2026. GitHub empezó a usar Node 24 de forma predeterminada el 16 de junio y mantuvo una vía de escape temporal para quienes todavía necesitaban Node 20.
- Hasta el 23/9: es posible probar por adelantado con FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true.
- Hasta el 23/9: el opt-out temporal ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true todavía puede mantener Node 20 en escenarios admitidos por el runner.
- Después del 23/9: esa salida deja de funcionar porque Node 20 será eliminado del runner.
Fuente principal: GitHub Changelog — Deprecation of Node 20 on GitHub Actions runners. El calendario de versiones de Node.js confirma que la línea 20 llegó al fin de vida el 30 de abril de 2026: Node.js Release schedule.
Primero: no confundas el Node de la action con el Node de tu proyecto
Esta es la distinción más importante para evitar una falsa sensación de seguridad. Las JavaScript actions se ejecutan con una copia de Node mantenida dentro del runner. La documentación del runner describe ejecutables en directorios propios, como externals/node20 y externals/node24, y deja claro que ese runtime no es el binario de Node disponible en el PATH.
En cambio, actions/setup-node instala o selecciona la versión de Node utilizada por los comandos de tu aplicación, como npm, pnpm, yarn, pruebas y builds. Por lo tanto, un workflow puede instalar Node 22 o 24 para el proyecto y, en el mismo job, ejecutar una action antigua todavía empaquetada para Node 20. Para la auditoría del 23 de septiembre, la versión relevante es la declarada por las JavaScript actions.
Referencias: Node.js Connection Check del Actions runner y actions/setup-node.
Checklist para auditar los workflows
1. Haz un inventario de todos los usos de actions
Empieza por los archivos de .github/workflows y enumera cada aparición de uses:. Incluye actions de GitHub, actions de terceros, workflows reutilizables y actions locales. En repositorios grandes, buscar “uses:” en los archivos YAML es más fiable que revisar visualmente cada workflow.
No te detengas en el primer nivel. Un workflow reutilizable llamado desde otro repositorio puede contener sus propias actions antiguas. Lo mismo vale para una composite action local: puede encadenar otras actions por debajo.
2. Identifica qué referencias todavía dependen de node20
Para cada action del inventario, abre la versión exacta referenciada por el workflow — tag, branch o SHA — y revisa su action.yml o action.yaml. En una JavaScript action, busca runs.using. La sintaxis de metadatos de GitHub admite actualmente node20 y node24; el objetivo de la migración es node24.
Si el workflow está fijado a una release antigua, revisa las notas de versión de la action. Varias actions oficiales importantes ya migraron: por ejemplo, actions/checkout documenta Node 24 a partir de la línea v5, y las versiones actuales de actions/setup-node también usan Node 24. No saltes a ciegas al “número más alto”: una major puede introducir cambios de comportamiento que deben entrar en el plan de pruebas.
Referencias: Metadata syntax for GitHub Actions, actions/checkout y actions/setup-node.
3. Fuerza Node 24 en una rama de prueba
Antes de cambiar todas las referencias, ejecuta los workflows críticos con FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true definido en el entorno del workflow o del runner. GitHub proporcionó este mecanismo precisamente para anticipar la migración. El objetivo es cubrir builds, pruebas, publicación de artefactos, despliegues, autenticación, cachés y cualquier etapa que dependa de JavaScript actions.
La prueba debe reproducir rutas que normalmente aparecen solo en releases o producción. Un workflow que pasa en pull requests puede fallar en un job de publicación porque ese job llama a actions diferentes o usa runners diferentes.
4. Audita los runners self-hosted
El corte también es un problema de infraestructura. GitHub indica que Node 24 es incompatible con macOS 13.4 y versiones anteriores. Además, Node 24 no tiene soporte oficial para ARM32; por eso, los runners self-hosted ARM32 dejarán de estar soportados después de la deprecación de Node 20.
Actualiza el software del runner e inventaría el sistema operativo y la arquitectura de cada pool. Esto es especialmente importante en organizaciones que mantienen imágenes antiguas congeladas o runners efímeros construidos a partir de plantillas propias. Septiembre de 2026 también tiene un segundo plazo cercano: el 25 de septiembre, GitHub Enterprise Cloud comienza la aplicación total de una versión mínima para runners self-hosted. Es un calendario distinto, pero puede afectar a la misma flota.
Referencias: Self-hosted runners reference y Minimum version enforcement timeline for self-hosted runners.
5. Trata tus propias actions como software que necesita una release
Si tu organización mantiene JavaScript actions internas, la corrección no termina en el YAML consumidor. La action debe cambiar sus metadatos a runs.using: node24, recompilar el bundle distribuido cuando corresponda y superar pruebas de integración. GitHub recomienda pruebas automatizadas y un proceso de release claro para JavaScript actions, entre otras razones porque las dependencias suelen distribuirse junto con el código compilado.
Después de publicar una versión compatible, actualiza a los consumidores de forma controlada. Para actions de terceros, GitHub recomienda fijar la referencia a un SHA completo cuando la prioridad es la inmutabilidad; las tags son más cómodas, pero pueden moverse. Un buen flujo para esta migración es validar primero la release compatible y luego fijar la referencia que realmente pasó las pruebas.
Referencias: Releasing and maintaining actions y Secure use reference.
Cómo priorizar las correcciones
| Situación | Riesgo antes del 23/9 | Acción recomendada |
|---|---|---|
| Action externa antigua con runs.using node20 | Alto | Actualizar a una release compatible con Node 24 y probarla |
| Action interna JavaScript en node20 | Alto | Migrar metadatos, recompilar el bundle y publicar una nueva versión |
| Runner self-hosted con macOS 13.4 o anterior | Alto | Actualizar el sistema o mover el job a otro runner |
| Runner self-hosted ARM32 | Alto | Planificar una migración de arquitectura; Node 24 no tiene soporte oficial |
| Workflow ya pasa con FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 | Menor | Eliminar dependencias antiguas, consolidar refs y repetir pruebas críticas |
| El proyecto usa Node 20 mediante setup-node, pero las actions usan Node 24 | Problema distinto | Tratar por separado la migración del runtime de la aplicación; Node 20 ya está EOL |
Planifica un rollback sin depender de Node 20
Hasta el 23 de septiembre, ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true puede servir como contención temporal. No es un plan de rollback para después del corte. Cuando el runtime sea eliminado del runner, ninguna variable de entorno podrá restaurarlo.
El rollback útil es otro: conserva el commit anterior del workflow, registra los SHA de las versiones probadas, realiza el cambio mediante pull request y mantén una referencia conocida compatible con Node 24 para cada action crítica. Si una actualización de major rompe el comportamiento, debes volver a un ref anterior que también sea compatible con Node 24, no a una versión que dependa de Node 20.
Secuencia práctica para terminar antes del 23/9
- Inventaría todas las apariciones de uses: en workflows, workflows reutilizables y actions locales.
- Clasifica qué refs son JavaScript actions y revisa runs.using en la versión realmente consumida.
- Actualiza las actions todavía ligadas a Node 20, leyendo los breaking changes de cada major.
- Ejecuta las rutas críticas con FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true.
- Valida releases, despliegues, artefactos, autenticación, cachés y jobs poco frecuentes.
- Actualiza runners self-hosted, retirando macOS antiguo y ARM32 del camino crítico.
- Fija refs probados y documenta un rollback que permanezca en Node 24.
- Elimina flags temporales cuando la migración esté estable.
El corte del 23 de septiembre no exige reescribir por completo el CI, pero sí exige saber exactamente qué actions ejecuta el workflow y para qué runtime fueron publicadas. Auditar ahora convierte un cambio de plataforma en una actualización controlada de dependencias; esperar hasta el día de la eliminación convierte dependencias invisibles en fallos del pipeline.
