Triple migración en GitHub Actions: qué cambia en junio 2026

En mayo de 2026, las migraciones GitHub Actions 2026 llegaron en tanda triple: runners ARM64 que pasan a infraestructura propia de GitHub, windows-latest que salta a Visual Studio 2026, macos-latest que migra a macOS 26, y encima el formato de tokens para GitHub Apps cambia de 40 caracteres a un JWT de ~520. Todo en la misma semana. No es coincidencia.

La triple migración de GitHub Actions mayo 2026

GitHub Actions es la plataforma de CI/CD integrada en GitHub que permite automatizar builds, tests y deploys mediante workflows YAML. El 14 y 15 de mayo de 2026, el equipo de GitHub publicó dos changelogs en la misma semana que cambian simultáneamente la infraestructura de runners y el sistema de emisión de tokens. No fue casualidad: ambos cambios son parte del roadmap Q1 de GitHub para tomar control total de su infraestructura de Actions y mejorar la performance del sistema S2S (service-to-service).

Lo que hace que esto sea complicado es la simultaneidad. El costo operacional cae sobre tus workflows YAML y tu código de GitHub Apps al mismo tiempo. Si tenés un stack con runners ARM, builds en Windows, pipelines en macOS y apps que usan tokens de instalación, las tres migraciones te afectan de frente.

Migración de runners ARM64: Ubuntu y Windows

Hasta ahora, las imágenes ubuntu-24.04-arm y windows-11-arm las mantenía Arm Limited. A partir de esta migración, GitHub toma control directo de esas imágenes.

Lo que no aclaran tan bien: durante el período de transición no va a haber actualizaciones de imagen. Si alguna herramienta de tu pipeline depende de un paquete que normalmente se actualiza con la imagen, quedás con la versión que estaba al momento del congelamiento. ¿Cuánto dura eso? Habría que ver, pero el rollout de los labels empieza entre el 8 y el 15 de junio.

La acción inmediata para la mayoría: revisar si usás runs-on: ubuntu-24.04-arm o runs-on: windows-11-arm en tus workflows. Si no los usás, tranquilo. Si los usás, verificá que ninguna dependencia crítica esté en ese limbo de no-actualización. Cubrimos ese tema en detalle en comparativa con otras herramientas CI/CD.

Windows-latest salta a Visual Studio 2026 entre el 8 y 15 de junio

El timeline es escalonado: entre el 8 y el 15 de junio, windows-latest pasa a apuntar a la imagen con Visual Studio 2026 en vez de VS2022.

¿Qué cambia? Nuevas versiones de compiladores, librerías del sistema y herramientas de build que vienen con VS2026. Si tu proyecto compila con MSVC, las versiones del toolset cambian. Si usás herramientas que dependen de la versión del SDK de Windows incluido, también.

Las opciones que tenés:

• Si necesitás seguir con VS2022: cambiá el label a windows-2022 explícitamente antes del 8 de junio.
• Si querés testear VS2026 ahora: usá windows-2025-vs2026 en un workflow paralelo antes del cambio obligatorio.
• Si tu proyecto es agnóstico al toolset de Visual Studio: probablemente no tenés que hacer nada (pero igual vale la pena correr el pipeline una vez con la imagen de VS2026 para confirmar).

El error más común que ya veo venir: equipos que usan windows-latest sin pinear la versión del toolset de MSVC, asumiendo que “latest siempre compiló bien”. Con el salto de VS2022 a VS2026, esa suposición se rompe (si es que eso cuenta como sorpresa a esta altura de CI/CD).

macOS-latest migra a macOS 26 desde el 15 de junio

El rollout arranca el 15 de junio y se completa en 30 días. Distinto al de Windows, acá no hay un corte de una semana sino un despliegue gradual que puede hacer que algunos repos lo vean antes que otros.

Para testear antes del cambio: macos-26-large ya está disponible. La recomendación es usarlo en una rama de test ahora, antes de que el cambio sea obligatorio. Complementá con herramientas de IA para workflows.

