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 |
4.2.1Runner groups and access control
Self-hosted runners are organized into runner groups to control "which orgs/repos may use them"—access control that, for example, restricts a sensitive production-deploy runner to specific repos. Runners usable by anyone can become a vector for a malicious PR to run code on a sensitive machine, so be careful using self-hosted runners on public repos (GitHub advises against it). Apply labels and target runners via runs-on:, routing to the right group.
4.2.2IP allow lists and networking
Organizations can set an IP allow list to accept access only from approved IP ranges. With GitHub-hosted runners the source IPs vary, so when you need stable IPs use larger runners with static IP ranges or self-hosted runners inside your own network. Jobs that must reach internal resources (e.g., an on-prem DB) typically use self-hosted runners (or proper network setup) for reachability.
4.2.3Preinstalled software and runtime installs
GitHub-hosted runners come with many language runtimes, CLIs, and build tools preinstalled. Check actual versions in the runner image release notes or the toolcache. If a tool is missing or you need another version, install at runtime via setup-* actions (e.g., actions/setup-node), package managers, caching, or container images. For self-hosted runners you can also bake requirements into a custom image. Note that image updates like the Windows Server 2025 migration for windows-latest or the deprecation of ubuntu-20.04 can break builds.
4.2.4Monitoring and troubleshooting runners
Monitor self-hosted runners for online/offline status and for queued jobs that don’t start (no idle runner, label mismatch). Common causes: the runner app is stopped, labels don’t match runs-on:, network/auth issues, or low disk. Check the runner’s diagnostic logs and re-register if needed. With GitHub-hosted runners, queueing under load or concurrency limits can be the bottleneck.
Common: (1) GitHub-hosted = ephemeral, clean, quick; self-hosted = special HW / internal net / big caches (state can persist). (2) Govern self-hosted via runner groups; using them on public repos is risky. (3) Stable IP / internal access = larger runners’ static IPs or self-hosted, plus an IP allow list. (4) Check preinstalled versions in release notes/toolcache; install missing tools at runtime via setup-* actions. (5) Jobs not starting = suspect label mismatch / no idle runner.
Watch out: (1) Self-hosted runners retain state, so jobs can be contaminated—use GitHub-hosted or ephemeral setups when cleanliness matters. (2) Self-hosted runners on public repos risk a malicious PR executing code on your machine. (3) If runs-on: labels don’t match the runner’s labels, jobs stay queued. (4) GitHub-hosted source IPs vary—designs assuming fixed IPs break.
4.2.5Section summary
- GitHub-hosted = ephemeral/clean/quick; self-hosted = special HW/internal net/big caches (state can persist)
- Govern self-hosted via runner groups; risky on public repos; restrict source via IP allow list
- Check preinstalled versions in release notes/toolcache; install missing via setup-* actions at runtime
- For stuck jobs, diagnose label mismatch/no idle runner/stopped runner; mind breakage from image updates
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. A job must reach an on-prem database and also keep special build tools resident. Which runner fits?
Q2. You want only a limited set of repos to use a self-hosted runner for production deploys. What do you use?
Q3. You’re unsure if a GitHub-hosted runner has the needed Node version and want a specific version if not. What is best?
Q4. Jobs sent to a self-hosted runner stay queued and don’t start. What should you suspect first?
Q5. Why is using self-hosted runners on public repositories generally discouraged?
Q6. Your org security requires limiting connections to GitHub to specific IP ranges only. Which feature do you use?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.