What a self-hosted GitHub Actions runner really costs

When do self-hosted GitHub Actions runners make sense?

Self-hosted GitHub Actions runners make sense when you need private-network access, unusual hardware, a controlled image, or enough steady CI work to justify owning the fleet. GitHub charges no Actions minutes for them, but you pay for capacity, patching, isolation, monitoring and on-call time. In the illustrative model below, 12,000 job-minutes cost $474 self-hosted versus $54 on GitHub-hosted Linux runners. Figures checked September 21, 2026.

Last checked September 21, 2026: GitHub’s self-hosted runner documentation, hosted runner rates, security guidance, update policy and postponed platform charge were checked on that date.

GitHub's self-hosted runner overview says the service charges no Actions minutes for these jobs. You supply and maintain the machines. That makes GitHub Actions self-hosted pricing a total-cost question rather than a per-minute price: infrastructure plus the engineering time needed to run it safely and reliably.

This guide makes that total visible, separates self-managed and managed runners, and gives a sequence for testing the decision with your own workload. Every dollar result below is an example with replaceable assumptions, not a general estimate for your team.

What are the real costs of running your own runner?

1. The machine, billed whether or not a job is running

A runner is a server that sits there. You pay for it by the hour or month regardless of how many jobs arrive, so the useful figure is the machine price divided by the job-minutes it actually delivers. In this example, an always-on Linux server with 2 vCPU and 8 GB runs one job at a time. A 730-hour month contains 43,800 machine-minutes; maintenance, failures and idle time keep usable job-minutes below that ceiling.

2. Idle waste, which is most of what you buy

CI is bursty. Jobs cluster around pushes, and the queue you are trying to avoid forms at the peak. Sizing a fleet for that peak leaves paid capacity idle at quieter times. This model assumes 40% average utilisation; that is an input, not an industry benchmark. It produces 17,520 usable job-minutes per machine and 26,280 paid but unused machine-minutes each month.

Usage-priced hosted runners do not have that idle-capacity line. GitHub's runner pricing reference bills larger runners only while workflows execute. Sengi bills only the minutes your jobs run, with boot and teardown never billed. You never pay for idle capacity.

3. Ops time, which dominates at ordinary volumes

Somebody has to build the image, keep the runner application current, patch the operating system and tools, clean disks, drain and replace machines, preserve diagnostics, and respond when jobs stop being accepted. On June 12, 2026 GitHub published its minimum-version enforcement timeline: version 2.329.0 or later is required for registration, and runners must install later releases within 30 days to keep receiving jobs.

The runner application updates itself by default, but GitHub leaves the operating system and all other software to the operator. Price that work at your team's loaded hourly cost. The model below uses five hours a month at $90 an hour and states the result separately so you can replace both inputs.

4. Isolation and security, which is not a one-off

A standard GitHub-hosted job gets a fresh virtual machine. A persistent self-hosted runner does not provide that guarantee. GitHub's secure-use guidance warns against self-hosted runners for public repositories because pull-request code can compromise the environment, its secrets and its GITHUB_TOKEN. Private repositories still need a threat model for untrusted contributors and dependencies.

GitHub recommends ephemeral autoscaling and documents just-in-time runners that accept at most one job. Its self-hosted runner reference also requires operators to forward ephemeral-runner logs externally and warns that reusing the underlying hardware can expose earlier job data. Clean instances, restricted runner groups, network boundaries and teardown verification are recurring engineering work rather than initial setup.

5. The charge that was announced and postponed

On December 16, 2025 GitHub announced a $0.002-a-minute Actions cloud platform charge for self-hosted use in private repositories from March 1, 2026, then postponed that change before it took effect. The billing documentation checked September 21, 2026 still lists self-hosted usage as free, and GitHub has published no replacement date. Do not add the proposed rate to a current bill. The GitHub Actions pricing changes page preserves the timeline.

What assumptions does this comparison make?

Everything below follows from these. Three of them are assumptions about your team, not facts about anyone's product; change them and the arithmetic changes with them.

Is self-hosting cheaper than GitHub-hosted runners?

The self-hosted total is machines plus people: $24 per machine plus a flat $450. The GitHub-hosted column is the minutes above the 3,000 included, at $0.006. The Sengi column is the minutes above its 3,000 free minutes, at $0.003. Nothing else is in any column.

The shape is the point. At 12,000 minutes the assumed people time is 95% of the self-hosted total. At 200,000 minutes that fixed input is spread across far more work, so this particular self-hosted model costs less than GitHub-hosted execution.

Because machine count is rounded up, the crossing is stepped rather than smooth. Self-hosting first equals GitHub-hosted at 102,000 minutes, briefly dips below it, then needs another machine; it remains below GitHub-hosted above about 106,000 standard Linux minutes a month. Against Sengi at $0.003, self-hosting does not break even until about 289,000 minutes a month.

Had the postponed platform charge taken effect, it would have been added to the self-hosted column and to nothing else: $18.00 a month at 12,000 minutes, $94.00 at 50,000 and $394.00 at 200,000. It did not, and it is not charged today.

When is self-hosting the right answer anyway?

Cost is only one reason to own the runner. Self-hosting can be the right call when a job needs hardware a hosted service does not offer, when a named compliance control requires execution inside your network, when builds depend on a local artifact store or licence server, or when an existing platform team can operate the fleet at low marginal cost.

Sengi gives you what self-hosting promises without the rota: bare-metal desktop CPUs boosting past 5 GHz, a fresh VM for every job, cache included, and builds up to 1.9× faster than GitHub’s runner, for up to 74% less per build. See how it works and pricing, or how it compares with Blacksmith.

What should I measure before deciding?

Start with four measured inputs: monthly job-minutes from billing, peak concurrent jobs from the busiest windows, current engineering hours spent on CI infrastructure, and the rate for the runner you use. The GitHub Actions pricing guide lists current rates, and the cost calculator turns rounded job-minutes into a hosted baseline.

A bounded evaluation sequence

1. Separate queue time from execution time. More machines only address capacity queues. If jobs start promptly but run slowly, use the performance guide. If labels or capacity leave jobs waiting, use the stuck-job checklist.
2. Model the peak. Convert the busiest hour into required concurrent runners, then cost all hours those machines exist. Include headroom for replacement and maintenance.
3. Define the trust boundary. List which repositories and actors may dispatch work, which networks and credentials a job can reach, whether every job gets a clean instance, and where diagnostic logs survive teardown. GitHub runner groups can restrict repository access, but they do not clean a reused machine.
4. Choose an update and recovery owner. Record who rebuilds images within GitHub's 30-day runner-release window, rotates credentials, handles offline runners and restores capacity. GitHub's monitoring guide identifies runner status and diagnostic files to retain.
5. Pilot one low-risk workflow. Compare completed-job time, queue time, failure rate and operator time for a full maintenance cycle. Keep the old label available as the rollback, then decide with observed numbers.

If a network or compliance requirement is decisive, self-hosting earns its cost. If the goal is cheaper, faster Linux CI, a managed runner gets you there with a one-line change and no fleet to own.