Question
Assessing Cost Trade‑offs Between GitHub‑Hosted and Self‑Hosted Runners for Low‑Traffic Workflows
Rahul Maple
0 reputation · 18 Mar 2021, 23:45 UTC
30.4K views
Loading…
0 reputation · 18 Mar 2021, 23:45 UTC
A private repository with low traffic currently uses GitHub Actions. The free tier provides 2,000 minutes per month. Workflows occasionally exceed this limit, incurring per‑minute charges for GitHub‑hosted runners. An alternative is to deploy a self‑hosted runner, which avoids GitHub‑side billing but introduces hardware, power, bandwidth, and maintenance costs.
Which runner strategy yields the lowest total cost for a low‑traffic project that may occasionally surpass the free minute quota, considering both direct billing and indirect operational expenses?
35275 reputation · 19 Mar 2021, 00:44 UTC
For a private repo that stays within the 2,000‑minute free tier most of the time but sometimes exceeds it, the GitHub‑hosted Linux runner is cheaper unless your monthly usage regularly climbs above roughly 2,500 minutes. At that point the per‑minute charges ($0.008/min on Linux) start to outpace the indirect cost of a single low‑power self‑hosted machine (~$0.08–$0.12/min).
GitHub’s pricing is linear and billed per minute. The free 2,000 minutes cover modest traffic. When you exceed that, each extra minute on a Linux runner costs $0.008. A self‑hosted runner eliminates that charge but introduces recurring indirect costs: hardware depreciation, electricity, network, and maintenance. For a single low‑power device these add up to roughly $0.08–$0.12 per minute, which is an order of magnitude higher than the GitHub paid rate.
Because the indirect cost is fixed regardless of how many minutes you run, the only way a self‑hosted runner becomes cheaper is if you consistently run more than ~2,500 minutes per month. In that scenario the $4 paid cost on GitHub would exceed the ~$40–$60 self‑hosted overhead.
If GitHub reduces the free‑minute allotment or raises the per‑minute rates, the breakeven minute count will drop, making self‑hosting more attractive. Conversely, a bump in free minutes or a discount on paid minutes would widen the margin in favor of GitHub‑hosted runners.
Could you confirm the average monthly minutes your workflows currently consume? That will determine whether the 2,500‑minute breakeven applies to your case.
Use comments to ask for clarification. Post a solution as an answer.
6,550 reputation · 19 Mar 2021, 01:56 UTC
GitHub‑hosted runners charge only for the execution time of a job. A self‑hosted VM, however, incurs electricity and network costs even when it’s idle. If the runner is kept running 24/7, the monthly power bill can add a few dollars that aren’t reflected in the billed‑minute calculation. Shutting the VM down between jobs (or using a container‑based runner that spins up on demand) can reduce the indirect cost to a level comparable with the GitHub‑hosted per‑minute rate.
GitHub’s hosted runners typically run on recent Intel/AMD CPUs with higher clock speeds and more cores than a low‑power Raspberry Pi or a modest laptop. For a workflow that takes 30 minutes on a GitHub runner, the same job might run 40 minutes on a low‑power self‑hosted machine. The extra minutes increase the indirect cost and shift the break‑even point upward.
GitHub’s 2 000 free minutes apply to each repository individually, not to an organization as a whole. If you have multiple repos that occasionally exceed the quota, the cost adds up across them, whereas a single self‑hosted runner can serve all repos.
githubgithub.run_duration output in your workflow to capture actual run time.powerstat and bandwidth with iftop to estimate idle costs.