A curated list of awesome self-hosted GitHub Action runner solutions in a large comparison matrix
The purpose of this repository is to provide an overview on self-hosted runner solutions for GitHub Actions compared by various criteria. There is no rating implied as the importance of the various categories differ from use case to use case. Data can be out of date, so if a certain feature is told to be missing, please double check whether this is still the case.
During my research, I stumbled over dduzgun-security/github-self-hosted-runners with ✨ tips ✨ on what to consider when using self-hosted runners by yourself.
The virtual environments provided by GitHub Action managed runners like ubuntu-latest contain a LOT of pre-installed tools already. If all of those tools were installed in your self-hosted runner, this would result in images > 18 GB. In many cases where you have a better picture for which purposes/platforms you will use your self-hosted runners, this is probably not what you want for performance and maintenance reasons. All of the self-hosted solutions compared allow to define custom images with custom tooling.
If you like to test your custom images with your Actions workflows locally before you expose them to your end users at large scale, you can use nektos/act to specify your own Docker image for a specific runner label using the -P option, see a more complex example here.
The matrix (might be better readable on GitHub pages)
| Solution name | Runtime | GHES | RegScope | Scaling | AutoScaling | Architecture | AutoDereg | PATInRunner | CleanUp | Privileged | Exposed | AllInOne | SelfService | IdleCosts |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
actions/actions-runner-controller      |
k8s | ✅ | Enterprise, Org, Repo, Labels, RunnerGroups | k8s manifests & dynamic scaling | ✅ (pending + running jobs or percentage runners already busy, check run events, scale up/down and flapping prevention parameters) | x86, AMD64, ARM, ARM64 | ✅ | no | yes (if ephemeral option is used) | yes (install time, optional DinD) | only if github-webhook autoscaler is used | no | yes (IssueOps project available) | actions-runner controller + at least one pod per org runner |
philips-labs/terraform-aws-github-runner      |
AWS EC2/Lambda for Linux and Windows VMs | ✅ | Org, Repo, Labels, RunnerGroups | Terraform config & dynamic scaling | ✅ (pending jobs in org/repo, scale up/down and flapping prevention parameters) | x86, AMD64, ARM, ARM64 | ✅ | no | yes (if ephemeral option is used) | no | yes (GitHub check_run events) | yes (at least intended this way) | yes (IssueOps project available) | no (only Lambdas, KMS, queue service, API gateway) |
myoung34/docker-github-actions-runner      |
Docker | ✅ | Org, Repo, Labels, RunnerGroups | docker-compose, Nomad & k8s examples | ❌ | x86, ARM64, ARM | ✅ | yes | no | yes (DinD) | no | no | no | no |
evryfs/github-actions-runner-operator      |
k8s | ✅ | Organization, Repo | yes (k8s manifests define max and min) | ✅ scales up to min runners ASAP, then adds one runner at a time up to max if all current runners are busy, scales down idle runners up to min | x86 | ✅ | no | yes (ephemeral from v0.10.0) | yes (install time, optional DinD) | no | no | no | actions-runner controller |
MonolithProjects/ansible-github_actions_runner      |
bare metal/VM | ✅ | Organization, Repo, Labels | based on Ansible playbook | ❌ | x86, AMD64, ARM, ARM64 | explicitly in playbook | no | no | install Ansible agents | Ansible agents | possible | no | Ansible agents |
SanderKnape/github-runner      |
Docker | ❌ | Org, Repo, Labels | k8s manifest example | ❌ | x86 | ✅ | yes | no | no | no | no | no | no |
machulav/ec2-github-runner      |
AWS EC2 | ❌ | Repo | GitHub Actions workflow params | ✅ (1 runner per workflow run that requests it) | x86 | part of Actions workflow | no | yes (ephemeral) | no | embedded in GitHub Action workflow | possible | yes (Actions Workflow) | no |
terraform-google-modules/terraform-google-github-actions-runners      |
k8s (GKE), Docker, VMs (GCE) | ❌ | Repo | Terraform config/k8s manifests | only on k8s, based on generic pod CPU consumption (HPA metric) | x86 | only worked for Docker | yes | no | no | no | VMs could be configured like this | no | at least one idle runner to allow HPA to kick in based on CPU consumption |
github-developer/self-hosted-runners-anthos      |
k8s (Anthos GKE) | ❌ | Repo | Terraform config/k8s manifests | only on k8s, based on generic pod CPU consumption (HPA metric) | x86 | ✅ | yes | no | yes, for DinD (can be turned off) | no | no | no | at least one idle runner to allow HPA to kick in based on CPU consumption |
cosmoconsult/github-runner-windows      |
Windows Docker container | ❌ | Org, Repo | docker compose example in blog post | ❌ | win-x86 | replace but not remove | yes | no | no | no | no | no | no |
aslafy-z/github-runner      |
(fat) Docker, AWS EC2 | ❌ | Repo, Labels | k8s & Nomad examples | ❌ | x86 | ❌ | yes | no | optional to run DinD | no | yes (50G+ image with all tools) | no | no |
redhat-actions/self-hosted-runner-installer      |
Kubernetes (OpenShift) | ✅ | Org, Repo, Labels | HELM chart parameters | ❌ | x86 | ✅ | yes | no | no | no | no | no | no |
peter-murray/github-actions-runner-container      |
Docker | ❌ | Enterprise, Org, Repo, Labels, RunnerGroups | ❌ | ❌ | x86 | ✅ | yes | yes | no | no | no | no | no |
lts-beratung/ansible-github-action-runner      |
bare metal or VM | ❌ | Org, Repo | Ansible playbook | ❌ | x86 | ✅ | yes | no | install Ansible agents | Ansible agents | possible | no | Ansible agents |
rakheshster/github-runner-on-ubuntu      |
Azure VM (ARM template) | ❌ | Repo | ❌ | ❌ | x86 | ❌ | yes | no | no | no | possible | no | no |
ChristopherHX/github-act-runner      |
bare metal | ✅ | Enterprise, Org, Repo, Labels, RunnerGroups | ❌ | ❌ | x86, AMD64, ARM, ARM64, riscv64, s390x, ppc64, ppc64le, mips, mipsle, mips64, mips64le on Linux, Windows, macOS, Openbsd, Freebsd, Netbsd, Solaris, Dragonfly, Plan9, Android and Illumos | ❌ | no | yes | no | no | no | no | no |
related-sciences/gce-github-runner      |
GCP GCE | ❌ | Repo | GitHub Actions workflow params | ✅ (1 runner per workflow run that requests it) | x86 | part of Actions workflow | no | yes (ephemeral) | no | embedded in GitHub Action workflow | possible | yes (Actions Workflow) | no |
whywaita/myshoes      |
Virtual Machine: LXD, OpenStack, AWS, and more! (pluggable, can implement any platform) The already implemented provider is whywaita/myshoes-providers | ✅ | Repo, Org | GitHub Actions workflow params | ✅ (1 runner per workflow run that requests it) | any platform that can start bash script or transpiled script from a bash script | part of Actions workflow | no | yes (ephemeral) | no | yes (GitHub check_run events) | possible (provide image in some provider, e.g. whywaita/virtual-environments-lxd and shoes-lxd) | no | myshoes daemon process |
boozallen/goobernetes      |
k8s | ✅ | Enterprise, Org, Repo, Labels, RunnerGroups | k8s manifests & dynamic scaling | ✅ (pending + running jobs or percentage runners already busy, check run events, scale up/down and flapping prevention parameters) | AMD64, others possible | ✅ | no | yes (if ephemeral option is used) | yes (install time, optional DInD) | only if github-webhook autoscaler is used | no | yes (IssueOps project available) | actions-runner controller + at least one pod per org runner |
some-natalie/kubernoodles      |
k8s | ✅ | Enterprise, Org, Repo, Labels, RunnerGroups | k8s manifests & dynamic scaling | ✅ (pending + running jobs or percentage runners already busy, check run events, scale up/down and flapping prevention parameters) | AMD64, others possible | ✅ | no | yes (if ephemeral option is used) | yes (install time, optional DinD) | only if github-webhook autoscaler is used | no | yes (IssueOps project available) | actions-runner controller + at least one pod per org runner |
knatnetwork/github-runner      |
Docker for single machine quick start or K8s deployments for multiple replicas | ❌ | Org, Repo, Labels | docker-compose or k8s deployment | ❌ | AMD64, ARM64 | ✅ | no | yes (if ephemeral option is used) | yes (install time, optional DinD) | no | no | no | no |
CloudSnorkel/cdk-github-runners      |
Docker on AWS CodeBuild, Fargate or Lambda | ✅ | Labels | On-demand | ✅ | AMD64, ARM64 | ✅ | no | yes (always ephemeral) | yes | yes (Lambda URL with secret) | possible | no | no |
vbem/multi-runners      |
bare metal/VM | ✅ | Org, Repo, Labels, RunnerGroups | CLI control | ❌ | x86, AMD64, ARM, ARM64 | CLI control | yes | no | yes | no | possible | yes (CLI) | no |
runs-on/runs-on      |
AWS EC2 | ✅ | Repo, Dynamic Labels | On-demand | ✅ | x86, AMD64, ARM64 | ✅ | No PAT, only JIT token | Auto-cleanup | No runtime privilege | GitHub App exposed | AllInOne and custom images possible | yes (Actions Workflow) | $15/month |
Specifies whether the self-hosted runners are running on a container, Kubernetes cluster or virtual machine. Virtual machine based runners typically have some cloud specific dependencies.
While GitHub.com is supported by all self-hosted runner solutions evaluated, not all of them support GitHub Enterprise Server yet (although supporting GitHub Enterprise Server is often just a matter on changing the API endpoint).
Self-hosted runners can be registered on the repo, org and enterprise level and may register with custom labels inside runner groups - but not all runner solutions provide support for all those options.
Some self-hosted runner solutions have the ability to specify how many runners of a certain kind should be launched and whether crashed runners should be restarted.
Some self-hosted runner solutions have the ability to scale automatically with the amount of pending jobs, busy runners, CPU utilization, ...
While self-hosted action runners can support Linux (x86, ARM, ARM64), Mac and Windows - most self-hosted runner solutions are restricted to a subset of those architectures
Not all runner solutions remove themselves after they have been deleted, which can be problematic, especially, if combined aith auto-scaling capabilities.
Some runner solutions provide a personal access token (PAT) or OAuth token directly to the runner so that it can register itself. This imposes the risk of a malicious job trying to steal the token and use it to elevate its permissions. Solutions that only pass a runner token to the actual runners are preferred from a security perspective.
While self-hosted runner provide some isolation between jobs, it is the responsibility of the job to clean up in most cases. Some self-runner solutions automatically de-register and clean-up runners after every build to avoid any interference between jobs.
Calls out any special privileges (like Kubernetes cluster admin, Docker privileged mode) needed to run or install the solution.
Some centralized runner solutions rely on the ability to receive web hook events from GitHub about new jobs. This approach might not be feasible for some installations, although a reverse proxy may help.
GitHub's own, hosted runners have a lot of software already pre-installed. Most container based solutions follow a different philosophy where only a minimum amount of software is pre-installed.
While the number of contributors is not the only criteria, it is typically a good indicator for the maturity of a solution.
Some runner solutions have add-ons that allow end users to stand up new runner groups in a self-service fashion, e.g. via IssueOps.
Some solutions require certain central components to be up and running all the time or at least one idle runner to allow scaling up properly - this category provides an idea of what is needed in terms of components, not concrete $$$ costs.
If you like to test the auto-scaling capabilities of your awesome runners with Matrix inspired action build runs, including LED matrices and Raspberry PIs, check out this repo.
