The writing is in the wall. First it was UX annoyances. Then it was GitHub Actions woes. Now it is paying money for running their software on your own hardware. It's only going to go downhill. Is it a good time now to learn from our mistakes and convince our teams and management to use community-maintained, libre alternatives? They may be inferior. They may lack features. But they're not going to pull user hostile tricks like this on you and me. And hey, if they are lacking features, maybe we should convince our management to let us contribute time to the community to add those features? It's a much better investment than sinking money into a software that will only grow more and more user hostile, isn't it?

We currently self-host on kubernets/aws. The thing that really got to me isn't the new charge per se. It's the fact that GHA has a ton of problems. I can hold my nose and deal with them when it's free. But now that you're squeezing me, at least you could have created something like GHA 2.0 and added a charge for that. Instead, there are vague roadmap promises which don't even include things that I care about. Specifically:

- Jenkins had better kubernetes integration years ago. It's crazy that GHA can't beat that.

- "Reintroducing multi-label functionality" - yeah, so they first broke it. They did supply "reasons", which looked like they never talked to a customer. [1]

- Still no SDK of any kind.

- "Actions Data Stream" - or you can just fix your logging.

There are dozens more complains, which are easy enough to find. This kind of an approach just makes me want to make sure that I don't use GHA again. Even if I end up paying another vendor, at least I'll be treated as a customer.

[1] - https://github.com/orgs/community/discussions/160682#discuss...

Of course, if you can just fence in your competition and charge admission, it'd be silly to invest time in building a superior product.

Charging for self-hosted runners is an interesting choice. That's the same cost as their smallest hosted runners [1]

[1] - https://docs.github.com/en/billing/reference/actions-runner-...

This is $2.88/day, $86.4/month, $1051.2/year. For them to do essentially nothing.

Most notably, this is the same price as their hosted "Linux 1-core" on a per-minute basis. Meaning they're charging you the same for running it yourself, as you'd pay for them to host it for you...

The GitHub encrapification finally affects me. I am militantly unwilling to pay per minute to use my own computer. Time to leave. I can trigger and monitor builds myself thank you very much.

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?

Anyone using GitLab or any other VCM that you'd recommend? I'm absolutely done with Github. Or is everything else just as bad?

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.

1. https://medium.com/@the_atomic_architect/github-vs-gitlab-20...

I'm happy for competition, but this seems a bit foul since we users aren't getting anything tangible beyond the promise of improvements and investments that I don't need.

https://tangled.org/tangled.org/core/blob/master/docs/spindl...

(no affiliation)

---

Blog post about Tangled's CI: https://blog.tangled.org/ci

* Codeberg https://codeberg.org/

* Sourcehut https://sr.ht/ [1]

[1] https://sourcehut.org/alpha-details/

It used to suprise me that people saw cool tech from Microsoft (like VSCode) and complain about it.

I now see the first innings of a very silly game Microsoft are going to start playing over the next few years. Sure, they are going to make lots of money, but a whole generation of developers are learning to avoid them.

Thanks for trying to warn us old heads!

i think it should be illegal or otherwise extremely damaging to do this kind of thing

1. Self-hosting runners is still cheaper than not Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) 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.

Note: I make WarpBuild, where we provide github actions runner compute. Our compute is still cheaper than using github hosted runners (even with the $0.002/min tax) and our runners are optimized for high performance to minimize the number of mins consumed. I'm generally biased, but I think the points 1-6 apply irrespective of WarpBuild.

Charging a per-workflow-minute platform fee makes a lot of sense and the price is negligible. They're ingesting logs from all the runners, making them available to us, etc. Helps incentivize faster workflows, too, so pretty customer-aligned. We use self-hosted runners (actually WarpBuild) so we don't benefit from the reduced default price of the Github-hosted runners, but that's a nice improvement as well for most customers. And Actions are still free for public repos.

Now if only they'd let us say "this action is required to pass _if it runs_, otherwise it's not required" as part of branch protection rules. Then we'd really be in heaven!

https://docs.gitea.com/usage/actions/act-runner

I'm sure we'll feel it too at https://sprinters.sh, but probably a bit less than others as our flat $0.01 per job fee for runners on your own AWS account will still work out to about 80% average savings in practice, compared to ~90% now when using spot instances.

