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.

Additional security references for self-hosted runner deployments:

• GitHub Actions secure use reference - GitHub's guidance for hardening workflows, secrets, permissions, and self-hosted runner usage.
• Harden-Runner - Runtime security monitoring and egress control for GitHub Actions runners, including self-hosted runner deployments.

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
github-aws-runners/terraform-aws-github-runner	AWS EC2/Lambda for Linux, Windows and macOS VMs	✅	Org, Repo, Labels, Dynamic Labels, RunnerGroups	Terraform config & dynamic scaling	✅ (pending jobs in org/repo, scale up/down and flapping prevention parameters)	x86, AMD64, ARM, ARM64, macOS (EC2, requires a dedicated host)	✅	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
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)
sprinters-sh/sprinters	AWS EC2	❌	Repo, Dynamic Labels	On-demand	✅	AMD64, ARM64	✅	No PAT, only JIT token	Ephemeral instances with auto-cleanup	No privileges needed	Not exposed	Full and minimal images	Yes	$0
cisco-open/forge Multi-tenant wrapper around ARC & terraform-aws-github-runner, adding automation & extra features on top with a single interface to deploy & manage	k8s (ARC) & AWS EC2/Lambda for Linux and Windows VMs (terraform-aws-github-runner)	✅	Org (multiple GitHub Apps per org scoped to selected repos, or one App for all repos in the org), Dynamic Labels (EC2), RunnerGroups	k8s manifests (ARC) & Terraform config (terraform-aws-github-runner), dynamic scaling	✅ (ARC: pending + running jobs or percentage runners already busy, check run events, scale up/down and flapping prevention parameters; terraform-aws-github-runner: pending jobs in org/repo, scale up/down and flapping prevention parameters)	x86, AMD64, ARM, ARM64, macOS (EC2 lane, requires a dedicated host)	✅	no	yes (if ephemeral option is used)	yes for ARC (install time, optional DinD), no for terraform-aws-github-runner	only if github-webhook autoscaler is used (ARC), no for terraform-aws-github-runner	yes (merges ARC & terraform-aws-github-runner features)	yes (IssueOps project available)	EKS cluster + ARC controller + at least one pod per org runner (ARC); no, only Lambdas, KMS, queue service, API gateway (terraform-aws-github-runner)
Flinner/gh-runnerctl	bare metal/VM, local or over ssh — no root, no Docker (user-level systemd or detached supervisor; targets HPC login nodes and shared hosts)	❌	Org, Repo, Labels, RunnerGroups	declarative runners.toml (count per pool), converged by up/reload; crashed runners restarted with backoff	❌ (fixed-size pools by design)	x64, ARM64 (Linux)	busy-aware CLI/converge (up prunes, rm deregisters; skips busy runners unless --force)	no (token never leaves the control machine; remotes get short-lived registration tokens over ssh stdin)	no (persistent runners)	no (never root; no sudo at any step)	no	no	no	one user-level supervisor process per machine
Manzanita (managed service, not self-hosted)	managed macOS VM (Apple Silicon M4 Pro)	❌	Org, Repo, Labels (via GitHub App)	managed by provider (buy N concurrent runners)	managed (jobs dispatched to purchased concurrency)	macOS (Apple Silicon, M4 Pro)	✅ (ephemeral, one job per VM)	no (GitHub App)	yes (fresh VM per job)	n/a (fully managed)	no	yes (Xcode + toolchain preinstalled)	yes (dashboard + GitHub App)	none (flat monthly price, no infra to idle)
eyupio/zoomies	Docker, Podman, bare process; no Kubernetes required	configurable API endpoint; untested	Org, Repo, Labels	UI, CLI and YAML; per-pool limits across existing hosts	✅ (queued jobs via workflow_job webhooks; polling fallback; min/max runners)	Linux AMD64, ARM64; Windows AMD64 process agent builds, runtime unqualified; macOS controller for development	✅ (ephemeral registration and cleanup reconciliation)	no (GitHub App; single-use JIT config for ephemeral runners)	yes (ephemeral containers by default; process runners do not reset the host)	rootless Docker/Podman supported; optional DinD uses a privileged sidecar	controller webhook optional with polling fallback; agents connect outbound	no (customisable runner images)	yes (web UI and CLI for pools)	controller + existing agent hosts; zero idle runners possible, host costs remain
Gondola	AWS EC2 jobs; ECS Fargate controller	❌	Org, Repo, Labels, RunnerGroups (org)	Terraform/OpenTofu fleet definitions	✅ (assigned jobs; configured minimum and maximum runners)	Linux AMD64, ARM64	✅ (ephemeral registration)	No PAT; short-lived JIT runner configuration	One job per EC2 instance; instance and root-volume termination	AWS deployment permissions; Docker socket gives a job control of its host	No inbound GitHub webhook; outbound long polling	Lean/development image profiles; custom AMIs and runner containers	Fleet setup through Terraform/OpenTofu; workflows select approved labels	Controller tasks, coordination and network services; subscription for paid plans; zero idle EC2 runners possible
CRACI (managed service, not self-hosted)	managed Linux VMs, one isolated VM per job	❌	Org, Repo (via GitHub App, all or selected repositories)	managed by provider; runner size 1 to 32 vCPU per job	managed	Linux x86-64, ARM64	✅ (one VM per job)	no (GitHub App)	yes (VM discarded after the job)	n/a (fully managed)	no	yes (GitHub-compatible Ubuntu 24.04 image; Docker Engine, Buildx, Compose)	yes (dashboard + GitHub App)	monthly plan fee; build minutes billed per second

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.