El tema con macOS es que las herramientas del ecosistema suelen atarse a versiones específicas del OS más que en Linux. Ponele que usás herramientas instaladas vía Homebrew que tienen dependencias de versiones de librerías del sistema: con el salto a macOS 26 esas dependencias pueden cambiar. Lo mismo con Xcode si buildás apps iOS/macOS en el pipeline.

El nuevo formato JWT para tokens de GitHub Apps

Este es el cambio que más código puede romper sin que nadie lo vea venir.

Hasta ahora, los tokens de instalación de GitHub Apps con prefijo ghs_ eran strings opacos de 40 caracteres. Según el aviso de abril de 2026, el rollout empezó el 27 de abril y continúa hasta fin de junio. El nuevo formato es un JWT de aproximadamente 520 caracteres, con estructura ghs_APPID_JWT.

¿Cómo distinguirlos? Contando puntos: un JWT tiene exactamente 2 puntos que separan header, payload y firma. El token opaco antiguo no tiene ninguno.

¿Y qué se rompe? Cualquier código que:

• Valide que len(token) == 40 o similar
• Use el token como key en una base de datos con columna VARCHAR(40)
• Haga parsing asumiendo que el token no contiene puntos
• Cachee tokens en sistemas que truncan strings largos

El header X-GitHub-Stateless-S2S-Token permite opt-in/opt-out por request durante el período de transición. Pero eso es temporal: eventualmente todos los tokens van a ser JWT.

¿Alguien verificó de forma independiente el impacto completo en todas las integraciones de terceros? Todavía no hay un recuento consolidado, pero el cambio de 40 a 520 caracteres es el tipo de cosa que explota silenciosamente en sistemas legacy que nadie revisó en años.

Preparación de workflows YAML: qué hacer antes del 8 de junio

Inventario rápido de lo que tenés que revisar:

Cambio	Fecha límite	Acción en tu YAML	Fallback disponible
windows-latest → VS2026	8-15 junio	Testear con windows-2025-vs2026	windows-2022
macos-latest → macOS 26	15 junio (+30 días)	Testear con macos-26-large	macos-15 o versión anterior
Runners ARM64 a infraestructura GitHub	8-15 junio	Verificar dependencias congeladas	Sin fallback de label
Tokens JWT ghs_ (~520 chars)	Fin de junio	Revisar código que valida longitud	Header opt-out por request

El patrón de conditional workflows es útil si necesitás mantener compatibilidad con las versiones viejas durante el período de transición: usás una matrix strategy con las dos versiones del runner y validás que ambas pasen antes de cortar. Lo explicamos a fondo en asistentes de IA para automatización.

Impacto en runners autohospedados y Actions Runner Controller

ARM64 ya tiene soporte en Linux, macOS y Windows (este último en preview). Para equipos que manejan su propia infraestructura de runners, Actions Runner Controller (ARC) en Kubernetes sigue siendo la opción más flexible para escalar.

Un dato que no siempre está en el primer plano del debate: los runners autohospedados en repos privados y organizaciones enterprise pasaron a ser pagos desde principios de 2026. Si tu equipo usa runners propios en repos privados, el costo es de $0.002 por minuto, lo que en pipelines largos empieza a sumar. Si buscás infraestructura para correr esos runners, la configuración con un VPS en donweb.com es una alternativa directa sin pasar por los runners hosted de GitHub.

Errores comunes que vas a ver en los próximos 30 días

Error 1: Asumir que windows-latest es estable. Muchos equipos usan windows-latest precisamente porque quieren “lo más nuevo” pero sin pensar en que “lo más nuevo” cambia. Si nunca pinaste la versión del toolset de MSVC con env: VCToolsVersion o similar, el cambio a VS2026 puede romper builds sin un error obvio.

Error 2: No testear macOS antes del 15 de junio. La imagen macos-26-large ya está disponible. No testearla antes del rollout obligatorio es dejar para último momento un problema que podría tomar horas diagnosticar en producción.

