>In the past, our customers have asked us how GitHub views third-party runners long-term. The platform fee largely answers that: GitHub now monetizes Actions usage regardless of where jobs run, aligning third-party runners like Blacksmith as ecosystem partners rather than workarounds.

It does? I feel like it implies that they want third-party runners like Blacksmith out of the ecosystem, which is why they're now financially penalizing customers who use them.

With these changes, three things hold:

1. Services like blacksmith and WarpBuild (I'm the founder) are still cheaper than GitHub hosted runners, even after including the $0.002/min self-hosting tax.

2. The biggest lever for controlling costs now is reducing the number of minutes used in CI. Given how slow Github's runners are, or even the ones on AWS compared to our baremetal processor single core performance + nvme disks, it makes even more sense to use WarpBuild. This actually makes a better case for moving from slow AWS instances running with actions-runner-controller etc. to WarpBuild!

3. Messaging this to most users is harder since the first reaction is that Github options make more sense. After some rational thought, it is the opposite.

Overall - it is worse for Github users, but options like blacksmith and WarpBuild are still the better option.

I checked the WarpBuild website and got excited because the header in the menu says you have macOS Intel runners, but then you click through and it doesn't seem to be so?

Right now at my company our biggest complaint are macOS Intel runners from GitHub which somehow take 15+ minutes to provision and are the slowest of the bunch.

We only have macos arm64 (M-series) runners. Can you point me to the intel reference so I can fix it?

Hover the top nav. Under "CI Runners" it's says:

macOS Runners Apple Silicon and Intel support

fixed it - sorry about that.

I can assure you WarpBuild has Mac runners that work very well. When I first switched GH only offered 1 Mac runner and it was horribly slow. Literally cut my build times in half by changing 1 line in my workflow file to use the WB runner.

Nowadays GH has more sizes by WB continues to beat them in price and performance.

It’s highway robbery what GH charges for the crap they provide. I can highly recommend WarpBuild for Mac (and Linux) runners.

I was talking specifically of macOS Intel runners. The sibling comment from the founder confirmed they don't have them.

"WarpBuild are still the better option."

what makes you think they won't hike the control plane price again? They can turn this knob arbitrarily to put you out of business.

The statement regarding the better option is as it stands today and does not account for all possible futures.

Reg. hiking it again, they'd have to either be extremely anti-competitive and selectively apply the pricing OR apply the hike uniformly by about double the current value to match our pricing while making it completely unviable for any large co to use self-hosted github actions in the first place.

That's clearly the case, this is a three-pronged manoeuver :

- Introducing a cheap 1-core runner

- Lowering the price of GitHub-hosted runners

- Making it slightly more expensive to use self-hosted runners

- There is actually a fourth one: the vnet integration, which also allows you to run public runners in your own infra

As a bonus, for some people it means something that was free is now not free. Those who are willing to pay rather than go, might prefer to use GitHub-hosted if they are going to pay anyway.

This is clearly an incentive to use github-hosted, and their sales reps are also going this way.

I require the VNet integration, but my region (Europe West) isn't supported (yet, over a year since I requested it)

https://docs.github.com/en/enterprise-cloud@latest/admin/con...

Well, these people earn their living by saying these things that only seem to make sense superficially but don't withstand closer scrutiny.

Getting acquired by Microsoft is a death sentence for any product.

The only variable is how long after acquisition before they gut it. It's almost never right away. GitHub was acquired 7 years ago, but it started showing symptoms perhaps 2 years ago.

With this I think it's clear the wound was fatal. GitHub will stumble on for a few more years with ever-decreasing quality, before going the way of Skype.

So, I guess we're all migrating to gitlab? Or is it time to launch gittube? Githamster?

The exodus from GitHub has not begun, as far as I can tell.

They seem to care much less about free users than in the past but businesses still flock to it. GitLab is the only other platform I’ve seen in the workplace of anywhere I worked, with the exception of a big tech company I worked at. They had both GitHub enterprise and an internally maintained platform which was being phased out. if I recall correctly it based on Phabricator

I've seen a small but increasing trickle of open source projects leaving github for free(libre) alternatives lately. It's not a stampede but I'd say the exodus is on its way.

The considerations for commercial users leaving github are probably pretty different, so perhaps they'll stay.

Github, i.e. MSFT will of course adjust their offer if they would start seeing an significant exodus. They could afford being a loss leader indefinitely.

There’s also a large bunch of projects that will never leave, some of which ms have influence over. I mean, some high profile open source projects hasn’t even left source forge yet, even though it has been malware infested shithole for decades.

In case you're considering moving to GitLab we currently have no plans that I'm aware of to pay from bringing your own runners. Happy to answer any questions.

Why are the self-hosted plans so expensive? Such a high bar to go from free to paid.

> The only variable is how long after acquisition before they gut it.

Considering that the lifetime of our sun system is finite that statement is undeniably true.

Also we don't know how a non-Microsoft GitHub could have developed.

This looks really nice actually! European non-profit is hitting some really good buttons for me! Thanks for the tip, I hadn't heard of codeberg before!

It got a boost in popularity recently when Zig announced its move from GitHub to Codeberg: https://ziglang.org/news/migrating-from-github-to-codeberg/

But other alternatives exist as well, like Sourcehut: https://sr.ht/

This pricing model continues to incentivize them not fixing the hundreds of clearly documented issues that causes CI to be incredibly slow. Everything from their self-inflicted bottlenecking of file transfers to the safe_sleep bug that randomly makes a runner run forever until it times out.

If Microsoft had not acquired GitHub, there would not be GitHub Actions. GitHub Actions is a mediocre knock-off of Azure Pipelines, and it was launched after the acquisition.

Azure Pipeline wasn't mediocre?

Still is.

hopefully something decentralized like https://tangled.org

Hopefully something ForgeFed-powered, so that we can all re-decentralize, as is right and proper.

I'm running forgejo on my NAS, including CI runners etc. Harder to share with folks but great for my personal projects (except building an iOS app, which someday I'll set a Mac Mini up for probably)

