Actions Runner Controller vs a managed runner service: which for a small team?
For a small team, a managed runner service. Actions Runner Controller (ARC) is a Kubernetes operator: you run a cluster, install two Helm charts, build a runner image, and reinstall the whole thing for each upgrade. GitHub recommends ARC "for organizations with Kubernetes infrastructure and teams that have Kubernetes expertise".
Skipbox gives you what ARC is for, self-hosted runners whose minutes GitHub doesn't bill, with nothing to operate. Your jobs run on your account's own machine for a flat $39 a month with unlimited minutes. Change one runs-on line.
What you run when you run ARC
From GitHub's ARC documentation:
| Piece | What it takes |
|---|---|
| A Kubernetes cluster | ARC's first prerequisite, with Helm 3. GitHub recommends running production workloads in isolation, because "using a shared Kubernetes cluster for production workloads could pose a security risk" |
| The controller | The gha-runner-scale-set-controller Helm chart: the controller manager pod, its roles and ARC's custom resource definitions |
| A runner scale set | The gha-runner-scale-set Helm chart, once per kind of runner: a listener pod that waits for jobs, and a runner pod created for each job |
| Authentication | A GitHub App or a personal access token (classic), stored as a Kubernetes secret |
| The runner image | GitHub's image holds "the least amount of packages necessary". For anything more, you build and publish your own |
| A container mode | Jobs that use containers need dind (a privileged Docker-in-Docker container in every runner pod) or kubernetes (persistent volumes or lifecycle hooks, and by default a job without a container: fails) |
| Scaling limits | minRunners and maxRunners per scale set. ARC has no schedule for them: a cron job of yours changes them |
| Logs and metrics | GitHub recommends collecting and retaining logs from the controller, listeners and runners before production; metrics come in Prometheus format |
Each runner pod is deleted when its job ends, so the images it pulled and the packages it downloaded go with it. Keeping them between jobs is storage you design and provision yourself.
What it costs in work
ARC is free software, and GitHub bills nothing for self-hosted runner minutes. The cost is the cluster's nodes every month, and these hours:
- Upgrades are reinstalls. Helm can't upgrade ARC's custom resource definitions. GitHub's upgrade steps: uninstall every runner scale set, wait for the cleanup, uninstall ARC, remove the CRDs if they changed, install again. Without a second cluster, no runner takes jobs while you do it.
- The runner goes stale. GitHub stops assigning jobs to a runner that is more than 63 days behind a new version. With your own image, rebuilding it in time is your job.
- The cluster is yours to debug. GitHub's support scope for ARC leaves out Kubernetes setup and networking, building images with Docker-in-Docker, storage and persistent volumes, cluster policies and image caching. It recommends "staff with expert-level knowledge of container orchestration".
- Kubernetes itself. Node upgrades, autoscaling the nodes under the runners, and the bill for nodes that sit idle between pushes.
A small team has no platform engineer to spend on this. The hours come out of product work.
What GitHub's runners cost if you stay
The reason teams look at ARC is the per-minute bill. Here is that bill against one Skipbox plan:
| Minutes a month (4 vCPU) | GitHub | Skipbox S | You save every month |
|---|---|---|---|
| 10,000 | $102 | $39 | $63 |
| 20,000 | $222 | $39 | $183 |
| 30,000 | $342 | $39 | $303 |
| Always on | $500.40 | $39 | $461.40 |
GitHub's figures are the bill on GitHub Team after its included compute. Price your own minutes in the calculator on the home page; no sign-in.
Skipbox: the runners, without the cluster
| ARC | Skipbox | |
|---|---|---|
| To start | A cluster, Helm, two charts, a secret, an image | Install a GitHub app, change runs-on |
| GitHub's bill for the minutes | None | None: Skipbox's runners are self-hosted runners |
| Monthly cost | The cluster's nodes, by size and hours | $39, $79 or $149, flat |
| Docker in jobs | Privileged Docker-in-Docker, or Kubernetes mode | Docker runs in the VM, as on ubuntu-latest |
| Caches between jobs | Gone with the pod, unless you build storage for them | Stay on your machine's disk |
| Upgrades | Uninstall and reinstall | Done for you |
| When a runner breaks | You read the controller's and listener's logs | Checked after every job; a machine that fails is rebuilt automatically |
- A flat price. 4 vCPU and 16 GB for $39 a month, 8 vCPU for $79, 16 vCPU for $149. Unlimited minutes, no usage charges. Add plans to run more jobs at once; jobs beyond your machines wait their turn.
- Your own warm machine. Docker images, layers and build cache, package caches and the tool cache stay between jobs: at least 7× the cache GitHub gives a repository. A runner pod that starts empty downloads all of it again.
- A runner for each job. Skipbox registers a just-in-time runner for one job when the job is queued, and removes it afterwards. No listener, no scale set, no
maxRunners. - Kept current. The runner, Ubuntu 24.04, Docker, Node 22 and Python 3.12 are Skipbox's to update.
Moving is one line
jobs:
build:
runs-on: skipbox # was ubuntu-latest, or your scale set's name
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test- Sign in to Skipbox with GitHub.
- Install the Skipbox GitHub app and pick your repositories.
- Change
runs-onand push.
Linux jobs run unchanged, on public and private repositories.
Security
- The machine is your account's alone; no other company's job runs on it.
- After every job, the runner's credentials, processes, containers and credential files such as
~/.npmrcare wiped. From 13 November 2026, your checkout and its build output (Cargo'starget/) stay on your own machine for your next jobs; Clean every job gives each job a fresh machine. - Code from people without write access (such as pull requests from forks) runs on a fresh VM, deleted afterwards. How jobs are kept apart.
Try it before you build a cluster
The trial takes no card and runs for 7 days or 3,000 job-minutes. Move one job to runs-on: skipbox today, before you build a cluster for it.
FAQ
Actions Runner Controller vs a managed runner service: which for a small team?
A managed runner service. Actions Runner Controller (ARC) is a Kubernetes operator: you run the cluster, install its two Helm charts, build the runner image and reinstall it for every upgrade. GitHub recommends it for organizations with Kubernetes infrastructure and teams that have Kubernetes expertise. Skipbox gives a small team the same free self-hosted minutes with nothing to operate: a flat $39 a month for a 4 vCPU machine, unlimited minutes, one runs-on line.
Is Actions Runner Controller hard to run for a small team?
It is a Kubernetes platform to keep running. You need a cluster, Helm, a GitHub App or token stored as a Kubernetes secret, a container mode for jobs that use Docker, your own runner image for the tools your jobs expect, and log collection for the controller, listeners and runners. GitHub's docs recommend staff with expert-level knowledge of container orchestration. On Skipbox none of that exists: you install a GitHub app and change runs-on.
What does Actions Runner Controller cost?
ARC itself is free, and GitHub bills nothing for self-hosted runner minutes. You pay for the Kubernetes cluster and its nodes every month, and for the hours spent installing, upgrading and debugging it. Skipbox puts the machine and the work in one flat price: $39, $79 or $149 a month for 4, 8 or 16 vCPU, with unlimited minutes.
How do you upgrade Actions Runner Controller?
By reinstalling it. Helm can't upgrade ARC's custom resource definitions, so GitHub's steps are: uninstall every runner scale set, wait for the cleanup, uninstall ARC, remove its CRDs if they changed, and install again. The runner inside your image also has to stay current: GitHub stops assigning jobs to a runner more than 63 days behind a new version. On Skipbox the runner and the image are updated for you.
Do I need Kubernetes to autoscale GitHub Actions runners?
No. ARC is GitHub's Kubernetes answer, and GitHub's docs also describe building your own autoscaler from its scale set client or from webhooks. A managed runner needs none of them. Skipbox registers a runner for each job as it is queued; your plans set how many jobs run at once, and the rest wait their turn.
Do Docker builds work without Docker-in-Docker on Skipbox?
Yes. Each Skipbox machine is a VM with Docker installed, so docker build, docker run, service containers and container jobs work as they do on ubuntu-latest. On ARC you choose a container mode first: Docker-in-Docker, which runs a privileged container, or Kubernetes mode, where a job without a container fails by default.
Updated November 14, 2026