From GitHub-hosted runners to ARC scale sets in 2026: an adoption/migration note on private networks, warm images, and queue control

A real server-rack photograph fits this article because ARC only starts to make sense when runner capacity stops being an abstract CI setting and becomes infrastructure you place, isolate, and maintain as part of a live cluster.[7]

Teams often reach for Actions Runner Controller too early. The usual trigger is frustration with GitHub Actions startup time, package installs, or occasional resource ceilings. But GitHub already gives you two lower-friction layers before you add Kubernetes to the problem: standard GitHub-hosted runners and larger GitHub-hosted runners.[1][2]

That distinction matters because larger runners already cover more ground than many platform teams remember. GitHub's own docs list static IP addresses, Azure private networking, runner groups, autoscaling, GPU options, and custom images on the managed side.[1][2] If your complaint is mainly "our jobs need a bigger box" or "we need a more repeatable VM image," ARC is often solving the wrong problem.

The better migration question is narrower: when does runner placement itself become part of your platform architecture? That is the point where ARC starts to make sense. GitHub describes ARC as the reference Kubernetes-based autoscaling solution for self-hosted runners and recommends it for organizations that already have Kubernetes infrastructure and teams with Kubernetes expertise.[3][4] In other words, ARC is not a general upgrade from hosted runners. It is a control-plane choice.

Image context: the cover uses a real Wikimedia Commons server-rack photograph rather than a diagram because this migration is ultimately about operating real capacity. Once you move to ARC, queues, images, network paths, and failure handling all become part of infrastructure stewardship rather than a hosted service default.[7]

What you already get before ARC

Start with the baseline. Standard GitHub-hosted runners give you fresh execution environments with the runner application and common tools preinstalled, and GitHub handles image maintenance and upgrades for you.[1] The docs also note that the software set on GitHub-owned images is updated weekly, with the exact tool manifest exposed in workflow logs.[1] That is a strong default for most repositories because it keeps the build surface disposable.

The next layer is larger runners, which are still GitHub-hosted but add the features that often get cited as reasons to self-host in the first place: more CPU, RAM, and disk, static IPs, Azure private networking, autoscaling, runner grouping, GPU options, and support for custom VM images.[1][2] That means a surprising number of "we need more control" complaints can be solved without taking on cluster operations.

The simplest decision rule is this:

Stay on standard hosted runners if your main priority is clean, low-maintenance execution.
Move to larger runners if the missing piece is machine size, network allowlisting, private Azure connectivity, GPUs, or custom images.

If those two layers already cover the need, ARC is pure overhead.

Where ARC actually starts to earn its keep

GitHub's self-hosted runner docs describe the real benefit plainly: you get more control over hardware, operating system, software tools, and access to machines or services your company already maintains.[3] ARC then turns that self-hosted flexibility into a Kubernetes-native autoscaling system.[4]

That usually matters in three cases.

First, data or service gravity. If jobs need to sit close to cluster-local services, internal package mirrors, private registries, or east-west traffic that is awkward to expose to hosted VMs, ARC lets you keep execution inside the same operational neighborhood.[3][4]

Second, existing infrastructure economics. Self-hosted runners are free to use from GitHub's perspective, but your team pays for the machines and the operations burden.[3] That only becomes attractive when you already have cluster capacity, procurement patterns, or hardware layouts that make reuse more efficient than buying more managed runner minutes.

Third, queue policy as platform policy. ARC is not just "runners in Kubernetes." It gives you runner scale sets with explicit runs-on targeting by scale-set name or labels, plus minimum and maximum runner settings that shape how much hot capacity you keep around.[5][6] If runner pools need to line up with namespaces, secrets, hardware tiers, or internal team boundaries, ARC gives you a clearer control surface than a pile of long-lived pets.

Those are real reasons. "We want faster npm install" is not.

What ARC changes operationally

GitHub's architecture write-up makes ARC's shape explicit. A controller manages the scale set, a listener long-polls GitHub Actions for Job Available messages, and ephemeral runner pods are created with just-in-time registration tokens when demand arrives.[4] Failed runner-pod creation is retried up to 5 times, and if no runner accepts the job, the Actions service can leave the assignment until the 24-hour limit is hit.[4]

That architecture brings two advantages.

One is cleanliness. GitHub's autoscaling reference recommends ephemeral self-hosted runners for autoscaling and says persistent autoscaling is not recommended, because ephemeral runners guarantee one job per runner and make clean-environment automation much safer.[3] ARC fits that model well.

The second is queue control. In the deployment docs, minRunners and maxRunners let you decide whether the scale set idles at zero, holds warm capacity, or caps concurrency.[5] GitHub also documents a maintenance pattern where setting both to 0 drains new work instead of creating fresh runner pods.[5] That is the kind of operational lever platform teams actually care about.

But the tax arrives immediately.

GitHub's own guidance says runner pods should live in a different namespace from the operator pods, Kubernetes secrets should be passed by reference rather than in plain text, and production workloads should be isolated because Actions workflows are designed to run arbitrary code.[5] The same page also says you should already have a way to collect and retain logs from controllers, listeners, and ephemeral runners before running production workloads.[5]

Then there is lifecycle maintenance. Self-hosted runners put operating-system patching and software upkeep back on your team.[3] If you disable automatic runner updates, GitHub requires you to update within 30 days of a new runner release or jobs stop getting queued to that runner.[3] That is not a theoretical footnote. It is now part of your platform contract.

A migration lane that usually works

The cleanest sequence is staged, not ideological.

Start by asking whether standard hosted runners already solve the problem with less ceremony.[1]
If the pain is bigger hardware, static IPs, Azure private networking, or image prep time, test larger runners before you self-host.[1][2]
Move to ARC only when runner locality, existing cluster economics, or queue policy inside Kubernetes is the actual requirement.[3][4][5]

When you do pilot ARC, keep the first lane narrow:

one scale set
one clear runs-on target or label set[6]
one bounded namespace
external log retention in place first[5]
a written update policy for runner binaries[3]

That sequence keeps the migration honest. It forces you to prove that ARC is buying something structural, not just giving you a more complicated way to run the same jobs.

One falsifier

If your team can explain the migration only in terms of startup speed, preinstalled tools, or "more power," stop and test larger runners with custom images first.[1][2] GitHub already sells that lane as a managed service. ARC earns its keep only when the runner fleet has to behave like part of your cluster, not like a bigger hosted VM.

Bottom line

ARC is the right move when CI execution has become infrastructure placement: private network reach, existing cluster economics, explicit queue policy, and ephemeral runners governed as Kubernetes workloads.[3][4][5][6] It is the wrong move when the real need is simply more compute, repeatable images, or less setup time, because managed GitHub-hosted options already cover a large share of that territory.[1][2]

That is the useful migration boundary. Do not adopt ARC because it feels more platform-shaped. Adopt it when the runner itself has become part of the platform.

cronfeed.work