Skip to content

New Pricing of self-hosted GitHub Actions Runners explained

Today GitHub announced changes to pricing for GitHub-managed runners and introduced a new per-minute charge for organizations using self-hosted runners. Below we’ll dive into what changed, the backstory, how companies have been using self-hosted runners, and how this affects third-party providers like us.

What exactly is changing?

There are two main changes, in order of importance:

  • GitHub will charge $0.0002 per minute for jobs executed on self-hosted runners starting March 1st 2026.
  • Up to 39% price cut across GitHub-managed runners starting January 1st 2026.

Backstory

GitHub Actions were released on November 13, 2019. Actions let individuals and organizations automate workflows on nearly any GitHub event (e.g., “issue created”), with most usage focused on CI/CD for pull requests: running linters, executing tests in parallel, building deployable artifacts, and more. Actions quickly dominated the CI/CD market and replaced Jenkins and other providers for many organizations on GitHub.

GitHub Actions weren’t perfect, but they covered ~80% of most companies’ needs and were natively integrated into GitHub’s model, UI, and billing.

The biggest drawbacks of GitHub Actions were:

  • A somewhat limited way to express complex builds in YAML.
  • Limited options for where jobs could run.

Self-hosting

On April 22, 2020, support for self-hosted runners was released. This gave companies the flexibility to choose where and how they run Actions. Teams could run jobs on self-hosted machines within their own infrastructure, pick more powerful CPUs, and curate a “golden image” with the exact packages and tools their org needed.

Best of all, GitHub’s orchestration was free for self-hosted runners. Companies paid only for the compute from their chosen providers while GitHub handled orchestration at no charge. Too good to be true — especially for large enterprises with the skills to operate their own runner fleets.

Market of third party runners providers

Soon after, a new market emerged: companies providing custom runners for GitHub Actions. The winning strategy was to buy the fastest hardware available and place it in specialized data centers to squeeze out maximum performance. The common one-liner: “Our per-minute price is half as much, and the runners are twice as fast.” That’s an easy sell — promising to cut CI bills by roughly 4x.

We chose a different path. With Cirrus Runners, we price by concurrency (how many jobs you can run at once) and don’t charge per minute at all. This maps directly to our cost model: we buy the hardware and place it in data centers on monthly contracts, unlike generic cloud providers where near-infinite scale comes with higher per-minute margins.

What’s changing

Like any other pricing change, it’s bittersweet — sweet for ~99% of users and a little bitter for the top ~1%. In this case, teams that only use GitHub-managed runners will just see smaller bills. There’s no change to CPU speed, memory, or machine types — just pricing. But the ~1% who push the limits on self-hosted will start to see an extra line item in their monthly bills.

Our opinion is that this change has been a long time coming. GitHub’s functionality for self-hosted runners hasn’t seen much movement recently. The announcement post indicated plans to invest in self-hosted experience and outlines a few upcoming improvements. Unfortunately, these improvements don’t align with the most popular feature requests the community actually asked for for years. We hope it’s only top of the iceberg and we’ll see more improvements but only time will tell.

How it affects Cirrus Runners

Cirrus Runners has always been fixed-price for unlimited minutes, and it will remain so. Our principle has always been a fixed monthly price with no hidden costs—no extra charges for traffic or storage.

On average, our customers save around 15x compared to what they would have paid to GitHub. In that context, the new per-minute fee is roughly ~0.1% of the effective per-minute cost our customers avoid by using our fixed-price model.