← Today's Issue / Tech / May 17, 2026
CI

GitHub Actions sets June dates for runner image changes

GitHub is preparing several hosted-runner image migrations that could affect CI pipelines in June. Windows labels will move to Visual Studio 2026, macOS latest will move to macOS 26, and GitHub is taking over maintenance of Arm64 runner images.

GitHub Actions: Upcoming image migrations GitHub Changelog 3 min
GitHub Actions sets June dates for runner image changes
Hosted runner image changes can arrive as build failures unless workflows are pinned or tested early.

GitHub has put dates on a set of hosted-runner image changes that are worth checking before June, especially for projects with mixed PHP, Node, mobile or Windows build pipelines.

The most immediate change is for Windows runners. GitHub says the `windows-latest` and `windows-2025` labels will migrate to images using Visual Studio 2026 by default. The rollout starts on 8 June 2026 and is due to complete by 15 June. Teams that want to test early can point jobs at `windows-2025-vs2026`. Teams that need to stay on Visual Studio 2022 should pin `runs-on` to `windows-2022`.

The macOS change follows close behind. From 15 June, GitHub will begin a 30-day migration of `macos-latest` so that it points to the macOS 26 image instead of macOS 15. Anyone who needs the older image should target `macos-15` directly.

There is also an Arm64 maintenance change. GitHub says it now owns and maintains the Arm64 hosted runner images that were previously maintained by Arm Limited. Windows 11 Arm images have already moved to GitHub-managed builds and pipelines; Ubuntu 24.04 Arm and Ubuntu 22.04 Arm are being migrated to GitHub internal pipelines. During that transition, those Ubuntu Arm images will not receive updates and new release notes will not appear in the old `actions/partner-runner-images` repository. Support is moving to `actions/runner-images`.

GitHub says Arm64 image functionality and compatibility remain the same, with no packages added or removed as part of that transition. Even so, the practical advice is to avoid discovering image drift during a client release.

For Laravel and PHP teams, this mostly affects the edges of the stack rather than `composer test` itself: browser tests that depend on Chrome or Edge versions, asset builds that depend on Node or native packages, extension builds, Windows compatibility checks, and any workflow that uses macOS for mobile packaging or notarisation. If the project uses broad labels such as `windows-latest` or `macos-latest`, now is the time to run a scheduled test against the future label, or pin the old one until the pipeline is ready.

The safest small task this week is to search workflow files for `windows-latest`, `windows-2025` and `macos-latest`, then decide whether each job wants freshness or stability. For release-critical workflows, explicit labels usually beat surprise upgrades. If the pipeline is not normally touched until it breaks, make this a calendar task now; hosted image migrations are exactly the kind of infrastructure change that arrive as a “random” Monday failure.

· · ·