Runners self-hosted de GitHub Actions: deadline 31/7

Si tenés pipelines de CI/CD corriendo sobre self-hosted runners de GitHub Actions en tu Cloud Server, hay una fecha que conviene anotar: GitHub arrancó un cronograma de brownouts y enforcement que va a dejar afuera a los runners viejos. El primer corte duro llega el 31 de julio de 2026 para cuentas Enterprise Cloud con Data Residency, y el 25 de septiembre para el resto de Enterprise Cloud. Un runner por debajo de la versión mínima deja de registrarse y, encima, deja de ejecutar jobs aunque ya estuviera registrado.

La minimum version enforcement de GitHub Actions es una política que exige que todo self-hosted runner corra al menos la versión 2.329.0 para registrarse, y que se mantenga dentro de los 30 días de cada release nuevo para poder ejecutar jobs. La aplican GitHub desde 2026, en dos fechas según el tipo de cuenta (31/7 y 25/9). Los runners que no cumplan quedan bloqueados, sin excepciones ni prórroga automática.

¿Qué runners deja de aceptar GitHub y desde cuándo?

GitHub Actions endurece los runners self-hosted antes del 31 de julio

Hay que distinguir dos umbrales, porque no son lo mismo y esto confunde a mucha gente:

Versión mínima para registrarse: es 2.329.0. Un runner por debajo de esa versión ya no puede hacer config.sh ni re-registrarse contra tu organización.
Versión mínima para ejecutar jobs: avanza con el tiempo a medida que salen releases nuevos. GitHub pide instalar cada release dentro de los 30 días de su publicación. Un runner que ya estaba registrado, pero quedó viejo, deja de tomar jobs.

El despliegue no es de un día para el otro: primero hay brownouts —bloqueos intermitentes de 11:00 a 15:00 ET— que empiezan cortando el registro y después también la ejecución. Este es el calendario según la documentación oficial de GitHub:

Tipo de cuenta	Brownouts	Enforcement total
Enterprise Cloud con Data Residency	29/6 – 24/7/2026	31/7/2026
Enterprise Cloud (estándar)	24/8 – 18/9/2026	25/9/2026

Los brownouts son a propósito una molestia diseñada: querés que tu pipeline falle un martes a las 11:15 durante una ventana controlada, y no que se caiga silenciosamente el día del deadline con un release en producción a medio salir.

¿Por qué GitHub fuerza esta actualización justo ahora?

La versión mínima no es un capricho de mantenimiento: es la punta visible de un endurecimiento más grande de GitHub Actions. Después de varios incidentes de cadena de suministro sonados en el ecosistema de Actions, GitHub publicó un roadmap de seguridad para 2026 que reescribe cómo se ejecutan los workflows. Forzar una base de runners moderna es el requisito previo para que las piezas nuevas funcionen.

Entre lo que viene (todavía en preview o GA a mitad de año, según GitHub):

Dependency locking en el YAML: una sección dependencies: que fija todas las dependencias directas y transitivas por commit SHA, estilo go.mod + go.sum pero para tu workflow. La idea es que cada corrida ejecute exactamente lo que se revisó.
Egress firewall nativo (capa 7): un firewall de tráfico saliente con modos monitor y enforce que vive fuera de la VM del runner, así sigue en pie aunque un atacante consiga root adentro. Por ahora apunta a runners hosteados por GitHub.
Scoped secrets: credenciales que se atan a repos, organizaciones, ramas o entornos puntuales, en lugar de heredarse implícitamente hacia todos lados.
Ejecución dirigida por políticas: control centralizado, apoyado en rulesets, sobre quién puede disparar workflows y qué eventos se permiten.

Ojo con un detalle importante: ese roadmap se enfoca sobre todo en los runners hosteados por GitHub. Los self-hosted no reciben la mayoría de esas mejoras automáticamente, lo que refuerza que la seguridad de tu propia máquina corre por tu cuenta (más sobre esto abajo).

¿Cómo sé qué versión corren mis runners hoy?

Antes de tocar nada, hacé el inventario. Tenés tres formas de ver la versión de cada runner:

Desde la UI: en Settings → Actions → Runners (a nivel repo, organización o enterprise) aparece cada runner listado con su versión al lado.
Desde la propia máquina: al iniciar el runner con ./run.sh, el arranque loguea la versión del listener. También la vas a ver en los logs de _diag/.
Desde el audit log (Enterprise): podés consultar los eventos de registro de runners, que incluyen la versión con la que se conectó cada uno. Es la forma más rápida de barrer una flota grande sin entrar máquina por máquina.

Prestá especial atención a los runners que armaste con imágenes cacheadas viejas: VM images, imágenes de contenedor y scripts de instalación congelados suelen ser los que traen versiones vencidas.

¿Cómo actualizo un runner self-hosted sin cortar el CI?

El camino depende de cómo desplegaste el runner, y acá está la trampa más común:

Runner con auto-update activo (el default): el runner se actualiza solo cuando llega un job, siempre que tenga salida a github.com. En la mayoría de las instalaciones "a mano" sobre un Cloud Server, esto te resuelve el problema sin que hagas nada.
Runner con auto-update deshabilitado (--disableupdate): acá está el riesgo real. Muchos setups en contenedores, o con el Actions Runner Controller en Kubernetes, fijan la versión y desactivan la auto-actualización a propósito. Esos runners no se van a actualizar solos y son los primeros que se van a caer.
Runners en imágenes de contenedor: actualizá el tag de la imagen de actions/runner a un release igual o superior a 2.329.0, reconstruí y volvé a desplegar. No alcanza con reiniciar el pod: si la imagen está pinneada vieja, sigue vieja.

