Today is the day GitHub Enterprise Cloud starts properly enforcing self-hosted runner version requirements, which means somewhere a perfectly good CI fleet is about to stop doing anything because somebody treated runner software like a fridge.
Plug it in. Leave it there. Assume it lasts twelve years.
No.
GitHub’s September 28 changelog says full enforcement begins September 29. Runners below version 2.329.0 cannot register or reregister. Existing runners also need to satisfy a separate, moving runtime freshness requirement.
That second bit is the one people will cock up.
2.329.0 is not your forever version
The registration floor is fixed at 2.329.0, but GitHub’s self-hosted runner documentation says runners with automatic updates disabled still need to be updated within 30 days of a new runner release.
So no, you cannot update to 2.329.0, laminate the version number, hang it above the server rack and declare the matter closed.
GitHub’s earlier minimum-version enforcement timeline is quite explicit: the runtime minimum moves forward as new runner releases appear.
If your fleet uses --disableupdate, immutable images, containers, appliance-like runner VMs or some lovingly handcrafted provisioning ritual involving Bash and regret, the update mechanism is now your mechanism.
Own it.
Pinning is fine. Rotting is not.
There are perfectly sane reasons to disable automatic updates.
Maybe you want reproducible images. Maybe security reviews runner releases before production. Maybe your fleet is ephemeral and the image is the product. Maybe allowing a build agent to mutate itself underneath a workload makes your eye twitch.
All reasonable.
What is not reasonable is choosing manual updates and then acting personally betrayed when “manual” turns out to contain a verb.
If you pin software, you need a refresh cadence, observability and some way to know when the platform is about to reject what you pinned.
GitHub has even added a runner version deprecations API, according to the changelog, specifically so fleets can automate alerts around registration and runtime deadlines.
Use the bloody thing.
GitHub is not entirely innocent here
There is one fair complaint: GitHub has moved this enforcement timeline more than once.
Dates shifted during the rollout. That makes operational planning harder, especially for organisations that need lead time to qualify runner images across a large fleet.
If you are going to impose a freshness contract on infrastructure, the contract needs to be boringly predictable.
But the underlying requirement is not absurd. Actions is a service and runner software is part of the protocol between your machine and that service. GitHub cannot promise to speak every ancient runner dialect until the heat death of the universe.
Treat runners like infrastructure
A self-hosted runner is not “free GitHub Actions”.
It is your compute, your patching, your network, your credentials, your disk growth, your runner binary and your problem when a queue sits there for six hours because half the fleet has gone technologically prehistoric.
If you want that control, excellent. I like control too.
But control comes with chores.
Update the runners.