Hosted runner minutes remain one of CI's largest line items for active organizations, and 2026 pushed more teams toward self-hosted runners for the heavy workloads. The economics are real, but so is the security surface: a runner is a machine that executes whatever a pull request tells it to.
When hosted runners are not enough
Self-hosted runners make sense for large build artifacts, specialized hardware like iOS build machines, air-gapped environments, or sustained volume where per-minute pricing becomes material. If none of those apply, managed runners are almost always cheaper once you count maintenance.
Treat runners as untrusted
Pipeline code executes arbitrary commands on the machine, so a runner that processes public fork requests is effectively public compute. Isolate runner pools per trust level, never mix sensitive and untrusted workloads, and rebuild images from known-good bases regularly.
Automate the fleet
Manual runner maintenance becomes an outage source. Build runner images as code, replace instances on a schedule, and monitor queue depth so capacity scales before builds back up.
The honest cost comparison
Self-hosted makes sense when workloads are constant and heavy: large builds, GPU jobs, long integration suites, or proprietary toolchains that hosted images cannot carry. It stops making sense when utilization is spiky or when engineering time spent on patching, scaling and image maintenance exceeds the minutes saved. A useful rule: calculate fully loaded cost per runner-hour including maintenance labor, not just hardware.
Securing the untrusted-execution problem
The core risk is running fork pull requests on machines with credentials or network reach to production. Mitigate with ephemeral runners that are destroyed after each job, no persistent secrets on disk, a hard boundary between trusted (same-repo) and untrusted (fork) workloads, restricted egress, and image pipelines that patch weekly. If a runner outlives a job, assume what ran in it persisted.
Key takeaways
- Compare fully loaded runner cost, including maintenance labor.
- Run fork PRs only on ephemeral, credential-free machines.
- Destroy runners after each job — persistence equals compromise.
Final thoughts
Self-hosted runners are a classic build-versus-buy decision with a security tax attached: the teams happy with them treat the runner fleet as production infrastructure with the same patching and ephemerality discipline.