GitHub Actions bloquea los runners autoalojados anteriores a 2.329.0

GitHub empezó a aplicar por completo su regla de versión mínima para los runners autoalojados de Actions el 29 de septiembre de 2026. Una entrada del changelog de GitHub movió la fecha, que antes era el 25 de septiembre. Los runners anteriores a la versión 2.329.0 ya no pueden registrarse en GitHub Enterprise Cloud. Los runners desactualizados que ya están registrados dejan de recibir trabajos.

Un runner autoalojado es el pequeño programa que un equipo instala en su propia máquina para ejecutar flujos de trabajo de GitHub Actions, en lugar de usar las máquinas alojadas de GitHub. Los equipos los usan para hardware especial, redes privadas o un menor costo. Un runner que se instaló una vez y nunca se actualizó puede ahora detener un pipeline de CI, el sistema automatizado de compilación y pruebas, sin ningún cambio de código.

Las dos reglas de versión

Se aplican dos límites separados, según la entrada con el calendario que GitHub publicó el 12 de junio de 2026.

Regla	Qué exige	Qué pasa si no se cumple
Registro	Versión del runner 2.329.0 o posterior	El runner no puede registrarse ni volver a registrarse
Ejecución de trabajos	Cada nueva versión del runner instalada en los 30 días siguientes a su publicación	El runner deja de ejecutar trabajos, aunque ya esté registrado

La regla de trabajos es la más estricta de las dos. Su versión mínima está por encima del mínimo de registro, y sigue moviéndose. Un runner puede ser lo bastante nuevo para registrarse y aun así demasiado viejo para ejecutar un flujo de trabajo.

A quién afecta

La regla cubre GitHub.com y GitHub Enterprise Cloud, el servicio alojado de GitHub para empresas. GitHub Enterprise Cloud con residencia de datos, la edición que guarda los datos en una región elegida, la aplica desde el 31 de julio de 2026. GitHub Enterprise Server, el producto que las empresas instalan en sus propios servidores, no se ve afectado.

Cómo se llegó a este despliegue

GitHub publicó el calendario en junio y luego realizó brownouts. Un brownout es un bloqueo breve y planificado que apaga los runners antiguos durante unas horas para que sus dueños lo noten antes de la fecha límite real.

Para Enterprise Cloud, los brownouts fueron de 11:00 a 15:00, hora del Este de EE. UU., en días fijados. Se ampliaron cada semana, según la entrada de junio.

Semana	Días de brownout	Qué se bloqueó
1	24 de agosto	Registro
2	31 de agosto, 2 de septiembre	Registro
3	7, 9 y 11 de septiembre	Registro y ejecución de trabajos
4	14, 16 y 18 de septiembre	Registro y ejecución de trabajos

El motivo de la regla es la infraestructura. DevOps.com informa de que GitHub empezó a reconstruir los servicios de backend de Actions a principios de 2024. La nueva plataforma maneja más de 120 millones de trabajos al día. También permite a las empresas iniciar siete veces más trabajos por minuto que antes. Exigir las versiones de los runners completa esa migración al asegurar que cada runner funcione en la nueva plataforma, según DevOps.com.

Cómo revisar sus runners

La entrada de GitHub del 28 de septiembre también añade una REST API para el desuso de versiones del runner. Devuelve las fechas de desuso para el registro y para la ejecución de las versiones del runner. Un equipo puede usarla para ver venir la próxima fecha límite, en lugar de enterarse por un trabajo fallido.

Los runners con las actualizaciones automáticas activadas cumplen la regla de 30 días por sí solos, dice la entrada de junio de GitHub. Los runners que alguien actualiza a mano necesitan un calendario de actualizaciones regular para mantenerse dentro de la ventana.

Qué significa esto para los desarrolladores

Revise hoy cada runner autoalojado, antes de que falle una compilación. Haga una lista de cada runner y de la versión que indica, y actualice primero todo lo que esté por debajo de 2.329.0. Esas máquinas ya tienen bloqueado el registro.

Después mire cómo recibe cada runner sus actualizaciones. Los runners incluidos en una imagen de máquina virtual o en una imagen de contenedor son la trampa habitual. Arrancan con la versión que quedó congelada en la imagen. Los equipos suelen desactivar las actualizaciones automáticas para que las compilaciones sean repetibles. Con una ventana de 30 días, esa imagen necesita ahora reconstruirse al menos una vez al mes.

Trate la regla como permanente, no como una migración puntual. Cada nueva versión del runner pone en marcha un nuevo plazo de 30 días. Incluya la versión del runner en la misma rutina de parches que el sistema operativo, y conecte la API de desuso a su monitorización.

Vigile los runners que se quedan en silencio. Antes de esta regla, un runner inactivo solía indicar una máquina averiada. Ahora puede significar que GitHub simplemente ha dejado de enviarle trabajos.