GitHub runners comparison

A runner is required to run workflows on GitHub Actions. There are three options available to customers: standard runners, larger hosted runners and self-hosted runners.

This page is intended to provide the comparison between these three options. The information on this page is current as of Feb 29, 2024

The original GitHub runners are hosted on Azure infrastructure and completely managed by GitHub. The larger hosted runners allow customers to have more powerful hardware and a static IP address. Self-hosted runners and installed on customer’s infrastructure and managed by the customer.

	Standard	Larger	Self-hosted
Specs	The specs are set by GitHub.	Can be customised. - 4-64 cores CPU - 16-256Gb RAM - 150-2040Gb HDD - Optional static IP address	The hardware is selected and provided by the customer Supported architectures: - x64 for Linux and Windows - ARM64 for Linux, macOS, Windows (currently in beta). - ARM32 for Linux
OS	Linux, Windows, macOS are available. The exact versions will change as new OS versions coming out. Check the Action runner images repo	← Same as with Standard runners	Linux, Windows and macOS are supported. The customer needs to provide the software. Refer to the docs for the full list
Software	Comes with common software (pip, npm, rubygems, etc). Refer to the Action runner images repo for the complete list of software included with each OS.	← Same as with Standard runners	Self hosted runner doesn’t come with preinstalled software. Customers will need to install the necessary tools themselves.
Where is it hosted	Linux and Windows runners are hosted in Azure. macOS runners are hosted in GitHub’s own macOS cloud.	← Same as with Standard runners	The customer decides where the runners are hosted. It can be at a cloud provider (AWS, Azure, GCP) or on customer’s server located on a customer’s network behind a firewall.
Networking	GitHub uses a wide IP address range for hosting the runners and it’s impossible to allocate a specific IP address to a runner. Note, If you use an IP address allow list for your GitHub organisation or enterprise account, you cannot use standard GitHub-hosted runners. Azure VNETs feature will allow GitHub hosted runners to access your resources on private network.	Larger runners use the same IP address range as standard runners, but customers have an option to obtain a static IP address for the runner which then can be used to create necessary rules in the firewall for runner to access resources on customer’s local network or to add them into IP allow list for your organisation.	Self hosted runner initiates the connection to GitHub during registration. As result, no rules have to be configured on the firewall for inbound connections. However, if there are restriction on outgoing traffic, there may be a need to create outbound rules.
Pros	- Easy to start with - No maintenance needed, no upfront investment for the hardware - Covered by included free allowance - Available as needed	- No maintenance needed - No upfront investment for the hardware - Can get a static IP address and use it to create necessary firewall rules for runners to access internal infrastructure - Available as needed	- The customer decides what hardware to provide - As runners are usually hosted on local networks behind firewall, they have access to local resources and can deploy to local servers - Support is available for ARM hardware
Cons	- no GPU - no Apple silicon (Intel hardware only) - accessing resources on local network will require opening firewall to a large range of IP addresses which likely will be a security issue (this will change when Azure VNETs are implemented) - not an option if also using allow listing	- no GPU - no Apple silicon (Intel hardware only) - included action minutes allowance (50,000 for GitHub Enterprise) cannot be used for larger runners, customers will be charged as soon as they start the first runner.	while possible, autoscaling is not an out of the box option - hidden cost of hardware and maintenance

Other resources:

• Another comparison by @tsviz