Microsoft has started raising prices on many of their products. I suppose they decided that their current customers need to pay the increased CapEx for AI;) New motto - AI pay for it whether you use it or not.

No such thing as free parking

No but there is validated parking for customers of other services.

This is going to be the downfall of GA

Control, Alt, Delete.

Here are the practical implications and considerations to optimize for cost, given the new pricing. These are generic and ensure you think through your workflows and runners before making any changes.

1. Self-hosting runners or using WarpBuild/blacksmith runners is still cheaper Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) or using WarpBuild/... runners remains the cheaper option.

2. Prefer larger runners If your workflow scales with the number of vCPUs, prefer larger runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.

For example, using actions-runner-controller with heavy jobs running on 1 vcpu runners is not a good idea. Instead, prefer a 2vcpu runner (say) if it runs the job ~2x faster.

3. Prefer faster runners All else being equal, prefer faster runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.

For example, if you're self-hosting on aws and using a t3g.medium runner, it's better to use a t4g.medium runner since the newer generation is faster, but not much more expensive.

4. Prefer fewer shards If you have a lot of shards for your jobs (example: tests on ~50 shards), consider reducing the number of shards and parallelizing the tests on fewer but larger runners.

5. Improve job performance This is not new advice, but it's now more important than ever because of the additional GitHub self-hosted runner tax.

6. Use GitHub hosted runners for very short jobs For linters and other very short jobs, it's better to use GitHub hosted runners.

Hope this helps. Note: I'm the founder of WarpBuild. I'm biased, but the points above hold.

Time to get off for good. We're moving to https://forgejo.org/. With downtime and this, screw them.

a per-job cost instead of per-minute cost for non-compute "control plane" for CI would have made more sense and seemed more reasonable to me -- but don't really know if customers would have liked it better/worse or paid more/less under it.

(I work exclusively on public repo open source at the moment, and get Github actions for free).

I wonder if players like Depot could sidestep GHA by using webhooks instead of acting as a custom runner, in other words build their own compatible control plane. I guess it would probably break a lot of workflows.

What I'd really like to see is some new CI/CD systems though. Actions is garbage in multiple dimensions. Can't somebody do something clever and save us from this flaky insecure YAML hell?

Founder of Depot[0] here. To answer your idea, at Depot we already have this concept internally. In fact, Depot isn't reliant on webhooks at all to run your jobs. One of the reasons we can be up running your jobs when GitHub webhooks service is down. Effectively, we listen to a different system to know you have a job that needs to be run.

To your second statement, I generally agree. Sounds strange to say given we're in the business of GHA runners. But it's just not a performant or reliable system at scale. This change from GitHub doesn't smell of a company that wants to do right by it's users.

If you are interested in what is up next for us at Depot, feel free to ping me via the email in my bio. I think you'll be quite interested in what we are doing.

[0] https://depot.dev

Related:

https://news.ycombinator.com/item?id=46291156

Comments moved thither. Thanks!

The way Github, Xamarin and other acquisitions have gone down, it is quite clear that the Satya charming phase is sadly gone.

