awesome-runners 🏃

A curated list of awesome self-hosted GitHub Action runner solutions in a large comparison matrix

Purpose

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.

General collection of self-hosted runner best practices

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.

A word about self-hosted action runner images / virtual environments and how to test locally

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
cloudbase/garm	k8s,VM,Bare Metal (pluggable), available providers: k8s, EC2, OpenStack, OCI, GCP, LXD, Incus, Equinix Metal, Azure.	✅	Enterprise, Org, Repo, Labels, RunnerGroups	On-demand	✅ Scales based on workflow jobs, allows setting min/max runners per pool, scales up to “min” immediately, maintains “min” idle runners as long as “max” is not reached	x86, AMD64, ARM, ARM64	✅	no	yes (all runners are ephemeral and automatically disposed from the provider once removed from GitHub)	no (GARM can run as a non privileged user)	yes, required for github-webhook endpoint, needed for auto scaling	yes (if used as standalone, optionally it can be integrated in k8s using the garm-operator)	yes, GARM has pools which can be created in any number on any entity (org, repo, enterprise), with any runner group and with any labels	the cost of running a single container or VM with GARM, and any idle runners configured in the pools, cost depends on provider used (EC2, Azure, etc)
Privatehive/gcp-hosted-github-runner	GCP GCE	✅	Enterprise, Org, Repo, Labels, RunnerGroups	On-demand	✅ 1 runner per workflow job. Created when job is “queued”. Deleted when job is “completed”.	x86, AMD64, ARM64	✅	No PAT, only JIT token	yes (always ephemeral)	no	yes, required for github-webhook endpoint, needed for auto scaling	possible	no	no (covered by GCP free tier)

Comparison categories

Runtime - Container, Kubernetes, virtual machines

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.

GHES - GitHub Enterprise Server support

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).

RegScope - Registration Scope

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.

Scaling - Ability to specify multiple runner instances

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.

Scaling

Some self-hosted runner solutions have the ability to scale automatically with the amount of pending jobs, busy runners, CPU utilization, …

Architecture - Operating systems supported

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

Dereg - Automatic Runner Deregistration

Not all runner solutions remove themselves after they have been deleted, which can be problematic, especially, if combined aith auto-scaling capabilities.

PATInRunner - Personal access or OAuth token needed in runner

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.

CleanUp - Automated clean up after a build

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.

Privileged - Any special privileges needed to run or install the solution

Calls out any special privileges (like Kubernetes cluster admin, Docker privileged mode) needed to run or install the solution.

Exposed - Need for GitHub to reach parts of the runner solution via web hooks

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.

AllInOne - Software installed in the self-hosted runners

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.

Contributors - Number of contributors to the solution

While the number of contributors is not the only criteria, it is typically a good indicator for the maturity of a solution.

SelfService - Ability for end users to setup new runner scale sets

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.

IdleCosts - Costs that incur even if no jobs are running

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.

Matrix bonus

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.