GitHub-hosted versus self-hosted runners

README.md

Area \ Type	GitHub-hosted	Self-hosted
Docs	GitHub-hosted	self-hosted
High-level differences	Receive automatic updates for the operating system, preinstalled packages and tools, and the self-hosted runner application. Are managed and maintained by GitHub. Provide a clean instance for every job execution. Use free minutes on your GitHub plan, with per-minute rates applied after surpassing the free minutes.	Receive automatic updates for the self-hosted runner application only, though you may disable automatic updates of the runner. For more information about controlling runner software updates on self-hosted runners, see "Autoscaling with self-hosted runners." You are responsible for updating the operating system and all other software. Can use cloud services or local machines that you already pay for. Are customizable to your hardware, operating system, software, and security requirements. Don't need to have a clean instance for every job execution. Are free to use with GitHub Actions, but you are responsible for the cost of maintaining your runner machines.
OS support	ubuntu-22/20/18, macOS-12/11/10, windows-2022/2019	varies based on your expertise in building and packaging VMs or containers to support use cases, requires time and effort to maintain
Languages	22+	varies based on time and effort to provide variety of options and maintain
Package Managers	13+	varies based on time and effort to provide variety of options and maintain
Tools	60+ including automation, builders, transformers, cloud CLIs	varies based on time and effort to provide variety of options and maintain
Libraries	many	varies based on time and effort to provide variety of options and maintain
Instance Types	Standard: 2 vcpu / 7 GB RAM / 14 GB storage Larger: 4 vcpu / 16 GB RAM / 150 GB storage Larger: 8 vcpu / 32 GB RAM / 300 GB storage Larger: 16 vcpu / 64 GB RAM / 600 GB storage Larger: 32 vcpu / 128 GB RAM / 1200 GB storage Larger: 64 vcpu / 256 GB RAM / 2040 GB storage	varies based on underlying infrastructure and availability
Administrative overhead	Managing policies and runner groups Reviewing and optimizing spend Firewall / proxy access	Managing policies and runner groups Reviewing and optimizing spend Managing underlying infrastructure including access updates Managing self-hosted runner orchestration solution

I think the thing we don't capture well is just how many variations of runners are in use for a given customer and just how much is out dated and contain vulnerabilities. We also don't demonstrate the cost of ownership on administrators and users.

One thing I've learned here is that folks who have a community edition or code that is open to the public cannot really run self hosted runners due to security risk of untrusted code being run on company networks.

@rafskov : that is definitely one of the big call outs in https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security

We recommend that you only use self-hosted runners with private repositories. This is because forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.

Additionally, people should check out https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ for more information that led to the creation of pull_request_target event