The Short Version
GitHub overhauled Actions pricing at the start of 2026. Hosted runners got cheaper — up to 39% cheaper, depending on the machine. Then GitHub tried slapping a $0.002/min “cloud platform charge” on self-hosted runners too. The community revolted. GitHub reversed course within 24 hours.
If you’re running hosted runners on private repos, your bill probably went down. If you’re running self-hosted runners, nothing changed — for now. But the whole episode tells you something about where GitHub’s pricing is headed, and you should understand what happened so you’re not caught off guard next time.
What Changed on January 1, 2026
GitHub restructured how they price hosted runners. The headline number is “up to 39% reduction,” but the actual savings depend on what you’re running.
The new pricing works like this: GitHub cut the raw compute cost by roughly 40% across all runner sizes, then baked in a new $0.002/min “cloud platform charge” that covers the Actions control plane — job orchestration, scheduling, workflow automation. For hosted runners, that platform charge is already rolled into the per-minute rate, so you just see a lower number on your bill.
Here’s what the standard hosted runner rates look like now:
| Runner | Per-Minute Cost (2026) |
|---|---|
| Linux 2-core | $0.006 |
| Windows 2-core | $0.010 |
| macOS (M-series) | $0.062 |
The multiplier pattern hasn’t changed: Windows costs roughly 2x Linux, and macOS costs roughly 10x. If you’ve been running macOS workflows for iOS builds, you already know the pain. These cuts help, but macOS runners are still expensive enough that you should be strategic about when they run.
A few things that didn’t change: public repos still get free hosted runner minutes. The free tier quotas stayed the same — 2,000 minutes/month for Free plans, 3,000 for Pro, and 50,000 for Team. And the minute multipliers for Windows (2x) and macOS (10x) still apply against your free quota.
The Self-Hosted Runner Debacle
This is the interesting part. Buried in the same announcement as the hosted runner price cuts was a new charge: starting March 1, 2026, self-hosted runners would incur a $0.002/min “cloud platform charge” on private repos.
Think about what that means. Self-hosted runners run on your hardware. You already pay for the VMs, the electricity, the maintenance. The whole point of self-hosting is avoiding GitHub’s per-minute compute charges. Now GitHub was saying, “We still need to get paid for the orchestration layer.”
And honestly? The argument isn’t crazy. The Actions control plane does real work — parsing YAML, queuing jobs, distributing them to runners, collecting logs, managing secrets. That infrastructure costs GitHub money whether you use their compute or not.
But the execution was terrible. The announcement was buried alongside genuinely good news (the hosted runner price cuts), and for teams running thousands of minutes of self-hosted workloads on private repos, the math added up fast. A team burning 100,000 self-hosted minutes per month was looking at an extra $200/month. Not devastating, but a new cost for something that was previously free — and the principle of it stung.
The community response was immediate and loud. GitHub’s discussion thread filled with hundreds of comments within hours. The pushback wasn’t just about the dollar amount — it was about the precedent. Today it’s $0.002/min. What’s it next year?
GitHub reversed the decision within 24 hours. Their statement acknowledged they “missed the mark with this change by not including more of you in our planning.” The self-hosted runner charge was shelved indefinitely. No new timeline, no guarantee it’ll come back in its original form.
So Where Does That Leave You?
The situation as of April 2026:
- Hosted runners on private repos: Cheaper than before. You’re already saving money if you haven’t changed anything.
- Hosted runners on public repos: Still free. No change.
- Self-hosted runners: No new charges. But the fact that GitHub tried this tells you it’s probably coming back in some form eventually.
That last point matters. If your CI/CD strategy depends on self-hosted runners being free forever, you might want a contingency plan. GitHub backed down this time, but the underlying economics haven’t changed — the control plane costs money to run, and GitHub clearly wants to recoup that.
7 Ways to Actually Cut Your Actions Bill
Whether you’re paying less than before or bracing for future changes, optimizing your workflow minutes is just good engineering hygiene. Here’s what actually moves the needle:
1. Cache Everything That Doesn’t Change Between Runs
This is the single highest-impact optimization, and I’m still surprised how many teams skip it. Use actions/cache@v4 for dependencies, build artifacts, and anything else that’s deterministic between commits.
- uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-The key trick: base your cache key on lockfile hashes, not branch names or dates. You want cache hits across PRs that share the same dependency tree. Teams I’ve worked with report 30–60% reductions in build time from caching alone.
2. Cancel Redundant Runs with Concurrency Groups
If someone pushes three commits in quick succession to a PR branch, you don’t need three full CI runs. Use concurrency groups to cancel superseded runs:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: trueThis is basically free money. Most teams push multiple times before a run even finishes, and every cancelled run is minutes you’re not paying for.
3. Use Path Filters to Skip Irrelevant Workflows
Don’t run your full test suite when someone updates the README. Path filters let you scope workflows to the files that actually matter:
on:
push:
paths:
- 'src/**'
- 'tests/**'
- 'package.json'This sounds obvious, but I’ve seen teams running 15-minute build pipelines on documentation changes. Set up separate, lightweight workflows for docs and config files.
4. Fail Fast and Gate Expensive Jobs
Run your cheapest checks first — linting, type checking, unit tests. Gate your expensive integration tests and E2E suites behind those:
jobs:
lint-and-test:
runs-on: ubuntu-latest
steps:
- run: npm run lint
- run: npm run test:unit
integration:
needs: lint-and-test
runs-on: ubuntu-latest
steps:
- run: npm run test:integrationIf linting catches a syntax error in 30 seconds, there’s no reason to spin up a 10-minute integration test suite. You save the minutes on every failed run.
5. Consolidate Small Jobs
GitHub bills each job rounded up to the nearest minute. Five jobs that each take 20 seconds? That’s 5 billed minutes. One job that takes all five steps in 100 seconds? That’s 2 billed minutes.
This conflicts with the “keep jobs small and parallel” advice you’ll see in a lot of CI/CD guides. And for fast feedback loops, parallelism is great. But if your jobs are individually tiny, the per-job rounding tax adds up. Find the balance — parallel where it saves wall-clock time, consolidated where it saves billed minutes.
6. Stay on Linux Unless You Absolutely Need macOS or Windows
At $0.006/min vs. $0.062/min, running Linux instead of macOS is roughly 10x cheaper. Cross-compilation, Docker-based builds, and most test suites can run on Linux even if your production target is macOS or Windows.
Reserve macOS runners for things that genuinely require them: iOS/macOS builds with Xcode, platform-specific UI tests, and notarization. Everything else? Ubuntu.
7. Monitor and Audit Your Usage
GitHub’s billing dashboard shows per-workflow and per-repository usage. Check it monthly. You’ll almost certainly find workflows that run more often than needed, or repos with abandoned CI configs that still consume minutes.
The GitHub Actions usage API lets you pull this data programmatically if you want to build dashboards or alerts. Set a budget threshold and get notified before you blow past it.
When Third-Party Runners Make Sense
If you’re spending more than a few hundred dollars a month on hosted runners, third-party runner providers are worth evaluating. They use the same GitHub Actions YAML — you just change the runs-on label — but offer faster machines, better caching, and often lower prices.
The landscape has shifted a bit in 2026. BuildJet, which was a popular option, shut down in January 2026. But several strong alternatives remain:
Blacksmith offers 3,000 free minutes per month on their pay-as-you-go plan, with 2-vCPU x64 runners at about $0.004/min. They’ve invested heavily in CI analytics and centralized log search, which is useful if you’re trying to debug why builds are slow. Their performance benchmarks are consistently near the top for x64 workloads.
Namespace takes a credit-based approach at $0.015 per credit, with interactive debugging via SSH and VNC — which is genuinely useful when you need to inspect a failing build environment live. Their arm64 performance leads the pack.
RunsOn is interesting if you want the control of self-hosted runners without the maintenance overhead. It runs on your own AWS account, so you get AWS pricing on compute while RunsOn handles the runner lifecycle.
Depot focuses on Docker builds and container-heavy CI. If your pipelines spend most of their time building and pushing images, Depot’s shared caching can cut build times dramatically.
For all of these, the migration is usually trivial: change runs-on: ubuntu-latest to the provider’s label, add a setup action or token, and you’re done. The workflow YAML stays the same.
Should You Move Off GitHub Actions Entirely?
Probably not, unless your CI/CD costs are a top-line budget item. GitHub Actions’ biggest advantage isn’t price — it’s integration. It lives where your code already is, the event model is deeply tied to GitHub’s pull request and release workflows, and the marketplace has an action for nearly everything.
GitLab CI is the strongest alternative if you want an all-in-one platform with built-in container registry, security scanning, and release management. But migrating means migrating your repos too, or at least mirroring them. That’s a much bigger commitment than swapping runner providers.
CircleCI has an edge in raw build speed and their Docker layer caching is excellent. But their free tier is stingy (500 minutes/month for the free plan), and pricing can get complicated with resource classes and concurrency limits.
My take: optimize your GitHub Actions usage first with the techniques above. If you’re still spending too much, try a third-party runner provider — it’s a 5-minute config change. Only consider a full platform migration if you have other reasons beyond cost (better security scanning, self-hosted requirement, GitLab’s integrated DevSecOps pipeline, etc.).
What to Expect Next
GitHub hasn’t forgotten about monetizing the control plane. The self-hosted runner charge will almost certainly come back in some form — probably with a higher free tier, better communication, and maybe a flat monthly fee instead of per-minute billing.
If I had to guess, I’d say they’ll roll it into GitHub Enterprise pricing rather than charging per-minute on Team plans. That’s a cleaner sell: “Enterprise includes unlimited self-hosted runner orchestration” sounds a lot better than “$0.002/min for using your own hardware.”
In the meantime, the January 2026 hosted runner price cuts are real and already saving teams money. Take the win, optimize your workflows, and keep an eye on GitHub’s pricing page. CI/CD costs aren’t going to stabilize anytime soon.