Memory hook: A runner is a security boundary and an operating responsibility.
Must remember
GitHub-hosted runners provide managed job environments with published images/tooling. Self-hosted runners give control over hardware, installed software and network reachability, but the organization owns patching, isolation, cleanup and capacity. A machine inside a private network can expose that network to whatever code it executes.
runs-on labels select eligible runners; runner groups restrict repository/workflow access. Labels describe matching capability, not a security permission by themselves. Check group policy, runner online status, labels and capacity when jobs queue. Separate trust levels and avoid executing untrusted public contributions on persistent privileged infrastructure.
Prefer ephemeral, isolated execution where suitable. Remove job residue, restrict outbound/internal access and avoid credentials on the host that exceed the job's need. Containerized steps do not automatically make a compromised persistent host safe. Keep the runner application and system dependencies supported.
Hosted image release notes and tool caches show available software. Use setup actions or controlled installation for required versions, with caches/images where appropriate. A latest image label is a moving target. Network access, proxies, IP allow lists and registry/package endpoints must support the actual job path.
Scale from queue depth, concurrency and job duration, while considering startup delay and cost. Larger runners can shorten some jobs but do not fix serialized workflows or slow external services. Autoscaling should remove unused capacity safely after work completes. Audit which repositories can reach sensitive runner groups and review changes to those permissions.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Need private network access and specialized hardware | A carefully isolated self-hosted or suitable managed runner design. |
| Restrict production-capable runners | Runner group policy plus scoped workflow access. |
| Job queues despite an online runner | Check labels, group access, capacity and platform requirements. |
Traps
- A label is not an authorization boundary.
- A self-hosted runner can retain hostile state between jobs.
Active recall
1. Who patches a self-hosted runner?
The organization operating it, including host and runner software responsibilities.
2. Why prefer ephemeral execution?
To reduce cross-job residue and persistence risk.
3. Why inspect image versions?
Tool availability and behavior can change between image releases.
4. What should drive scaling?
Measured queue time, workload demand, startup overhead and cost.
5. Why separate trust levels?
Untrusted code must not inherit production network access or credentials.