To spell it out: jobs can hang forever because of some ridiculously bad code on their end, they have a 6 hour cap, so that's 6 hours of billable $$$ per-instance of the bug (assuming it wasn't manually canceled). I know I've seen jobs hang forever regularly over the course of my years using GitHub for work.

Note: pretty sure this has been resolved.

Now Microsoft will charge "data plane usage" (CRUDing a row that contains (id, ts, state_enum, acc_id ...) in essence) 2.5 more than what Ubicloud offers for WHOLE compute. Also to have "fair pricing" they'll make you pay 2.5 more the compute's price for being able to use their data plane.

cool.

As far as I can tell from that article, these changes will not affect me; it says "Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free" and another section says "This will not impact Actions usage in public repositories". Hopefully, this information would behelpful for other people who use GitHub Actions. However, I don't know if I missed something else that is important, from the article.

From this perspective this is a huge price jump, but self-hosting to save money can still work out.

Honestly, GitHub Actions have been too flaky for me and I'm begrudgingly reaching for Jenkins again for new projects.

[1] https://instances.vantage.sh/aws/ec2/m7i.large?currency=USD&...

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

Today it's possible to spin up a company that sells GitHub Actions runners with a lower price and higher performance than GitHub's own hosted runners. These new fees will make that a lot less economically viable.

Holy s***

That's more expensive than an m8i.large.

What on earth.

Part of this is fair since there is a cost to operating the control plane.

One way around this is to go back to using check runs. I imagine a third party could handle webhooks, parse the .github/workflows/example.yml, then execute the action via https://github.com/nektos/act (or similar), then post the result.

It’s been awhile since I looked. What’s a good alternative?

I get that self-hosted runners generate huge egress traffic, but this is still wild. Hope it pushes more companies to look into self-hosted Gitea / Forgejo / etc.

I have cron jobs on several github projects that runs once a day and I have never been charged anything for it (other than my github membership). Should I expect to be charged for this?

GitLab CI and others seem to be perfectly serviceable.

Focus on the enterprise. Something like a 3000$ minimum yearly price. Direct customer support with real engineers no questions asked.

Need someone to setup your CICD, that's another fee, but on staff engineers will get it done.

Edit: I'd even imagine a company like this can bootstrap, I'd need help though. Would probably take 4 skilled SWEs about 6 months for an MVP.

https://docs.github.com/en/actions/reference/workflows-and-a...

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?

This is not new, not unexpected. This is ongoing. Nothing stops this because who wins elections? How do they pay for all that publicity. Certainly "contributing" to campaigns is much cheaper than paying your taxes.

Supposedly this is a place for hackers. Hackers can build a better alternative.

It'll be interesting to see how this affects third party companies providing GitHub runners.

To solve the problem, I created a simple vm in Google Cloud with a lot of CPU and memory that runs Ubuntu. I installed enough stuff on it to be able to check out code and run our build script (a jvm and gradle basically). And then I modified the Github action to 1) start the vm, 2) trigger the build script via ssh 3) pause the vm so we don't get billed for it. That vm runs for maybe an hour per month or so. It would probably cost us hundreds of euros per month if we ran it 24/7. But 1/3600th of that barely registers on our bills. And it's nice and fast.

This has been working flawlessly for a few years now. The Github action takes about 3 minutes. That includes starting the vm, running the script, and shutting the vm down again.

Wonky in a way. But also simple and robust enough. People over engineer/over think this stuff for the wrong reasons. For example, I could of course automate the provisioning of that vm. But I haven't. Because I only ever touch it once a year or so to run a quick apt-get update. I rebuilt it a few weeks ago in a different region. That was like a 20 minute job. Terraform or Ansible for vms you only create once every few years is redundant and might take more time than you would save. I can always do that when that stops being true.

I've been running this startup on the freemium layer in Github for five years now. It's great as a free service. I would actually pay for it if I needed to. I did actually pay for it before MS acquired Github in a previous startup when business usage wasn't free. But so far, there's no need for me to do that. I also run some monitoring scripts as Github actions. Simple curl jobs against our servers that trigger alerts when they fail. That has to run somewhere. It might as well be Github actions. But if/when that becomes inconvenient, I can improvise other solutions.

I do not know what route are these companies taking. Microsoft has been crazy for past 2-3 years, but it is sad to see BitBucket and other alternatives also taking similar route :/

