GitHub Actions is the default automation choice for millions of developers, and for personal projects it feels completely free. That is mostly true, but the free tier has limits that surprise people: monthly minute allowances, multipliers for different machine types, and storage caps. Understanding them now prevents a stalled pipeline later.

The headline number is the monthly minute allowance for private repositories. Public repositories are effectively unlimited, which is why open-source projects never worry about this. For private repos on a free plan, you get a set number of minutes each month, and the counter resets on your billing date, not the first of the month.

The multiplier is the detail most people miss. Minutes on a standard Linux runner count as one minute, but macOS runners cost ten times as much and Windows runners twice as much. A pipeline that runs happily on Linux can burn through a monthly allowance in days if it is moved to macOS runners without adjusting expectations.

Storage is the second limit. Build artifacts and caches share a storage allowance, and old artifacts do not delete themselves by default. A project that uploads large build outputs on every run can quietly fill its storage and start failing. Set short retention periods, a week or two for most artifacts, and let the platform clean up automatically.

Concurrency is the third limit, and it shows up as queued jobs rather than errors. Free plans allow a limited number of jobs to run at the same time. If you push several branches at once, later jobs wait in a queue. This is rarely a problem for solo developers, but teams notice it during busy release days.

The practical way to stay inside the limits is to make pipelines fast. Cache dependencies, run only the tests that matter on every push, and save the full test suite for merges to the main branch. Splitting a pipeline into a fast check on every push and a thorough check on merge can cut minute usage by more than half.

Also audit your workflows quarterly. Delete workflows for archived projects, remove scheduled jobs that no longer matter, and check the usage page for the workflows consuming the most minutes. One forgotten nightly job often accounts for more usage than all your real pipelines combined.

If you consistently exceed the free minute allowance, self-hosted runners are worth considering. You run the build agent on your own server, so you pay for the machine instead of per-minute, and the minutes no longer count against your allowance. For a team with a spare server or a cheap virtual machine, this can cut automation costs dramatically while giving you control over the build environment.

The trade-off is maintenance and security. You must keep the runner updated, secure it properly, and never run untrusted code on it, because a compromised runner can expose your repository secrets. For public repositories accepting outside contributions, self-hosted runners are risky and generally discouraged. For a private project with a trusted team, they are a practical way to escape minute limits without paying for a higher plan.

For most solo developers, the free tier is plenty — if you respect the multipliers and the storage cap. Know the numbers, keep pipelines lean, and GitHub Actions stays free for a very long time.

Check your Actions usage page today, even if nothing feels wrong. Knowing which workflows consume your minutes — and whether a forgotten scheduled job is eating them — takes two minutes and often reveals an easy saving. Small audits, done regularly, are what keep a free tier free.