Should I upgrade to GitHub Actions Self-Hosted Runner Upgrade Policy now?

Decide whether to keep self-hosted runners, move more jobs to hosted runners, or automate image refreshes after GitHub introduced hard minimum runner version enforcement that can block registration and eventually job routing.

Move most workflows to GitHub-hosted runners, unless jobs need private network access, custom hardware, or signing; keep self-hosted only for those exceptions.

Blockers

Who this is for

Candidates

Keep self-hosted runners, but automate image refreshes and ephemeral re-registration

As of 2026-03-15, GitHub says that starting March 16, 2026 it blocks configuration and registration of self-hosted runners older than v2.329.0, and separately says runners that miss software updates for more than 30 days can stop receiving jobs. The Actions Runner releases page currently shows v2.331.0 and notes a progressive release policy, so the workable self-hosted pattern is automated image rebuilds or redeploys that install a current runner before `./config.sh`.

When to choose

Best for enterprise + compliance + high-scale or monorepo + microservices teams where jobs need private network access, custom hardware, local services, or full control of the machine image and you already have Kubernetes or VM automation. As of 2026-03-15, choose this only if you can rebuild images, roll runners, and refresh registration flows on a schedule instead of treating runners as long-lived pets.

Tradeoffs

You keep the flexibility and cost model of self-hosted runners, and GitHub documents self-hosted usage as free with GitHub Actions, but you now need a real fleet-management path for runner binaries, base OS patching, access policies, and cleanup. Ephemeral or just-in-time registration reduces drift, while ARC runner scale sets can scale to zero and back up automatically.

Cautions

GitHub says self-hosted runners should almost never be used for public repositories, and even private or internal repos with fork-based pull requests need care because untrusted workflow code can compromise the runner environment. If you disable auto-updates, GitHub requires updates within 30 days of a new runner release; GitHub also documents self-hosted limits such as 1,500 runner registrations per 5 minutes per repository, organization, or enterprise, 10,000 runners per runner group, 5-day job execution time, and 24-hour queue time. For ARC-based ephemeral fleets, GitHub tells you to collect and retain logs from the controller, listeners, and ephemeral runners.

Sources

Move most workflows to standard GitHub-hosted runners and keep self-hosted only for exceptions

As of 2026-03-15, standard GitHub-hosted runners give you a fresh GitHub-managed VM or container for each job, standard hosted usage is free and unlimited on public repositories, and private repositories use included minutes first and then per-minute billing. GitHub's pricing page currently lists Linux 2-core x64 at $0.006 per minute, Linux 2-core arm64 at $0.005 per minute, Windows 2-core at $0.010 per minute, and macOS at $0.062 per minute.

When to choose

Best for small-team + low-ops + cost-sensitive or enterprise + compliance teams where only a narrow slice of workflows truly needs private network access, custom hardware, or privileged local tooling. Use this when you want untrusted pull requests, test matrices, and routine build jobs off the self-hosted fleet, while keeping self-hosted only for deployment, signing, or internal-resource jobs.

Tradeoffs

This removes most runner-version enforcement and patching work from your side and gives you cleaner isolation for untrusted jobs. The tradeoff is ongoing GitHub-hosted compute spend for private repositories, less control over the machine image, and no direct access to your internal network unless you redesign the workflow or keep an exception path.

Cautions

GitHub documents that hosted runner IP ranges are too large and change often enough that they are not recommended as allowlists for internal resources. If allowlisting, private networking, or static egress is a hard requirement, GitHub points you toward larger runners with static IP ranges or self-hosted runners instead.

Sources

Replace part of the self-hosted fleet with GitHub-hosted larger runners and custom images

As of 2026-03-15, GitHub documents larger runners for Team and Enterprise Cloud plans with static IPs, Azure private networking, autoscaling, and custom images, while custom images are billed at the same per-minute rates as the larger runner that uses them. GitHub also says larger runners are always billed per minute and do not consume included minutes.

When to choose

Best for enterprise + low-ops + compliance or monorepo + microservices teams where standard hosted runners are too limited but you still want GitHub-managed compute instead of owning a self-hosted fleet. This is the middle ground when version enforcement made self-hosted image maintenance painful, but you still need firewall allowlists, prewarmed toolchains, or bigger managed machines.

Tradeoffs

You get managed runners with more CPU, RAM, disk, runner grouping, autoscaling, and custom images, while avoiding most self-hosted OS and runner-binary lifecycle work. The tradeoff is explicit per-minute spend, Team or Enterprise plan requirements, and some feature gaps that vary by platform.

Cautions

As of 2026-03-15, custom images are in public preview and GitHub recommends generating them on a weekly schedule so dependencies and security patches stay current. Larger runners are always billed per minute, and GitHub documents that macOS larger runners still do not support Azure private networking or static IP assignment.

Sources

Facts updated: 2026-03-15
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Should I upgrade to GitHub Actions Self-Hosted Runner Upgrade Policy now?"
Missing something? Request coverage