Yeah... Kind of expected GHA to be a money trap at some point. It was tempting with how easy it is to setup. And every since Claude Code integrated tightly it assumes i want pipelines in gha even though I have pipelines elsewhere. Glad I stuck with picking a different system and didn't invest a lot of time here. I had plenty of compute to run jobs myself.

At $0.002 per minute there are at most 90 dollars in a month. Maybe even after an year of cumulative costs it's less then the cost of switching to something else. Maybe even after many and many years of cumulative costs: the larger the company the more expensive corporate inertia gets.

Our org is showing around 200-300$/mo in added fees and we are exclusively self hosting in our own on premise cluster. Kind of wild we have to pay to use our own compute.

In fairness to Github, bringing your own runners isn't "free" on their end. The orchestration happens server-side, so there is some level of cost. I don't know if that justifies the $0.002/min price - just wanted to point this out.

Oh absolutely, but honestly the self hosted runner setups that I'm familiar with are just waiting for a call. As far as I can tell GH side just routes.

if you were only paying to use your own compute, you could just use your own compute - you don't have to use github actions, you can trigger actions on your own systems without github.

the control plane clearly has value to people beyond the compute used for running the actions, and it seems reasonable that they should charge for that if you're using it.

We are a ~20 person team who use private runners and this will increase our annual costs by ~12k/yr. This is a huge relative cost increase for us. If anything this hurts small teams that focused on expansive automated testing more than giant orgs.

I agree that it’s probably not a big amount. But note that it can be potentially quiet a bit more than the 90$. Task runtimes are always rounded up to the nearest minute.

For example, in our pipeline we have 5 different linter tasks (for different subprojects), running each only a few seconds. Nonetheless, we’ll get billed for 5 minutes on every commit.

Ah I see, they are not minutes as on the clock. They are runtime minutes. That changes my assessment. I was thinking that they picked a balanced price point not to scare away many people except probably personal projects or unfunded open source. If it's something potentially in the ballpark of $500 per month it's a bit too greedy. It's more like: we want only corporate customers, free tier users need not apply.

Per minute per runner. If you have multiple workfows/jobs running, it can add up.

It's a bit weird, they add pricing for this, but reducwle GitHub-hosted runners by "up to 39%".

Not sure about the "up to" implications, but I guess it's just Microsoft trying to make github a bit more freemium tm

The full quote:

> And we’re reducing the net cost of GitHub-hosted runners by up to 39%, depending on which machine type is used.

> The price reduction you will see in your account depends on the types of machines that you use most frequently – smaller runners will have a smaller relative price reduction, larger runners will see a larger relative reduction.

it explains github actions update better than github

If I have a VPS, what should I be running on it to replace github actions? (eg run tests, return pass/fail to github PR)

https://woodpecker-ci.org is an option. It's an open source CI tool, that supports integration with GitHub (among others).

Makes you wonder, how much the AI madness will be able to cannibalize other buisness sectors before it encounters the limits of growth there, leaving behind hollowed out eco-systems - similar to how adds ruined everything.

Related:

GitHub will begin charging for self-hosted action runners on March 2026 https://github.blog/changelog/2025-12-16-coming-soon-simpler... (Discussion: https://news.ycombinator.com/item?id=46291156)

I guess this is on brand for Microsoft. Just lame to go through the trouble to self host runners and still get tacked on with fees after the fact.

Hard for me to feel like our industry is innovating and not just gouging with the rest in the battle for enshittification.

I will intentionally start exploring other options even if the cost isn't high, because I don't want to support this type of thing.

Is there any included free amount of platform minutes for private orgs/repos? Currently using Blakcksmith with arm64 and do around 600 minutes a month (very small). I get 2,000 free minutes of GitHub runner time for free, so maybe have to switch to using GitHub native arm64 runners.

That being said even with no free platform minutes my Blacksmith usage will only $1.20 a month in platform fees, so inconsequential.

Use open source software. Buy your own compute. Make the effort. It's worth it.

I'm kind of ok with renting compute so long as it's running open source software.

Basically I'll gladly pay for a service, but I don't like getting locked into that service. If the payed service is using FOSS, I will always have the option to migrate if the provider starts to misbehave

Rented compute is fine, just plan for being able to lift and shift at a moments notice.

> TL;DR GitHub is adding a $0.002-per-minute fee on all GitHub Actions usage, so the control plane is no longer free.

That's not true for _all GitHub Actions usage_.

https://resources.github.com/actions/2026-pricing-changes-fo...

> Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free.

That was my biggest concern... I've used runners for personal/public repos because they're there and generally good enough. If I were paying for it, I might be inclined to look at faster options.

Enshittification deepens.