Self-Hosted CI Runners: Cost Math vs GitHub Hosted
Self-hosted runners cut CI costs 50-80% — when used at the right scale. The decision math and the operational realities.
GitHub Actions, GitLab CI, CircleCI, and the various hosted CI platforms charge premium prices for compute. Substantial CI workloads cost organizations $100K-$10M+ annually on hosted runners. Self-hosted runners cut that 50-80% — when used at the right scale, with the right operational discipline. This post walks through the cost math and the operational realities.
The cost math#
The arithmetic is straightforward at substantial scale.
GitHub Actions hosted large runners cost $0.008-$0.064 per minute depending on size. A workload using 100,000 minutes/month on 4-core runners costs $800/month.
Self-hosted on AWS equivalent compute (m5.xlarge spot at ~$0.07/hour): the same 100K minutes is ~1,667 hours = ~$117/month for compute. Plus operational overhead.
The compute is substantially cheaper; the question is whether operational overhead justifies the savings.
At 100K minutes/month, the savings of ~$700/month barely justify operational effort. At 10M minutes/month, the savings of ~$70K/month substantially justify it.
The rule of thumb: self-hosted starts being interesting around $5K-$10K/month of hosted CI spend, becomes compelling at $25K+, and is almost mandatory at $100K+.
The operational costs#
Self-hosted CI has substantial operational components:
Runner provisioning. Static fleet vs autoscaling. Autoscaling (which most production deployments use) requires substantial infrastructure work.
Runner update management. Runner agents need updates; the underlying OS and tooling need updates.
Capacity planning. Underprovision and CI queues; overprovision and waste money.
Network and IAM. Runners need access to private resources, secrets, plus the various.
Observability. Runner health, queue depth, job success rates.
Security hardening. Runners executing arbitrary code (untrusted PRs, fork PRs, plus the various) need substantial isolation.
The full operational burden, including engineer time, is often 0.2-0.5 FTE for substantial deployments. That’s $50K-$150K/year in labor.
The deployment patterns#
Several substantial patterns:
Static EC2 fleet. Fixed number of runners always on. Simplest; least cost-efficient. Workable at small scale.
Auto-scaling EC2 with custom code. EC2 instances spun up on demand. Substantial custom code.
Kubernetes-based with Actions Runner Controller (ARC). Substantial GitHub-promoted pattern for Kubernetes-anchored deployments. ARC handles runner provisioning, scaling, lifecycle.
Kubernetes-based with custom operator. Custom-built operator for organization-specific patterns.
Third-party platforms — RunsOn, Ubicloud, Depot, plus the various — handle the operational complexity at the cost of vendor lock.
Cloud-vendor offerings — GitHub-hosted larger runners on customer cloud (relatively new), GitLab dedicated runners, plus the various.
The security dimension#
Self-hosted runners executing untrusted code (open-source projects, fork PRs) is a substantial security concern.
Patterns:
- Isolated runners for fork PRs. Separate runner pool for untrusted code with substantially restricted permissions.
- Ephemeral runners. Each job runs on fresh instance; no state leaks.
- Network isolation. Runners can reach what they need; can’t reach what they don’t.
- No persistent secrets in runner images. Secrets fetched per-job from vault.
- Approval gates for first-time contributor PRs.
The security work is substantial; getting it wrong is costly.
When NOT to self-host#
Several scenarios favor hosted runners:
Small scale. Below $5K/month of hosted spend, operational overhead exceeds savings.
Spiky workloads. Burst capacity is expensive to self-host; hosted runners handle bursts naturally.
Specialized hardware needs. GitHub-hosted GPU runners, macOS runners, Windows runners — substantially easier than self-hosting equivalents.
Limited DevOps capacity. Teams without the operational capability shouldn’t take on the burden.
Compliance requirements that favor hosted in some scenarios — depends on specifics.
What we typically see at clients#
Common patterns:
Hosted runners as default. Most organizations start hosted, evaluate self-hosting when spend becomes substantial.
Partial self-hosting. Some organizations run their high-volume workloads self-hosted; specialty workloads (macOS, GPU, Windows) on hosted.
Self-hosted on Kubernetes with ARC. Increasingly common pattern at substantial scale.
Third-party platforms — Depot, RunsOn, Ubicloud, plus the various — when teams want self-hosted economics without operational burden.
The decision framework#
For most teams in 2026:
Stay on hosted if CI spend is below ~$5K/month. Operational overhead not justified.
Self-host via Kubernetes + ARC at $25K+/month and substantial Kubernetes capability.
Use third-party platforms as middle ground — better economics than pure hosted, less operational burden than self-hosted.
Hybrid for organizations with mixed needs — self-hosted for high-volume, hosted for specialty.
Where pdpspectra fits#
Our DevOps practice builds production CI/CD platforms with appropriate runner architecture.
Related reading: the GitOps multi-cluster post, the Karpenter vs Cluster Autoscaler post, and the cloud spend post.
Self-hosted CI is workable at substantial scale. Talk to our team about your CI/CD platform.