GitHub Actions Self-Hosted Runner Deadline: September 29

GitHub Actions’ revised minimum-version enforcement for self-hosted runners on GitHub Enterprise Cloud begins Tuesday, September 29, 2026. GitHub’s September 28 update moved the date from September 25; the requirements did not change. The detail easy to miss: version 2.329.0 is the registration floor, not a permanent “safe to run jobs” version. Here is a focused fleet audit for administrators, including an API check and the image templates most likely to reintroduce an old runner.

Source check: 29 September 2026. This guide summarizes current GitHub documentation and is not a live test of an Actions fleet. AI tools assisted with drafting; an editor checked the cited official sources.

What changed—and what did not

On September 28, GitHub moved the full enforcement date for GitHub Enterprise Cloud to September 29. The minimum-version rules stayed the same. Runners older than 2.329.0 cannot register or register again; existing runners below the higher, applicable job-execution minimum can stop receiving workflow jobs even if they are already registered. GitHub Enterprise Cloud with Data Residency reached its enforcement date on July 31. GitHub Enterprise Server is not affected by this particular rollout.

Scope matters before anyone patches a machine. The September change concerns GitHub Enterprise Cloud, not every computer used by Actions. GitHub-hosted runners are managed by GitHub, so this minimum-version check is for teams operating self-hosted runners.

Separate registration floor from runtime floor

Do not pin a fleet to 2.329.0 and consider it finished. That number is the announced minimum for registering or re-registering a runner. Job execution has a separate, higher version requirement that advances as runner releases age out. GitHub’s enforcement timeline says the service can stop queueing work when a runner misses an available update by 30 days; a critical security update can also suspend job queueing until installation.

This split explains two otherwise confusing outcomes: a runner can register successfully and later fail to pick up jobs, or a long-idle machine can fail when it tries to re-register. For an individual version, GitHub’s deprecation API returns registration and runtime support dates. Check those dates for the version you actually run instead of inferring runtime eligibility from the registration minimum.

Build a real inventory, not a list of active machines

Start with the registered fleet. GitHub’s organization runner endpoint returns each runner’s name, operating system, status and version. With GitHub CLI authenticated for an organization administrator, this read-only command prints a compact inventory:

gh api --paginate --jq '.runners[] | [.name, .os, .status, .version] | @tsv' \
  'orgs/ORG/actions/runners?per_page=100'

Replace ORG with organization slug. The GitHub CLI API command supports --paginate and --jq for this read-only inventory. If you register runners at repository or enterprise scope, inventory those scopes too; one organization list is not a complete fleet map. The REST API requires appropriate administrative or self-hosted-runner read access.

Then compare every distinct version with its current deprecation dates. GitHub’s runner version deprecation endpoint returns separate registration and runtime support dates. For an organization-level runner, the REST endpoint follows this pattern:

gh api 'orgs/ORG/actions/runners/deprecations/VERSION'

Replace VERSION with the value from inventory. The response distinguishes registration and runtime support; use both. GitHub also exposes equivalent repository-level endpoints.

Update images and bootstrap code, not only running hosts

A clean inventory today can still become stale at the next rebuild. Search the places that create runners: VM images, container images, runner configuration files, installation scripts, and deployment automation. GitHub specifically recommends updating installation scripts, VM and container images, and recreating runners built from older cached images or templates.

Self-hosted runners auto-update by default. That default does not help a fleet whose update is disabled or whose image recreates a pinned old version. GitHub’s runner reference says manually maintained runners must be updated regularly; missed updates beyond 30 days can stop job queueing. Check for the --disableupdate registration flag and make sure network policy permits the update path your design depends on.

1. Export registered versions, including offline runners.
2. Group by Enterprise Cloud, Data Residency, or GHES so teams apply right rollout.
3. Flag any version below registration minimum or close to its runtime deprecation date.
4. Update live hosts and every image, script, or controller that can recreate them.
5. Confirm runner returns online and accepts a representative workflow; retain an alternate compliant runner for critical queues while updating.
6. Schedule recurring version checks from the deprecation API instead of hard-coding one deadline.

Version compliance is not runner isolation

Passing version checks does not make an untrusted workflow safe to run on a self-hosted host. GitHub’s secure-use guidance warns that if untrusted contributors can open pull requests against a repository, they can compromise its runner environment and expose local secrets or tokens; shared organization or enterprise runners can widen impact across repositories. Restrict which repositories can use a runner group, keep sensitive credentials off general-purpose runner hosts, and treat workflow changes from less-trusted contributors as a separate security boundary.

For a broader primer on workflow structure and permissions, see our GitHub Actions CI/CD guide. For a separate release-credential example, see our guide to staging npm packages before publishing.

September 29 is a deadline, not a durable version target. Audit both floors now, remove stale runner sources, and let GitHub’s deprecation dates drive the next maintenance window.