GitHub Actions Runner Controller 0.15.0 Targets Reliability at Scale

GitHub has released Actions Runner Controller (ARC) 0.15.0, introducing reliability, scalability, and observability improvements for organisations running self-hosted GitHub Actions runners on Kubernetes. The October 1 release focuses on reducing unnecessary Kubernetes API requests, improving controller throughput and making upgrades and shutdowns more predictable, particularly for environments managing large numbers of runner scale sets.

ARC is a Kubernetes operator that automatically scales self-hosted runners in response to workflow demand. It allows organisations to run their own execution infrastructure while creating and removing runner instances as jobs arrive and finish. This is particularly useful for enterprises that need control over build environments, network access, compute resources, or workload isolation without maintaining a permanently provisioned pool of runners.

One of the main themes in version 0.15.0 is reducing the work the controller performs to keep runner resources in sync. Controller updates now use Kubernetes patch requests instead of full update requests, reducing the size of API payloads. Runner status aggregation has also moved to metrics for EphemeralRunnerSet and AutoscalingRunnerSet, reducing the number of status updates sent to the Kubernetes API.

The controllers now filter incoming events to avoid unnecessary reconciliation, while listener API client rate limits can be configured through queries-per-second and burst settings. Teams can also configure reconciliation concurrency globally or for individual controllers using max-concurrent-reconciles flags. Together, these changes give platform teams more control over how ARC behaves under load and should help reduce avoidable processing and API traffic in larger deployments.

The release also addresses lifecycle management. Patch-version upgrades now update resources in place, maintaining a one-to-one mapping between autoscaling runner sets and ephemeral runner sets and reducing disruption during upgrades.

Controller shutdown behaviour has also been improved. The terminationGracePeriodSeconds setting is now configurable and aligned with the controller manager's graceful-shutdown timeout, allowing operators to better control how the controller exits during restarts or upgrades.

ARC can also re-register a runner scale set when its recorded counterpart no longer exists in the GitHub Actions service. This helps the controller recover from a mismatch between its local Kubernetes state and the scale-set state maintained by GitHub.

Finally, ephemeral runners can be deleted faster when their runner pods exit successfully because ARC skips an additional server-side check for runner removal. While individually small, these changes address the operational details that become increasingly important when runner environments are created and destroyed continuously.

Moving runner status aggregation into metrics is particularly relevant to teams operating ARC as shared CI infrastructure. Large runner fleets generate frequent lifecycle events as jobs are queued, runners are provisioned, workloads execute, and ephemeral environments are removed. Reducing status patches can ease pressure on the Kubernetes API, while metrics provide a more suitable basis for monitoring aggregate controller and runner behaviour.

Configurable reconciliation concurrency and listener rate limits also help operators tune the balance between throughput and API pressure. However, these settings are not simply performance switches: increasing concurrency can increase the rate at which the controller interacts with Kubernetes and GitHub services. Teams should therefore validate changes against their workload patterns and cluster capacity rather than assuming higher concurrency is always better.

ARC is part of a broader move towards dynamically managed CI execution infrastructure. CircleCI's Machine Runner Orchestrator, for example, focuses on scaling machine-based runners and supports different resource classes, including CPU, GPU, and ARM workloads. ARC instead integrates directly with Kubernetes to manage GitHub Actions runner scale sets, commonly using ephemeral runner environments. The two approaches address the same broad challenge, matching execution capacity to CI demand, but differ in their platform integration and runner execution models

For organisations already standardised on GitHub Actions and Kubernetes, ARC provides a native way to manage runner capacity alongside other cluster resources. Its trade-off is that platform teams must also operate the controller, manage Kubernetes capacity and understand how runner scaling interacts with cluster scheduling, API limits and workflow demand.

ARC 0.15.0 is an incremental release, but its emphasis reflects a significant engineering concern: once CI infrastructure serves many repositories and teams, controller efficiency and lifecycle reliability become delivery concerns in their own right.