Error 3: Ignorar el cambio de tokens si “no usás GitHub Apps”. Si usás integraciones de terceros que internamente usan GitHub Apps (bots de review, herramientas de automatización de PRs, plataformas de CI de terceros), el token que llega a tus sistemas puede cambiar de formato sin que lo veas directamente. Si alguna de esas integraciones guarda o valida tokens, el problema llega de rebote.

Error 4: Confiar en que el opt-out del header JWT es permanente. El header X-GitHub-Stateless-S2S-Token es para el período de transición. Usarlo como solución definitiva es patear el problema para después. Te puede servir nuestra cobertura de modelos de IA para generar código.

Preguntas Frecuentes

¿Qué son las migraciones GitHub Actions 2026 de mayo?

Son tres cambios simultáneos en la infraestructura de GitHub Actions anunciados el 14 y 15 de mayo de 2026: los runners ARM64 pasan a gestión propia de GitHub, windows-latest migra a Visual Studio 2026 entre el 8 y 15 de junio, y macos-latest pasa a macOS 26 a partir del 15 de junio con rollout de 30 días. Los tres forman parte del roadmap Q1 de GitHub para tener control total de su infraestructura de CI/CD.

¿Cómo actualizo mis workflows para no romper nada con estos cambios?

Revisá los labels de runs-on en todos tus workflows. Si usás windows-latest, testear con windows-2025-vs2026 antes del 8 de junio y tener windows-2022 como fallback si necesitás VS2022. Para macOS, probá macos-26-large ahora y monitoreá dependencias de Homebrew que puedan cambiar con el OS. Para ARM64, verificá que no tengas dependencias que se actualicen con la imagen base durante la transición.

¿Qué pasa con el nuevo formato de tokens ghs_ para GitHub Apps?

Los tokens de instalación de GitHub Apps pasan de 40 caracteres opacos a JWTs de ~520 caracteres. El rollout empezó el 27 de abril de 2026 y se extiende hasta fin de junio. Si tu código valida la longitud del token, lo guarda en campos de base de datos con tamaño fijo, o hace parsing asumiendo que no hay puntos en el string, se rompe. Revisá toda la lógica que toque esos tokens antes de fin de junio.

¿Cuándo debo migrar mis workflows a macOS 26 obligatoriamente?

El rollout empieza el 15 de junio de 2026 y se completa en aproximadamente 30 días (mediados de julio). No hay una fecha única de corte sino un despliegue gradual, lo que significa que distintos repositorios verán el cambio en momentos diferentes. Para evitar sorpresas, lo mejor es testear con macos-26-large ahora y ajustar antes del 15 de junio.

¿Los runners autohospedados se ven afectados por estas migraciones?

La migración de imágenes hosted no afecta directamente a los runners autohospedados, pero el cambio de formato de tokens sí: si tu runner autohospedado usa tokens de GitHub Apps para autenticarse o interactuar con la API, el nuevo formato JWT de ~520 caracteres puede romper código que valide el token. Además, desde principios de 2026 los runners autohospedados en repos privados tienen costo ($0.002/min), lo que vale tener en cuenta al diseñar la infraestructura de CI.

Conclusión

Las migraciones GitHub Actions 2026 de mayo no son actualizaciones menores: son tres cambios de infraestructura que llegan juntos y que, combinados, pueden afectar simultáneamente tus builds de Windows, tus pipelines de macOS, tu stack ARM y el código que maneja tokens de GitHub Apps. El calendario es apretado: tenés hasta el 8 de junio para estar listo con Windows, y hasta mediados de julio para macOS.

La ventana para testear existe: windows-2025-vs2026 y macos-26-large están disponibles hoy. Usarla ahora, antes de que el cambio sea obligatorio, es la diferencia entre migrar con control y apagar incendios un martes a las 2am cuando los builds de producción empiezan a fallar.

Fuentes

• GitHub Blog Changelog — Upcoming image migrations (14 mayo 2026)
• GitHub Blog Changelog — Nuevo formato de tokens para GitHub Apps (24 abril 2026)
• GitHub Blog Changelog — Header de override por request para tokens (15 mayo 2026)
• Dev.to — GitHub Actions May 2026 Triple Migration deep dive
• GitHub Docs — Runners hospedados por GitHub