3.2. Runners at Scale
💡 First Principle: A runner is where trust becomes physical — it's a real machine that will execute whatever your workflows tell it to, so choosing runner types and controlling access to them is simultaneously a capability decision, a cost decision, and the single largest security boundary in Actions.
Why care: runner strategy is the difference between a build fleet that scales elastically and bills predictably, and one that queues for hours or, worse, lets a fork's pull request execute code on a machine inside your corporate network. Every scenario question about "our builds are slow / expensive / can't reach the internal registry / were compromised" is a runner question in disguise.
⚠️ Common Misconception: "Self-hosted runners are the safer, more controlled option." For public repositories GitHub explicitly recommends against them: a fork's pull request can execute arbitrary code on your machine, and because self-hosted runners are persistent by default, that code can poison the environment for every subsequent job. Hosted ephemeral VMs are the safe default on public repos; self-hosted belongs behind private repositories and controlled access.
