GitHub has released Actions Runner Controller (ARC) 0.15.0, introducing reliability, scalability, and observability improvements for organizations 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, allowing organizations to run their own execution infrastructure while creating and removing runner instances as jobs arrive and finish.
One of the primary themes in version 0.15.0 is minimizing the work the controller performs to keep runner resources synchronized, according to the report. Controller updates now rely on Kubernetes patch requests rather than full update requests, shrinking the size of API payloads. Runner status aggregation has shifted to metrics for EphemeralRunnerSet and AutoscalingRunnerSet, cutting down the number of status updates dispatched to the Kubernetes API. The controllers now filter incoming events to prevent 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. 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. 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, and ephemeral runners can be deleted faster when their runner pods exit successfully because ARC skips an additional server-side check for runner removal.
The report states that 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. However, configurable reconciliation concurrency and listener rate limits aren't simply performance switches, the report notes: increasing concurrency can raise 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.
These changes tackle the operational details that become increasingly important when runner environments are created and destroyed continuously. Together, they give platform teams more control over how ARC behaves under load and should help reduce avoidable processing and API traffic in larger deployments. For organizations already standardized on GitHub Actions and Kubernetes, ARC provides a native way to manage runner capacity alongside other cluster resources. The 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. The report emphasizes that ARC 0.15.0 is an incremental release, but its focus 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. Platform teams operating at scale will need to balance the flexibility of self-hosted infrastructure against the operational overhead of managing controller behaviour and cluster resources. As continuous integration becomes mission-critical shared infrastructure rather than isolated build tooling, the stability and performance characteristics of controllers like ARC increasingly shape development velocity across entire engineering organizations.