← Home

Free tools

Your CI Is Free. Unless You Picked the macOS Runner.

Same builds, same minutes, same everything — but the runner you picked changes the bill by a factor of ten. And two settings take it to zero.

Most teams paying for CI do not have a volume problem. They have a configuration problem, and it is two checkboxes deep.

The two settings that take the bill to zero

GitHub’s own billing documentation is unambiguous about this: usage is free for self-hosted runners and for public repositories using standard GitHub-hosted runners. Not discounted, not a bigger allowance — not metered.

That is the entire answer for a large fraction of the projects that are currently paying. If your repository is public, you are not being billed for standard runners no matter how many minutes you burn. If you run the workflow on a machine you own, the same applies.

So the interesting question is only about the case that is left: a private repository on GitHub-hosted runners.

There, the runner choice is a 10× decision

Per-minute rates, from GitHub’s documentation:

macOS is more than ten times the price of Linux. This is not GitHub being difficult — Apple’s licence terms require macOS builds to run on Apple hardware, so no provider can pack them onto commodity servers the way they do with Linux. Every CI vendor prices it the same way.

What makes it expensive in practice is that nobody looks. runs-on: macos-latest gets copied from an example, the pipeline works, and the line item never gets questioned.

Put your own numbers in

Try 20 builds a day at 8 minutes each — a fairly ordinary team. That is 3,520 minutes a month across 22 working days. On the Free plan your 2,000 included minutes run out on the twelfth working day, and the remainder costs:

Identical work. Identical minutes. The only thing that changed was one line of YAML.

Then tick “public repository” or “self-hosted runner” and watch all three go to zero.

The honest caveats

Self-hosted is not actually free, it is unbilled. You pay in hardware, in maintenance, and in security review — a self-hosted runner executes whatever a workflow tells it to, which on a public repository means anyone opening a pull request can run code on your machine. GitHub says as much in their own docs, and it is the reason self-hosted runners are a bad default for public projects specifically.

These prices will change. The rates above were checked against GitHub’s billing documentation on 6 August 2026. That is why the calculator lets you edit them rather than baking them in: a tool with hardcoded prices starts lying the day the price list moves, and it keeps looking authoritative while it does.

What to actually do

1. Check whether you need to pay at all. Public repository, or a runner you own — either one and the meter stops. Most of the “how do I reduce CI costs” threads are answered by this and never get there.
2. Look at what runs-on says before you look at anything else. Moving jobs that do not need macOS off macOS is the single largest lever, by an order of magnitude, and it is one line.
3. Only then optimise minutes — caching, matrix pruning, skipping unchanged paths. Shaving 20% off your build time is worth much less than not running it on the expensive machine.