loading…
[OK] dns resolved
[OK] tcp handshake
[..] waiting on payload
GitHub has put dates on something many platform teams have quietly treated as optional: keeping self-hosted Actions runners current.
In a June 12 changelog, GitHub said it is resuming minimum-version enforcement for self-hosted runners on GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency. The short version: runners must be on at least 2.329.0 to register or re-register, and after that they need to install each new runner release within 30 days. If a critical security update ships, job queuing can pause until the runner is updated.
That is not a subtle nudge. That is CI walking into the room with a clipboard.
Sources:
GitHub says the enforcement is tied to a larger GitHub Actions backend migration. According to the changelog, the newer architecture handles over 120 million jobs per day and lets enterprises start seven times more jobs per minute than before.
The operational change is more important than the platform victory lap:
2.329.0 or later to configure or re-register.GitHub is also running brownouts before full enforcement. For GitHub Enterprise Cloud with Data Residency, full enforcement starts July 31, 2026. For GitHub Enterprise Cloud, full enforcement starts September 25, 2026. Brownouts begin earlier and intermittently block registration, then later block both registration and runtime job execution for unsupported runners.
The failure mode is straightforward: workflows can sit queued, fail, or stop landing on the runner fleet you thought existed.
Self-hosted runners are attractive because they let teams control hardware, network reachability, installed tooling, GPU access, private dependencies, and other messy realities that do not fit neatly into hosted runners. They are also attractive because they become infrastructure, and infrastructure tends to develop folklore.
Somewhere there is a runner VM named actions-prod-legacy-do-not-touch that has not been rebooted since a team offsite. This announcement is for that machine.
The main shift is that the runner binary is no longer just a bootstrap detail. It is part of the availability contract for CI/CD.
If your release pipeline depends on self-hosted runners, stale runner versions are now a deployment risk, not merely an audit finding. A pinned runner version may work today and then fail to receive jobs after the enforcement window. That can break releases in the least dramatic but most annoying way possible: nothing explodes, the build just waits.
If you operate GitHub Actions self-hosted runners, this is what I would check now.
Find every runner pool: enterprise, organization, and repository scoped. Include ephemeral runners, autoscaling groups, Kubernetes-backed runners, and any one-off machine someone added during an incident and then promoted by neglect.
GitHub says runner version is being added to the REST API, and enterprise owners can inspect audit log registration events such as org.register_self_hosted_runner, repo.register_self_hosted_runner, and enterprise.register_self_hosted_runner.
Do not rely on a spreadsheet unless it is generated from reality. Spreadsheets are where runner fleets go to become fan fiction.
GitHub’s docs note that self-hosted runners receive automatic updates for the runner application, though teams can disable that behavior. Auto-update is the easiest path for many fleets, but it is not free:
For regulated or high-control environments, disabling auto-update can still be reasonable. But then the replacement is not “we’ll remember.” The replacement is a patch pipeline with owners, monitoring, and a deadline shorter than 30 days.
Runner binaries should live in the same mental bucket as container base images, VM images, and build toolchains. They are not application code, but they execute application code, touch credentials, and decide whether your delivery machinery works.
For immutable or ephemeral runners, bake the runner version into the image and rotate the fleet. For long-lived runners, monitor the installed version and alert before the 30-day window becomes a small fire wearing a GitHub logo.
The brownout schedule is the useful warning. Use it.
Pick a non-critical repository or runner group and confirm what happens when a runner is unsupported. Does the workflow fail clearly? Does it queue forever? Does the owning team get paged? Does the dashboard show the actual cause, or does everyone spend 45 minutes blaming npm because tradition demands a scapegoat?
The time to learn that your CI failure mode is inscrutable is before the release train is full.
This announcement is about version enforcement, but it is adjacent to the bigger self-hosted runner problem: trust.
GitHub’s Actions security guidance still applies. Runners can see whatever your jobs give them. Secrets should be least-privilege. GITHUB_TOKEN permissions should be minimal by default. Logs should be treated as places secrets may accidentally visit and then refuse to leave.
A stale runner is not automatically compromised. But runner patch hygiene is part of the same operational surface as secret handling, network egress, job isolation, and cleanup between runs.
The enforcement timelines apply to github.com and GitHub Enterprise Cloud with Data Residency, not necessarily every GitHub Enterprise Server deployment in the same way. If you run GHES, check your version-specific release notes and runner compatibility guidance rather than assuming the cloud timeline maps exactly.
Also, GitHub says the 2.329.0 threshold is only the registration minimum. It is not a permanent safe harbor. Once new runner releases ship, the effective runtime requirement moves forward.
That detail matters. Upgrading once is not the project. Building the update loop is the project.
Self-hosted Actions runners have always been part of the delivery system. GitHub is now making that fact harder to ignore.
If you own a runner fleet, inventory it, patch it, monitor it, and test the failure mode. CI that depends on an unpatched box in the corner is not a platform. It is a superstition with YAML.