GitHub Actions Gets Serious About Self-Hosted Runner Versions

GitHub is resuming enforcement of minimum version requirements for GitHub Actions self-hosted runners — and this time, the deadlines are firm. After a rocky start that included multiple delays and a temporary pause earlier this year, GitHub has published a clear enforcement timeline for both GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency. If your team runs self-hosted runners and hasn’t upgraded them yet, now is the time to act. Why This Is Happening In early 2024, the GitHub Actions team began rearchitecting the backend services that power job execution and runner communication. That foundational rebuild now handles over 120 million jobs per day — more than three times the pre-migration volume — and lets enterprises start seven times more jobs per minute than before. Version enforcement is the final step in completing that migration. Older runner versions that are incompatible with the updated infrastructure can no longer be supported as all runners move to the new platform. Two Requirements to Stay Compatible GitHub has simplified the compliance picture down to two requirements. First, to configure or re-register a runner, it must be on version 2.329.0 or later. This is the minimum version required for the new architecture to recognize the runner and allow it to connect. Second — and this is where some teams may get caught off guard — registration alone isn’t enough. To continue executing workflow jobs, the runner must stay up to date by installing each new runner release within 30 days of its publication. The practical implication: a runner pinned at 2.329.0 that never updates again will eventually stop picking up jobs. Runners with auto-update enabled automatically meet the 30-day requirement, as long as they can reach the update service. Runners with auto-update disabled must be upgraded manually on a regular cadence. And GitHub has added another layer of urgency: when a critical security update is published, GitHub Actions will pause job queuing to the runner until the update has been applied. The Shift in How Runners Need to Be Managed Mitch Ashley, VP & Practice Lead, Software Lifecycle Engineering & AI-Native Software Engineering at The Futurum Group, says this enforcement marks a meaningful change in how teams need to think about runner infrastructure. “Self-hosted CI infrastructure is moving from a set-and-forget asset to a continuously validated state,” said Ashley. “A runner now has to prove version currency to keep executing jobs, and pinning it once no longer keeps it in service. A runner that registers cleanly today becomes a silent pipeline outage in thirty days if it stops updating. Freshness is now an availability requirement, moving the control point to image pipelines, provisioning automation, and ephemeral runner strategy.” That last point matters. Teams that have been treating runner maintenance as a one-time provisioning task will need to rethink their approach — and the earlier they do it, the less disruption they’ll face. The Enforcement Timeline GitHub is using a brownout strategy to give teams time to identify and fix outdated runners before hard enforcement kicks in. Brownouts will start by intermittently blocking registration of unsupported runner versions, then expand to also intermittently blocking job execution on unsupported runners. All brownout windows run from 11:00 AM to 3:00 PM ET on the listed dates. For GitHub Enterprise Cloud with Data Residency, the brownout schedule starts June 29 and runs through late July, with full enforcement beginning July 31, 2026. For GitHub Enterprise Cloud, brownouts begin August 24 and ramp up through mid-September, with full enforcement beginning September 25, 2026. GitHub Enterprise Server is not impacted at this time. What Happens If You Don’t Upgrade The consequences are straightforward. After each enforcement date, self-hosted runners with versions below the minimum required for registration won’t be able to register or re-register. Existing runners below the minimum version required to execute workflow jobs will stop running workflow jobs, even if they were previously registered. Workflows targeting unsupported runners may remain queued or fail. That’s a potential full stop on CI/CD pipelines — not a warning message. How to Find and Fix Affected Runners GitHub has added tooling to help teams audit their runner inventory. Enterprise owners can audit which runner versions are currently registering by querying the audit log for runner registration events, each of which includes the runner version. GitHub also recently added runner version data to the REST API. The fix itself is straightforward: upgrade all self-hosted runners to the latest supported version, update installation scripts, VM images, container images, and deployment automation, and recreate runners built from older cached images or templates. The Bottom Line This isn’t a new requirement. GitHub has been communicating the need to keep self-hosted runners up to date for some time. What’s changed is that enforcement is no longer optional or easily deferred. Teams that treat runner maintenance as a low-priority task are about to feel that friction directly in their pipelines. The brownout schedule gives DevOps teams a reasonable runway to get compliant without scrambling at the last minute. But that runway is finite. Audit your runners now, enable auto-update where you can, and update your runner provisioning scripts before the first brownout dates hit. The new GitHub Actions architecture is built for scale. The catch is that outdated runners aren’t invited to run on it.