What's changed: New GH-200 Chapter 4 (governance = use policies disable/all/GitHub/verified/allow-list, require SHA pinning, reusable-component access settings, fork-PR approval, cascade; runners at scale = GitHub-hosted/self-hosted, runner groups, IP allow lists, preinstalled/toolcache/setup-*, troubleshooting; encrypted secrets & variables = org/repo/environment scope and precedence, secrets/vars, masking, REST API management)
4.2Managing Runners at Scale
Understand GitHub-hosted vs self-hosted runners and when to use each, runner groups for access control, IP allow lists and networking, identifying preinstalled software/tool versions and installing more at runtime, and monitoring/troubleshooting runners.
Jobs run on runners. GH-200 tests correctly understanding GitHub-hosted runners vs self-hosted runners, choosing per requirement, and managing them safely in an org. GitHub-hosted runners are ephemeral VMs that GitHub provisions, updates, and tears down—clean per job. Self-hosted runners install the runner app on your own machine/cloud and register it, used when you need special hardware, internal-network access, or large caches.
| Aspect | GitHub-hosted | Self-hosted |
|---|---|---|
| Management | GitHub-managed, ephemeral | You build and maintain |
| Environment | Clean per job | State can persist |
| Best for | General CI, quick start | Special HW, internal net, big caches |
| Billing | Usage-based (free minutes) | Your own infra cost |
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.