GitHub moves self-hosted Actions runner enforcement to September 29

GitHub moves self-hosted Actions runner enforcement to September 29

GitHub moved Enterprise Cloud enforcement for old self-hosted Actions runners to September 29, with version 2.329.0 as the registration floor.

Format News Brief
Read Time 2 min
Category Software
Updated Sep 29, 2026

GitHub has moved the enforcement date for its GitHub Actions minimum version requirements for self-hosted runners on GitHub Enterprise Cloud. The change shipped on Monday, September 28, 2026, and full enforcement now begins Tuesday, September 29, 2026. For teams that run their own CI capacity, this is a same week operational deadline rather than a distant platform notice.

The requirements did not change. GitHub says self-hosted runners below version 2.329.0 will no longer be able to register or reregister. It also says existing runners below the higher runtime minimum will stop executing workflow jobs, even if they were previously registered. The shift applies to GitHub Enterprise Cloud. GitHub Enterprise Server is not affected, and GitHub Enterprise Cloud with Data Residency began enforcement on July 31, 2026.

What changed for CI teams

The practical issue is not the version number alone. Many organizations keep self-hosted runners in locked images, autoscaling groups, Kubernetes controllers, or isolated build networks. A runner image that looked stable yesterday can become a hidden release blocker when new jobs stop landing on it. The risk is larger for fleets that support security scans, release signing, mobile builds, or long running hardware tests, because those jobs often depend on specialized machines that are updated less often than standard cloud runners.

GitHub points administrators to upgrade guidance and to a REST API for runner version deprecations. That API is the useful control surface here: teams can check registration and runtime deprecation dates for specific runner versions and build alerts around fleets that are nearing a deadline. CyberOGZ would treat this as a fleet inventory problem, not a one time patch task. If CI capacity is managed through images or templates, the base image and the rollout mechanism both need to be checked.

What to watch next

The immediate decision is simple: verify the runner version behind every active Enterprise Cloud self-hosted runner and upgrade anything below the required levels before business critical workflows depend on it. The follow through matters more. Runner age should become part of routine platform health reporting, alongside queue time, failure rate, and image drift. GitHub's tighter enforcement makes old CI infrastructure less forgiving, but it also gives engineering leaders a clearer reason to retire runners that have been quietly carrying release risk.

Sources

Cover image: cobaltfish, source, licensed under BY-SA.

Comments (0)

Leave a Comment

Loading comments...