GitHub comienza este 29 de septiembre de 2026 la aplicación completa de sus requisitos mínimos de versión para runners autohospedados de GitHub Actions en Enterprise Cloud. Los runners con una versión anterior a 2.329.0 dejarán de poder registrarse o volver a registrarse y los que estén por debajo del mínimo de runtime dejarán de ejecutar trabajos, según el aviso oficial publicado por GitHub el 28 de septiembre.
Qué cambia desde hoy
La medida afecta a GitHub Enterprise Cloud y no a GitHub Enterprise Server. GitHub había anunciado previamente otra fecha de aplicación y la ha movido para iniciar el enforcement completo el 29 de septiembre.
Una empresa que mantenga runners propios para CI/CD debe comprobar inmediatamente la versión instalada en cada máquina. Si un runner queda por debajo del mínimo, un pipeline puede dejar de aceptar trabajos aunque el workflow y el repositorio no hayan cambiado.
El riesgo está en la infraestructura que no se actualiza
Los runners autohospedados se utilizan para ejecutar compilaciones, pruebas y despliegues dentro de infraestructura controlada por la empresa. Eso da flexibilidad, pero también obliga a mantener actualizado el software del runner. Una máquina olvidada en una red interna puede convertirse en un punto de fallo operativo o de seguridad.
GitHub ofrece además una API REST para consultar deprecaciones relacionadas con runners, útil para organizaciones que administran muchas instancias y necesitan automatizar la detección de versiones que se aproximan a su fecha límite.
Qué debe revisar una pyme con GitHub Actions
El primer paso es inventariar runners autohospedados activos y comprobar su versión. Después conviene actualizar aquellos por debajo de 2.329.0, ejecutar un workflow de prueba y verificar que etiquetas, grupos y permisos siguen funcionando.
También es recomendable revisar imágenes base y procesos de provisioning. Si un runner se recrea automáticamente desde una plantilla antigua, actualizar solo la máquina actual no evita que el problema reaparezca en el siguiente despliegue.
Cómo evitar que vuelva a ocurrir
La versión del runner debería formar parte de la monitorización de la plataforma de desarrollo. Las empresas pueden fijar alertas antes de las fechas de enforcement, automatizar actualizaciones controladas y mantener un pequeño grupo de prueba antes de aplicar cambios al conjunto de runners de producción.
Para equipos que están desplegando IA y automatización, este cambio se puede leer junto con el sandbox local de GitHub Copilot, la actualización de CodeQL, el parche crítico de GitLab, la adopción de passkeys en Microsoft Entra, las capacidades agénticas de Google Workspace y el nuevo enfoque de Microsoft Defender para agentes.
Fotografía: Christina Morillo / Pexels.
