GitHub Actions Self-Hosted Runner Enforcement: Upgrade and Audit Guide

GitHub Actions began full minimum-version enforcement for self-hosted runners on GitHub Enterprise Cloud on September 29, 2026. An old runner can now fail to register, stop receiving jobs, or leave workflows waiting even though the machine itself looks healthy.

This is not a one-time migration to version 2.329.0. That version is the registration floor for the new Actions architecture, while the runtime requirement continues moving as GitHub publishes runner releases.

Registration and runtime rules are different

GitHub applies two requirements:

• A runner older than 2.329.0 cannot configure, register, or re-register.
• A registered runner must install new runner releases within 30 days. A stale runner can stop receiving workflow jobs even when it remains visible in repository or organization settings.

Critical security releases can shorten the practical response window because GitHub may pause job queuing until the runner is updated. Treat runner software like a production dependency, not a static appliance image.

The September enforcement applies to GitHub Enterprise Cloud. GitHub Enterprise Cloud with Data Residency began enforcement earlier, on July 31, 2026. GitHub Enterprise Server is not affected by this cloud timeline.

Inventory the fleet

Start with the GitHub REST API rather than logging into every host:

gh api --paginate \
  -H 'X-GitHub-Api-Version: 2026-03-10' \
  /orgs/ORG/actions/runners \
  --jq '.runners[] | [.id, .name, .os, .status, .busy, (.labels | map(.name) | join(","))] | @tsv'

The runner list helps you find offline and unexpectedly busy agents, but it is not sufficient by itself for a version audit. GitHub recommends using runner registration events in the enterprise or organization audit log because those events include the registering version. Registration events show actively registering clients, not a complete historical inventory, so combine them with your infrastructure source of truth.

Record at least:

• runner name, group, labels, OS, and architecture;
• runner application version;
• image or AMI version;
• auto-update status;
• last registration and last successful job time;
• owner and replacement procedure.

Query a version's support deadline

GitHub added REST endpoints that return the end-of-life schedule for a specific runner version:

gh api \
  -H 'X-GitHub-Api-Version: 2026-03-10' \
  /orgs/ORG/actions/runners/deprecations/2.329.0

The response can include runtime_deprecates_at. Use that timestamp to create alerts before a version stops receiving jobs. Query the versions that actually exist in your fleet instead of assuming one global date.

A simple monitoring design runs daily, groups runners by version, looks up each version's schedule once, and alerts when a deadline is within 14 days. Cache the lookup response to avoid unnecessary API traffic.

Auto-update versus immutable runner images

Persistent runners update automatically by default. GitHub checks for an update when a job is assigned and can also update an idle runner within a week of a release.

Ephemeral container or VM runners often use --disableupdate because modifying a running image defeats immutability. That is valid, but it transfers responsibility to your image pipeline. Rebuild, scan, test, and roll out a new image after every runner release—major, minor, or patch.

For an immutable fleet:

1. Subscribe to releases from actions/runner.
2. Trigger an image build when a new version appears.
3. Verify checksums and signatures according to your supply-chain policy.
4. Run representative checkout, cache, artifact, OIDC, container, and deployment jobs.
5. roll out a canary runner group;
6. replace the remaining instances before the 30-day deadline;
7. prevent old images from launching through admission policy or image lifecycle rules.

Do not merely update running containers. If an autoscaler can launch an old cached image tomorrow, the fleet is still vulnerable to enforcement.

Upgrade safely

For a persistent runner, follow GitHub's supported update process and verify the service afterward. For a fleet managed by Actions Runner Controller, update the runner image reference in GitOps and let the controller replace Pods.

Before draining a runner, check whether it is busy. Do not terminate an agent during a deployment or long-running test. Move traffic through runner groups or reduce autoscaler capacity gradually.

After rollout, run a workflow that exercises:

jobs:
  verify-runner:
    runs-on: [self-hosted, linux, x64]
    steps:
      - uses: actions/checkout@v5
      - run: |
          echo "runner=$RUNNER_NAME"
          uname -a
      - uses: actions/upload-artifact@v4
        with:
          name: runner-verification
          path: README.md

Confirm both the main steps and post-job cleanup complete. Cache and credential actions frequently perform important work after the visible build step.

Operational guardrails

• Set an SLO for runner freshness, such as every active version being less than 14 days old.
• Alert on queued-job age by label and runner group.
• Keep capacity in a canary group before fleet-wide image promotion.
• Remove unused registration tokens and offline runner records.
• Test outbound access to GitHub update and Actions endpoints.
• Document whether auto-update is enabled; do not leave the choice implicit.
• Treat runner images as deployable artifacts with owners and rollback versions.

What to do today

If workflows are already queued, compare their runs-on labels with online runners, verify the runner application version, and query its deprecation schedule. Update or replace stale runners before retrying jobs. If an old binary cannot register, download a current runner package or deploy a fresh image rather than repeatedly running the old configuration script.

For the other major September runtime change, read GitHub Actions Node 20 removal and Node 24 migration. For high-volume reporting, see the GitHub Actions workflow-run query change.

Building and operating CI/CD workflows? Explore this GitHub Actions course on Udemy. Affiliate link: DevOpsBoys may earn a commission at no extra cost to you.

Sources

• GitHub Changelog: Self-hosted runner enforcement date moved
• GitHub Changelog: Minimum version enforcement timeline
• GitHub Docs: Self-hosted runner reference
• GitHub Docs: REST API for self-hosted runners