GitHub Actions Self-Hosted Runner Minimum Version: Check 2.329.0

Separate registration from job execution#

The third row is why this article is not the same as a Node24 action failure. The Node24 self-hosted runner guide covers action runtime and host compatibility. This article is about GitHub’s runner fleet enforcement and update policy.

Inventory every runner that can receive production jobs#

Start with the repository, organization, or enterprise scope that owns the runner. For a repository runner, the REST API can expose the version and labels:

1
gh api --paginate repos/OWNER/REPO/actions/runners \
2
  --jq '.runners[] | [.name, .version, .os, .status, .busy, (.labels | map(.name) | join(","))] | @tsv'

The API response is scope-specific. Querying a repository does not inventory an organization or enterprise runner group, and a permission error does not prove that all runners are current. Also inspect the runner settings page and the image or service definition that creates the machine.

For each production-capable runner, record:

• installed runner version and the version returned by the API;
• operating system, architecture, labels, and runner group;
• whether automatic updates are enabled;
• whether the runner is a long-lived host, container image, or ephemeral instance;
• the workflow labels that can route builds to it;
• the last successful update and the outbound access required to reach GitHub.

Pay special attention to immutable images. An ephemeral runner can start with an old binary on every scale-out even when a long-lived runner on the same label updates correctly.

Upgrade with a canary runner first#

A safe rollout keeps a path back to a known runner without silently routing production jobs to an old version:

1. Build or download the current runner package for the host OS and architecture.
2. Start one canary runner in the same runner group with a temporary label.
3. Run a small workflow that checks checkout, cache, artifacts, containers, and the secrets boundary used by the real job.
4. Upgrade one production runner or the image template, then drain and restart it.
5. Verify that the API reports the expected version and that jobs select the upgraded machine.
6. Roll the image or service change across the rest of the fleet.

GitHub’s self-hosted runner reference says runners update automatically by default, but that behavior still depends on a runner that can reach the update service. If auto-update is disabled, make the update cadence part of image maintenance rather than waiting for a brownout.

Do not rely on changing runs-on: ubuntu-latest to upgrade a self-hosted machine. A self-hosted label still selects infrastructure that you manage. If the job can safely use a GitHub-hosted runner, remove the self-hosted labels intentionally; otherwise upgrade the selected machine or image.

Check the product-specific dates#

GitHub’s minimum-version enforcement timeline separates the product cohorts:

• GitHub Enterprise Cloud: brownouts start with registration checks on August 24, 2026; the staged schedule continues through the September 25, 2026 enforcement date.
• GitHub Enterprise Cloud with Data Residency: the announcement lists a July 31, 2026 full-enforcement date and a separate earlier brownout schedule.
• GitHub Enterprise Server: the announcement does not cover GHES; use the runner compatibility guidance for the GHES release you operate.

Dates are a reason to finish the inventory now, not a reason to assume every organization is on the same rollout. If a runner serves more than one GitHub product or environment, track each registration independently.

Verify the runner at the workflow boundary#

After the rollout, run the workflow on every label that can receive the production job. Confirm:

1. The job was scheduled on the upgraded runner, not another machine with the same labels.
2. The runner API and local service report the expected version.
3. JavaScript actions start with their required runtime.
4. Container actions and service containers still work on the host.
5. The runner can receive a later automatic update.
6. A new ephemeral instance uses the new image rather than an old cached layer.

If the job then fails because a secret is empty, a tool is missing, or a cache is read-only, keep that diagnosis separate. Runner version enforcement only answers whether the machine can register and accept work; it does not validate every workflow dependency.

The practical takeaway is to treat self-hosted runners like a maintained dependency. Check v2.329.0 for the registration boundary, keep the fleet inside the ongoing update window, and roll the change through the same labels and images that production actually uses.

FAQ#