[0] https://docs.gitea.com/usage/actions/overview

[1] https://gitea.com/gitea/act / https://gitea.com/gitea/act_runner

[2] http://github.com/nektos/act

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.

If you've been running your runners on your own infra for cost reasons, you're not really that interesting to the Github business.

This is an insult to anyone who bought into GitHub. It's an insult to all of us who have been doing OSS there for years. This is how you kill your business and any loyalty or trust in your brand.

What a disaster.

I was just using act (https://github.com/nektos/act) on my local server to build the X64 packages for my project, since I want to streamline it with ARM64 support, I migrated to the github self hosted runners.

This is really ridiculous, is M$ really lack that money just to schedule the Jobs running not in there infra?

It's not outrageous money today, but it's a clear signal about where they want CI to live.

1 - https://github.com/orgs/community/discussions/32376

- Git repo - Ticketing, Kaban - Full helpdesk - Complete and full CI/CD - everything links via custom workflow - self hosted

I still dont know why everyone hasn't switch yet to that banger.

Are Control Plane costs already separately charged?

a nice feature would be if they limit the number of branches, too: - <=2 branches: free - <=5 branches: 3.00$ per user per month - >5 branches: contact enterprise sales

to top it all off, they round up to the nearest whole minute instead of billing for actual usage which i assume they'll use for this new charge.

Running workers ourselves was the last resort, we tried everything else but it was impossible to get fast (and consistent) build times otherwise.

In a way we are now going to get charged for Github's poor execution on Actions.

Why would a public repo use a self-hosted runner ? because the self-hosted runner storage available is only 14GB !!

My org sadly has a lot of github actions workflows, even after this it's not expensive enough to justify migrating away, but with all their downtime and bugs they are really pushing us closer and closer.

Can't we switch to something more advanced in terms of protocols (like one that always maintain 3 copies, and where people can give ressources (cpu/bandwidth/memory) in the forms of tokens)?

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

https://github.com/orgs/community/discussions/182186

I'm in the era of writing my own tools, not to share just for me or whatever group I'm working in. If you're going to charge me for something rife with annoying struggles, I might as well be annoyed by a tool I control.

I suspect we'll be doing that sometime in January or February.

I guess forgejo is the easiest migration path? https://forgejo.org/

But nothing they've done in the last few years has demonstrated improvement in this area. As the person with both purchasing and final authority on these things in my org, it's hard to stomach.

Charging per minute for self-hosted runners seems absolutely bananas!

I hate GH Action runners with a passion. They are slow, overpriced, and clearly held together with duct tape and chewing gum. WarpBuild, on the other hand, was a breeze to setup and provided faster runners and lower prices.

This is a really shitty move.

Hey GitHub, your Microsoft is showing...

The biggest issue is the compatibility, forgejo doesn’t have all the actions available that GitHub does nor some of the same functionality

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

When building on self-hosted windows machines, you actually pay three times.

Oh I wish I could make my customers pay three times for everything I deliver, I might be as rich as Bill by now.

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.

People, now, are going to be annoyed and/or pissed off about this and look for/move to alternatives. It's not even that difficult to move, and if you're already self-hosting runners you're also in the position to self-host your Forge or move elsewhere.

Actions isn't even good enough to demand this. They're slow, buggy, and full of shit.

Feels super much like the classic Microsoft short-sighted bullshit. Take something that's been running well, and people were happy, then abruptly change it in disruptive ways and slowly kill your products that were doing just fine.

Github can just drop Actions pricing and leave the self-hosted stuff alone, and people would even have extended more goodwill. Is MS this short-sighted and greedy as to push further toward killing a golden goose?

Thanks, enshittification.

These people will forever unto the end of time into their afterlife have a Harem of old ladies following them around laughing at their never ending hilarious hot takes.

We will continue to do our best to provide the fastest GHA runners and keep them cheaper than GitHub-hosted runners.

[0] https://depot.dev

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.

It seems GitLab has a much better experience in this department, but their pricing is hard to justify for us...

Genuinely curious if folks here had better experiences or recommendations for a smooth CI/CD experience.

- DroneCI

- ConcourseCI

- forgejo can use github actions

[1] https://nesbitt.io/2025/12/06/github-actions-package-manager... [2] https://github.com/github/roadmap/issues/592