Should you put runner capacity in Kubernetes?
Choose ARC when Kubernetes is where your team intends to operate GitHub Actions runners. Actions Runner Controller scales self-hosted GitHub Actions runners on Kubernetes. The README describes runner scale sets that scale with workflows in a repository, organization, or enterprise, and runners that can be ephemeral containers.
That capability comes with a deployment to manage. GitHub's tutorial requires a Kubernetes cluster and Helm 3, then separate controller and runner scale-set installations. If you want an AWS VM rather than a Kubernetes workload, consider the alternatives below before committing to that operating model.
What our sandbox established
In our run on October 2, 2026, at commit 1945b42, the sandbox install succeeded in 152 seconds, the build step succeeded in 312 seconds, and the test command exited 1 after 56 seconds.
Our harness records each step's success flag, elapsed time, exit code, timeout status, and retained output tail. It stores parsed test results separately. The attached stored parser summaries report 20 passing and 13 failing package results, total 33. They do not establish exhaustive unique test coverage; no complete-log reconciliation or new execution was performed for this correction. Packages without test files are not failed tests, and the record does not supply a skipped-test count.
The recorded sandbox had 3 CPUs, 8 GB RAM, and the golang:1.24-bookworm image. The install tail says go1.27.1 was downloaded. The successful build step ends with vet-exit:0. These observations support the recorded command outcomes, without proving a controller installation or successful workflow execution.
See how MrKeyoor tests software for the publisher's explanation of command recording and sandbox limits. That page describes the methodology available when retrieved for this correction; it does not establish which revision governed the October 2 run.
The failures need separate explanations
The retained test tail names failures in the experimental chart tests, including TestExperimentalRunnerRejectsMalformedLists, TestExperimentalRunnerLegacyEnvPrecedence, and TestExperimentalRunnerRejectsDuplicateIdentities. It also names TestAPIs failures in both controller packages, TestE2E, and TestARCJobs.
Those names identify affected areas, but the supplied tail does not establish their causes. In particular, it does not show a missing-kubeconfig error. Attributing every failure to an absent cluster would conceal the experimental chart failures and go beyond this record. The named failures are examples from the retained tail, not a reconstruction of all 13 failing package results.
The record does not demonstrate runner registration, a completed GitHub Actions job, production scaling behavior, queue latency, or workload isolation. Audit data is null, and scan coverage is unknown. This run provides no security verdict.
Follow the scale-set path and check authentication scope
The README directs new users to runner scale sets and labels the older autoscaling modes legacy, maintained by the community only. Follow the GitHub setup tutorial rather than assuming every older example has the same maintenance arrangement.
The tutorial recommends a GitHub App for repository or organization runner scale sets where possible. Enterprise runner scale sets require personal access token (classic) authentication. It also recommends separate namespaces for runner and operator pods, Kubernetes secret references instead of plaintext CLI secrets, and retained controller, listener, and ephemeral-runner logs before production use.
The experimental charts in gha-runner-scale-set-0.14.2 are unsupported for production workloads. The release notes say they may be modified or republished without notice. Their evaluation status matters independently of the failures observed in our sandbox.
Compare AWS alternatives by who manages the lifecycle
Terraform AWS GitHub Runner uses Terraform infrastructure and AWS Lambda functions to manage autoscaling runners on AWS spot instances. Its supplied README describes a GitHub App and AWS infrastructure setup. The philips-labs repository is marked deprecated and directs readers to github-aws-runners/terraform-aws-github-runner. That destination was not independently supplied as a fetched source, so check its current documentation before adopting it. This is an alternative operating model to ARC, not an ARC add-on.
EC2 GitHub Runner starts and stops an EC2 runner as part of a GitHub Actions workflow. Choose this narrower model when the workflow should explicitly manage an AWS runner's lifecycle. Its README requires a cleanup job and warns that omitting it leaves the instance running. It replaces the Kubernetes runner-management approach for that use case; it does not provide evidence about ARC compatibility or comparative performance.
Ratings and their limits
These are editorial ratings, not benchmark results. The rubric runs from 1 for weak or obstructed evidence to 5 for the strongest evidence within the stated dimension. For setup, higher means fewer deployment prerequisites; for documentation, clearer task guidance; for community, broader documented participation; for maturity, a clearer maintained deployment path. A community rating does not measure adoption or response time, and a maturity rating does not certify reliability.
Setup ease is 2/5 because deployment requires Kubernetes, Helm, authentication, and two installations despite successful sandbox install and build steps. Documentation is 4/5 because the supplied tutorial covers prerequisites, authentication, verification, and a workflow trial, while the README distinguishes legacy material. Community is 5/5 on the narrow participation rubric: the README documents collaboration among the GitHub Actions team, named external maintainers, and contributors. Maturity is 4/5 because the documented scale-set path has deployment guidance and release maintenance, with explicit limits around legacy modes and experimental charts.
Before adoption, complete the tutorial in an evaluation cluster, run a representative workflow, inspect retained logs, and verify runner cleanup. Our sandbox command results cannot substitute for that deployment trial.