GitHub Actions Self-Hosted Runners: Fix Before Sept 25

Originally published on DevToolHub.

If you run GitHub Actions self-hosted runners, the enforcement clock isn't approaching — it's already running. GitHub's minimum-version enforcement blocks registration below version 2.329.0. It's been fully in effect for GitHub Enterprise Cloud with data residency since July 31, 2026, and for the rest of github.com the brownout windows started August 24 — full enforcement lands September 25.

The practical takeaway isn't "update your runners." It's that GitHub already tried this once and had to pull it days before the deadline, and the fix has a gap the changelog doesn't spell out: auto-update can't save a runner that's already below the line, because the version check happens before auto-update ever gets a chance to run.

What Breaks If You Don't Upgrade Your GitHub Actions Self-Hosted Runners

Two separate requirements kick in. Runners need version 2.329.0 or later just to register at all. Once registered, GitHub raises the bar again — runners must install new releases within 30 days of publication, or they stop picking up jobs even though they stay registered.

Each deadline comes with brownout windows — scheduled periods where GitHub temporarily blocks old-version registration so you can catch problems before enforcement is permanent. For September 25, those windows are already running: August 24 was the first, with more on August 31, September 2, 7, 9, 11, 14, 16, and 18 (11:00 AM–3:00 PM ET each). Miss the deadline entirely and the failure mode is blunt. New runners fail to register. Existing runners stop picking up jobs, and workflows targeting them sit queued or fail outright. Separately, when GitHub ships a critical security update to the runner, job queuing pauses on runners that haven't applied it.

[IMAGE: articles/images/2026-08-25-github-actions-self-hosted-runner-enforcement-diagram.png | alt: "registration flow for github actions self-hosted runners hitting the minimum version gate"]

If you're new to running your own runners at all, the guide to your first GitHub Actions CI/CD pipeline covers the baseline setup this enforcement sits on top of.

Why Enforcement Got Paused Once Already

This isn't GitHub's first attempt. Enforcement was originally slated for early 2026, pushed to March 16, and then paused three days before that deadline. GitHub's pause notice gave no technical reason — just wanting "a smooth transition" — but third-party reporting tied it to kernel compatibility failures v2.329.0 exposed in legacy cgroup environments, the kind of failure that breaks CI pipelines overnight. Three months later, GitHub came back with the current July 31 / September 25 timeline.

That history matters for one reason. 2.329.0 is the floor GitHub checks at registration, not a recommendation. Pull the current runner release instead of the minimum version number quoted in the changelog — newer releases carry every fix shipped since the pause, and the 30-day rule means you need to stay near-current anyway.

The Registration Trap: Why Auto-Update Won't Save an Old Runner

Here's the gotcha GitHub's own docs don't call out directly. Auto-update on a self-hosted runner only kicks in after the runner successfully registers with ./config.sh. If a runner is already below the minimum version, registration gets rejected first. Auto-update never gets a chance to pull a newer release.

That's a real chicken-and-egg problem. It hits teams provisioning runners from a golden image or a container that hasn't been rebuilt recently. A GitHub community discussion confirms the fix isn't waiting for auto-update. Bake a current runner tarball into the image or startup script before config.sh runs. Auto-update keeps it current from there.

# check what version a running self-hosted runner is on
cat _diag/*.log | grep -i "Runner Version"

# disable auto-update explicitly (you'll then own manual updates
# within 30 days of each new release, per GitHub's policy)
./config.sh --disableupdate

⚠️ Important: if you use --disableupdate, you're committing to manually updating that runner within 30 days of every new release GitHub ships — not just the current one. Most teams are better off leaving auto-update on and fixing the registration-time version at the image level instead.

How to Check and Upgrade GitHub Actions Self-Hosted Runners

1. Inventory your runner images and startup scripts. Anywhere a VM image, container image, or Kubernetes manifest pins a runner tarball URL or version string, that's a place a current runner release needs to land before September 25.
2. Confirm the version already registered. GitHub's Actions settings page lists each runner's version under Settings → Actions → Runners; cross-reference against anything still on 2.328.x or earlier.
3. Rebuild images with the current runner release, not the bare minimum. The reported cgroup issues with v2.329.0 are reason enough to stay off the exact floor version.
4. Re-run registration in a non-production environment first if you manage runners through Terraform, Pulumi, or a custom operator — the registration handshake is where the version gate lives, and that's the step most likely to silently fail in automation.
5. Leave auto-update enabled on any runner you don't have a strict reason to pin, so this doesn't recur at the next enforcement wave.

Once your runners are current, the caching and performance guide and the security best practices guide are worth a pass too — a version audit is a natural time to also check for other drift. And if you want visibility into runner health going forward instead of finding out at the next deadline, the monitoring and debugging guide covers exactly that.

Upgrade Now or Wait?

Upgrade now, in a staging environment — the brownout windows running through September 18 are exactly the feedback loop to use. GitHub's first enforcement attempt got paused amid reports of v2.329.0 breaking legacy cgroup setups, so treat this as a real change to test, not a checkbox. Because the failure mode is silent queuing rather than a loud error, teams that wait until the deadline usually find out from a stalled deploy, not a warning.

If your runners already sit on GitHub-managed VM images or an actively maintained container base, this is likely a non-event; auto-update has probably already carried you past 2.329.0. The risk concentrates in golden images, air-gapped runners, and anything provisioned by infrastructure code that hasn't been touched since early 2026.

Frequently Asked Questions

Q: What's the actual minimum GitHub Actions runner version required?
A: 2.329.0 for registration. But pull the current release instead of the bare minimum — reported compatibility issues with 2.329.0 on legacy cgroup setups were tied to GitHub's paused first enforcement attempt, and the 30-day rule means you need to stay near-current anyway.

Q: Will my existing, already-registered runners just stop working on September 25?
A: Not immediately for registration — that gate only applies to new or re-registering runners. But the separate 30-day job-execution rule means an already-registered runner that falls too far behind on releases will stop picking up jobs, even without re-registering.

Q: Does this affect GitHub Enterprise Server customers?
A: No. The enforcement applies to self-hosted runners on github.com — including GitHub Enterprise Cloud and its data-residency variant. GitHub says Enterprise Server isn't impacted at this time.

Q: Can I just disable auto-update and update manually on my own schedule?
A: Yes, with ./config.sh --disableupdate, but you then own updating within 30 days of every new release GitHub ships, not a schedule you control. For most teams, leaving auto-update on and fixing the version at the image level is simpler.

Quick Summary

• Enforcement has been live for GitHub Enterprise Cloud data-residency orgs since July 31, 2026; for the rest of github.com, brownout windows are running now ahead of full enforcement September 25
• Minimum version for registration is 2.329.0, but pull the current release — reported kernel compatibility problems with the bare minimum on legacy cgroup setups were tied to GitHub pausing its first enforcement attempt in March
• Auto-update can't rescue a runner that's already below the minimum, because registration is rejected before auto-update gets a chance to run
• Fix it at the image or startup-script level, not by waiting for the runner to self-update
• GitHub Enterprise Server customers are not impacted at this time, per GitHub's changelog

Rebuild your GitHub Actions self-hosted runners with the current release now, register one in staging during a brownout window, and confirm the version shown in GitHub's Actions settings page before September 25 turns this into a production incident.