SuperCI vs Actions Runner Controller (ARC)
ARC is GitHub's own, and the right choice when you already run Kubernetes. SuperCI needs no cluster: it starts a machine for each job and nothing runs in between.
Actions Runner Controller (ARC) is, in its own words, “a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions”. GitHub calls it its recommended Kubernetes-based way to autoscale runners. SuperCI does the same work without a cluster: it starts a machine in your cloud account for each job.
Side by side
| What | SuperCI | Actions Runner Controller |
|---|---|---|
| You need | An AWS, Cloudflare or Modal account | A Kubernetes cluster and Helm 3 |
| A job runs in | A machine of its own | A pod in your cluster |
| Between jobs | A small function waits | A controller and a listener for each set of runners, and whatever nodes your cluster keeps |
| One job per runner | Yes | Yes |
| Docker in a job | There, on AWS and Cloudflare | Docker-in-Docker in privileged mode, or Kubernetes mode with limits |
| Works with | GitHub Actions and GitLab CI | GitHub Actions |
| Licence | MIT | Apache-2.0 |
| Help from | The repository | GitHub Support, for the current version |
What ARC asks of you
ARC is installed with two Helm charts: the controller, then a set of runners. After that it is yours to run, with the cluster under it. GitHub’s support page says so plainly:
To ensure a smooth adoption of Actions Runner Controller, we recommend that organizations have staff with expert-level knowledge of container orchestration.
It also lists what its support does not cover: the cluster itself, networking, building images in ARC, storage.
Jobs that use containers need a choice. In Docker-in-Docker mode, “the Docker-in-Docker container requires privileged mode”. In Kubernetes mode each job needs a job container, and building a container action from a Dockerfile is not supported.
GitHub also recommends against sharing the cluster: “using a shared Kubernetes cluster for production workloads could pose a security risk”.
What SuperCI does instead
There is no cluster. A small control plane in your account (on AWS, a Lambda function) hears from GitHub that a job is queued, starts a machine of the size the job’s label asks for, and ends it when the job is done. On AWS that machine is a whole virtual machine with Docker on it, so container jobs, services and docker build work as they do on GitHub’s own runners.
Nothing but that function runs between jobs, so an idle day costs close to nothing.
Where ARC is the better choice
- You already run Kubernetes and have people who know it. Then runners are one more workload, scheduled and observed like the rest.
- You want GitHub behind it. ARC is developed with the GitHub Actions team, and GitHub Support covers its current version.
- Jobs must run inside the cluster, beside the services they test or deploy to.
Pick SuperCI if you do not want a cluster to look after for the sake of CI, if you want a fresh virtual machine for each job, or if you also run GitLab CI.
Sources
Read on 9 October 2026.
- About Actions Runner Controller: what it is, pods, runners that take one job, the listener.
- Quickstart for Actions Runner Controller: what you need, and the two Helm installs.
- About support for Actions Runner Controller: the staff it recommends, and what GitHub Support covers.
- Deploying runner scale sets: the container modes and their limits, and the advice on shared clusters.
- Runner container hooks for Kubernetes: what Kubernetes mode does not support.
- Self-hosted runners reference: ARC as GitHub’s recommended Kubernetes-based way.
- actions/actions-runner-controller: the licence and who maintains it.