What Are the Best Self-Hosted CI Runners for GitHub Actions?

GitHub Actions runners can be self-hosted in several ways. GitHub's runner application fits a few machines you manage. Actions Runner Controller (ARC) fits teams that run their own Kubernetes. RunsOn fits teams on AWS that want to run the runner stack themselves. Managed self-hosting, such as WarpBuild BYOC, fits teams that want runners in their own AWS, GCP or Azure account without running the fleet.

What are the main ways to self-host GitHub Actions runners?Copy Anchor Link

The main options are GitHub's self-hosted runner application, Actions Runner Controller (ARC), RunsOn, and managed self-hosting (BYOC). They differ in who operates the machines. In each one, the runners are machines you own or rent, and GitHub Actions sends jobs to them through the runs-on label.

1. GitHub's self-hosted runner application. You install the runner application on a machine and register it with a repository, organization or enterprise. Your team keeps the machine, its operating system and its tools up to date (GitHub docs on self-hosted runners).
2. Actions Runner Controller (ARC). ARC is a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions (GitHub docs on ARC). Your team runs the cluster, the controller and the runner container images.
3. RunsOn. RunsOn runs self-hosted runners in your own AWS account. Your team deploys it as a CloudFormation stack, and its control plane also runs in your account. Each job gets a new EC2 instance that is destroyed when the job ends (RunsOn).
4. Managed self-hosting (BYOC). BYOC means "bring your own cloud". It counts as self-hosting because the runner machines are in your own cloud account. In WarpBuild BYOC, the machines are operated for you. When GitHub requests a runner, WarpBuild boots a standby disk or creates a new VM in your account for the job (standby disks docs). On AWS, each job runs on a new instance that is terminated after the job (AWS security docs).

For the basic difference between GitHub's own runners and runners you host, see GitHub-Hosted vs Self-Hosted Runners.

How do the self-hosting options compare?Copy Anchor Link

The table below compares the options, and the WarpBuild feature matrix lists BYOC features in more detail.

Which self-hosting option fits which team?Copy Anchor Link

Pick the option by how much of the fleet your team wants to run. Each one works with the same GitHub Actions workflows.

• GitHub's runner application fits a small number of fixed machines, special hardware, or Macs you already own. Your team handles upgrades, cleanup between jobs and capacity.
• ARC fits teams that already run Kubernetes and have people to own the controller, the runner images and cluster scaling. WarpBuild vs Actions Runner Controller (ARC) compares the two in detail, and Actions Runner Controller (ARC) Alternatives lists other options.
• RunsOn fits teams on AWS that want to deploy and run the runner stack in their own account without Kubernetes, and need Linux or Windows runners.
• WarpBuild BYOC fits teams that must keep runners and caches in their own cloud account, want to use cloud discounts they already have, or want runners inside a VPC in their own account, but do not want to run the fleet themselves. Choosing Between Hosted and BYOC Runners covers when BYOC is worth it compared with hosted runners.

If you need macOS runners, BYOC does not cover them. Use WarpBuild Cloud macOS runners (cloud runners docs) or GitHub's runner application on your own Macs.

What does WarpBuild BYOC set up in my cloud account?Copy Anchor Link

WarpBuild BYOC sets up a stack in one region of your cloud account. A stack is a group of resources such as a VPC, subnets and an object storage bucket (BYOC docs). The bucket stores the cache, container image layer cache, logs and other workflow artifacts.

Setup has three steps:

1. Connect your cloud account. This creates an IAM role or service account with the permissions WarpBuild needs.
2. Create a WarpBuild stack. Choose the cloud account and region, and create a new VPC or, on AWS, use an existing one.
3. Create a custom runner. Choose the instance types, disk and IP settings, then use its warp-custom- label in runs-on.

Static IPs need extra care. Turning them on puts the runners in private subnets behind a NAT gateway, which can add outbound data transfer costs, NAT gateway data processing fees, and data transfer costs between the private subnets and the NAT gateway. Use static IPs only where you need them. Without static IPs, runners start in public subnets and avoid NAT gateway costs (BYOC docs).

For an AWS walkthrough, see BYOC Runners on AWS for GitHub Actions. For the term itself, see BYOC (Bring Your Own Cloud).

Is WarpBuild BYOC secure enough for a security review?Copy Anchor Link

WarpBuild is SOC 2 Type 2 certified (Security, Availability, Confidentiality). See the trust center. On BYOC in AWS, each job runs on a new EC2 instance that is terminated after the job completes, so no state is shared between jobs (AWS security docs). The runners, cache and logs stay in your own cloud account.