Self-Hosted Runners for GHA

Self-hosted GHA runners. When and why.

When

GitHub Actions self-hosted runners is the discipline of running CI workloads on the team's own infrastructure rather than GitHub's. The choice is driven by cost, compliance, or specific build requirements; the trade-off is operational responsibility.

What when-to-use looks like:

• Cost: large monthly compute.: Teams with significant CI usage pay GitHub Actions per minute. Self-hosted runners on spot instances or owned hardware are dramatically cheaper at scale.
• Self-hosted on spot is cheaper.: The cost difference is significant. Spot-based self-hosted runners can produce 70-90% savings versus GitHub-hosted runners; the math justifies the operational investment.
• Compliance: builds touching internal data.: Some compliance regimes restrict where data can be processed. Self-hosted runners on team infrastructure keep the data within the team's compliance boundary.
• Specific hardware needs.: Some builds need specific hardware (GPUs, ARM, specific CPU). GitHub-hosted runners may not have what is needed; self-hosted provides specific hardware.
• Network access.: Self-hosted runners can access internal networks directly. Builds that need internal services do not require special tunneling; the access is native.

The when-to-use is specific. Most small teams should not self-host; large teams or specific needs justify it.

Setup

Setup options vary. Kubernetes-based (actions-runner-controller) is common; VM-based works too. The team picks based on their existing infrastructure.

• actions-runner-controller for K8s.: The Actions Runner Controller (ARC) runs runners as Kubernetes pods. The team's existing Kubernetes infrastructure hosts the runners; the operational story integrates.
• Or VM-based.: Beyond Kubernetes, runners can run on VMs. EC2 instances, GCP VMs, on-prem VMs all are options. The choice depends on the team's infrastructure.
• Auto-scales with job demand.: Both approaches support auto-scaling. Idle capacity is minimized; busy times scale up; the cost matches actual usage.
• Per-runner configuration.: Different runners can have different configurations. ARM runners for ARM builds; GPU runners for ML; standard runners for everything else. The team's CI matches their workload.
• Tagged runners.: Workflows specify which runner type they need via labels. The team's CI configuration is explicit; the right runners run the right jobs.

The setup is bounded effort. The discipline is choosing the right approach for the team's infrastructure.

Limits

Self-hosted has limits. The team operates the infrastructure; the cost includes engineering time; the discipline is real work.

• You operate them.: Self-hosted runners need operational care. Patches, OS updates, security maintenance all are the team's responsibility. The cost is real engineering time.
• Patches.: Security patches must be applied. Outdated runners are security risks; the team's discipline includes regular patching.
• Scaling.: The team operates the auto-scaling. Monitoring, capacity planning, scale-up policies all are operational concerns; the system is the team's responsibility.
• Debugging.: When runners misbehave, the team debugs. GitHub support cannot help; the team's expertise solves issues. The investment in expertise is part of the cost.
• Pay the cost in engineering time.: The cost savings from compute are partially offset by engineering time. The team's calculation must include both; the choice is informed.

Self-hosted runners is one of those CI/CD disciplines that pays off when the cost or compliance benefits justify the operational investment. Nova AI Ops integrates with CI/CD telemetry, surfaces runner patterns, and supports the team's CI infrastructure decisions.