Para una instalación tradicional en Ubuntu, la actualización manual es descargar el paquete nuevo del runner, frenar el servicio, reemplazar los binarios y volver a levantarlo. Si administrás varios, la recomendación de GitHub es directa: actualizá los scripts de instalación, las VM images, las imágenes de contenedor y la automatización de despliegue, y recreá los runners que hayas construido a partir de imágenes cacheadas viejas. Si ya tenías un runner self-hosted andando, quizá te sirva repasar la instalación y el hardening base en nuestra guía "Runner self-hosted de GitHub Actions en un Cloud Server: instalación y seguridad".

¿Qué otro cambio de fecha tengo que tener en el radar?

Además del enforcement de versiones, hay otro deadline cercano que toca a quien usa OIDC para autenticarse contra la nube: los subject claims inmutables. Desde el 15 de julio de 2026, todo repositorio nuevo —y los que se renombren o transfieran después de esa fecha— van a usar un formato de sub con identificadores inmutables, según el changelog de GitHub.

El cambio es concreto: donde antes el claim decía repo:octo/mi-repo:ref:refs/heads/main, ahora agrega los IDs numéricos (repo:octo@123456/mi-repo@456789:ref:...). ¿Por qué importa? Porque si un nombre de repo u organización se liberaba y alguien lo reclamaba, ese nuevo dueño podía emitir tokens con el mismo subject y colarse en recursos de nube que todavía confiaban en la identidad vieja. Los IDs inmutables cierran ese agujero. Los repos existentes no cambian solos: tenés que activar el toggle en la configuración de OIDC. Si tenés condiciones de trust que matchean el sub por texto, revisalas antes de julio o vas a empezar a ver fallos de autenticación.

¿Cómo endurezco mis runners más allá de la versión?

La versión mínima es el piso, no el techo. Como los self-hosted runners ejecutan código en tu infraestructura, GitHub tiene recomendaciones de uso seguro que vale la pena aplicar mientras tenés las manos en la masa:

No los uses en repos públicos: GitHub es tajante en que casi nunca deberían usarse en repositorios públicos, porque cualquiera puede abrir un pull request y ejecutar código en tu máquina. Ahí no hay VM efímera que te proteja.
Preferí runners efímeros (JIT): un runner que ejecuta un solo job y se destruye reduce muchísimo el riesgo de compromiso persistente. Eso sí: si reusás el hardware para hostear runners JIT, automatizá la limpieza para no filtrar datos entre corridas.
Minimizá lo sensible en la máquina: preguntate qué hay en ese host —claves SSH privadas, tokens de API— y qué servicios internos alcanza por red, incluido el servicio de metadata de tu instancia de nube. Cuanto menos, mejor.
Usá OIDC en vez de credenciales de larga vida: autenticar contra tu proveedor de nube con tokens efímeros de OIDC es más seguro que guardar secretos permanentes en el runner (y te deja bien parado para el cambio de claims inmutables).
Ordená con runner groups: agrupá los runners y limitá qué organizaciones y repos pueden usarlos, en lugar de dejar runners sueltos por repositorio.

Si venís de una instalación mínima, sumar Fail2Ban, UFW y un buen manejo de SSH sobre el host del runner es la otra mitad del trabajo —el runner es tan seguro como la máquina donde vive.

Preguntas frecuentes

¿Cuál es la versión mínima de runner que exige GitHub?

La 2.329.0 para poder registrarse. Para ejecutar jobs, el piso efectivo avanza con cada release, y GitHub pide instalar cada uno dentro de los 30 días de su publicación.

¿Cuándo es el deadline exacto?

El enforcement total es el 31 de julio de 2026 para Enterprise Cloud con Data Residency, y el 25 de septiembre de 2026 para Enterprise Cloud estándar. Antes hay ventanas de brownout que ya empezaron a bloquear runners viejos de forma intermitente.

¿Qué pasa si no actualizo a tiempo?

Los runners por debajo de la versión mínima no se pueden registrar ni re-registrar, y los que ya estaban registrados pero quedaron viejos dejan de ejecutar jobs. En la práctica, tu pipeline de CI/CD se frena.

¿Mi runner se actualiza solo?

Si dejaste el auto-update activo (el comportamiento por defecto) y el runner alcanza github.com, sí. Si lo desplegaste con --disableupdate o con una imagen de contenedor pinneada —típico en Kubernetes—, no: tenés que actualizar la imagen o el binario a mano.

¿Esto afecta a los runners hosteados por GitHub?

No. La enforcement de versión mínima aplica solo a los self-hosted runners. Los runners hosteados por GitHub ya corren siempre una versión soportada.

¿El cambio de OIDC es lo mismo que el de la versión?

No, son dos cosas distintas con fechas cercanas. El de versión mínima (31/7 y 25/9) es sobre el software del runner; el de subject claims inmutables (15/7) es sobre cómo se firman los tokens OIDC que usás para autenticar contra la nube.