Self-Hosted GitHub Runners on Azure: The ROI Calculation

Self-hosted GitHub Actions runners on Azure sit in the uncomfortable middle: cheap enough that teams keep reaching for them, complex enough that they regularly become an operational tax. The decision is not "is this cheaper?". The decision is whether the cost saved beats the engineering time spent keeping runners healthy, secure, and private-network-connected. Here is the honest ROI model.

The Cost Model, Without Hand-Waving

GitHub-hosted Linux runners bill per minute with a free tier on public repos and per-minute pricing for private. Self-hosted runners on Azure bill by VM-hour (or equivalent compute), regardless of whether a job is running. The break-even point is where the fixed Azure cost equals the variable GitHub bill:

Two-core Linux runner. GitHub-hosted at roughly $0.008/minute equates to ~$0.48/hour. An Azure B2ms at ~$0.08/hour breaks even at ~10% utilisation. Self-hosted wins any time your runners are busy more than 10% of the hour. For active engineering orgs, that is always.
Larger runners (8+ cores). The hosted pricing scales up faster than Azure VM pricing. Break-even drops further in favour of self-hosted.
Windows and macOS. Windows breaks even slightly later than Linux; macOS self-hosting is a specialist effort and usually not worth it below large scale.

When Self-Hosted Wins

Private-network access required. Workflows that need to reach an Azure SQL behind private endpoints, an internal artifact feed, or an ExpressRoute-only service cannot use GitHub-hosted runners without complex VPN workarounds. Self-hosting inside the VNet is the clean answer.
Custom hardware or large caches. GPU runners, persistent dependency caches, or workflows that benefit from large ephemeral disks justify self-hosting.
Consistent heavy utilisation. Teams running full test suites continuously through the day get the biggest break-even advantage.
Compliance boundaries. Workloads whose source, artifacts, or secrets must not leave a specific cloud tenancy for regulatory reasons.

When Self-Hosted Is a Trap

Small teams with bursty usage. Minutes saved rarely repay the weekly maintenance cost.
Public repositories. GitHub docs explicitly warn against self-hosted runners on public repos. A malicious pull request can run arbitrary code on your infrastructure.
Teams without platform capacity. A self-hosted runner is a piece of infrastructure. Without someone accountable for its health, the first outage costs more than a year of hosted runners.

The Production Architecture: Ephemeral Runners on a Scaleset

A persistent runner is a security liability. State leaks between jobs, and a compromise from one workflow persists to the next. The correct architecture is ephemeral: one VM per job, destroyed after the job completes. Azure Virtual Machine Scale Sets integrated with GitHub's runner scaleset controller is the current standard.

# Bicep — ephemeral runner scaleset, stripped to essentials
resource runnerVmss 'Microsoft.Compute/virtualMachineScaleSets@2024-07-01' = {
  name: 'gh-runners-linux'
  location: location
  sku: { name: 'Standard_B2ms', capacity: 0 }      // scale from zero
  properties: {
    overprovision: false
    upgradePolicy: { mode: 'Manual' }
    virtualMachineProfile: {
      storageProfile: {
        imageReference: { publisher: 'Canonical', offer: 'ubuntu-24_04-lts', sku: 'server', version: 'latest' }
        osDisk: { createOption: 'FromImage', caching: 'ReadOnly', diffDiskSettings: { option: 'Local' } }
      }
      networkProfile: { networkInterfaceConfigurations: [ /* VNet integration */ ] }
      // cloud-init registers the runner, runs one job, deregisters
    }
  }
}

Security Hygiene

Ephemeral, always. Never re-use a runner VM across jobs.
Managed Identity, not stored secrets. The runner VM's identity should grant access to only the resources needed for that workflow.
Separate runner pools per trust level. Production deploy runners do not run PRs from unvetted forks.
Egress firewall. Allowlist the handful of endpoints runners need (GitHub, your artifact registry, your deploy targets). Block everything else.
Centralised logging. Every runner should stream job logs and system events to Log Analytics before self-destructing.

Autoscaling: Scale to Zero, Scale to Burst

The scaleset controller watches GitHub's queue depth and adjusts the VMSS capacity. Scale to zero during off-hours (Swedish engineering calendars leave runners idle overnight and on weekends), and scale to a high ceiling during working hours. The typical production config holds a minimum of one warm runner during business hours and scales to fifty during peak CI load.

Conclusion

Self-hosted runners on Azure are a clear win for teams with private-network workflows, heavy and consistent utilisation, or compliance constraints. They are a trap for teams hoping to save money on CI without owning the operational work. The right question is not "what does it cost in dollars?". It is "who on the team owns this infrastructure, and have we staffed the role?"