Pricing Changes for GitHub Actions

Every company I've been at that tried to self-host something like GitLab, later moved to GitHub. Nobody in business cares if it's open source/free software. They care about managed hosting, centralized services, invoicing, etc. DIY is great for hobbyists and the cash-strapped.

Actually there were alternatives that were far superior (seriously, no way to group projects?) but also more than 2x as expensive. If GH "fixes the glitch" then it will be plan B time.

For example, Azure has had a script runner service for ages that you can hook up to your ”own” vm, by installing an agent. But then you pay double, the fee (per second) for the service as long as the script is running, and the fee (per second) for the vm in azure as long as it exists. So, as with GitHub actions, it’s cheaper to run it on their provided crap instances.

To get rid of the double costs I guess you could install your own CI server and agents, that polls the GitHub repo, but then you don’t get the integration in their web gui. That was what you did before gh actions came around, a local Jenkins for example.

1) company uses exclusively free software, spends more time dealing with the shortcomings of said software than developing product, product is half baked and doesn't sell well, company dies.

2) company uses proprietary but cheap/free (as in beer) software that does the job really well, focuses on developing product, product is good and sells well, company how has a ton of money they could use to replicate the proprietary product from scratch if they wanted to.

A purist approach like in scenario 1 leaves everyone poor. A pragmatic approach like scenario 2 ends up earning enough money that can be used to recreate the proprietary software from scratch (and open-source it if you wanted to).

In this case the problem isn't even the proprietariness of the software, it's the fact that companies are reliant on someone else hosting the software (GH being FOSS wouldn't actually change anything here - whoever is hosting it can still enforce whatever terms they want).

FOSS alternatives already exist, it's just that our industry is so consumed by grifters that nobody knows how to do things anymore (because it's more profitable for every individual not to); running software on a server (what used to be table stakes for any shop and junior sysadmin) is nowadays lost knowledge. Microsoft and SaaS software providers are capitalizing on this.

it changes and you move on.

How is there not a collective decision to dissolve them?

"Thank you for your interest in this GitHub action, however, right now we are not taking contributions.

We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in."

We had it done with a week to spare.

Apples to oranges, naturally, but like this, our infra-jenkins master would pay for itself in hosting in a week of ansible integration testing compared to what GHA would cost. Sure, maintenance is a thing, but honestly, flinging java, docker and a few other things onto a build agent isn't the time-consuming part of maintaining CI infrastructure.

And I mean sure, everything is kinda janky on Jenkins, but everything falls into an expectable corridor of jank you get used to.

They’ve lowered their runner costs to compete, and introduce minimum charge to discourage abd make sure they still get paid.

The runner configuration and registration process is unnecessarily byzantine. [1]

They can't cancel jobs cleanly. [2]

There are consistency problems everywhere. [3]

Their own documentations describes horrible things unless you use runners in JIT mode. Though JIT runners are not always removed after exit.

If there is a worse self-hosted CI runner, I haven't yet met it.

[1] https://docs.github.com/en/actions/how-tos/manage-runners/se...

[2] https://github.com/orgs/community/discussions/26311

[3] https://github.com/orgs/community/discussions/62365

> Actions is down again, call Brent so he can fix it again...

In my experience gitlab always felt clunky and overly complicated on the back end, but for my needs local forgejo is better than the cloud options.

(People seem to object to this comment. I genuinely do not understand why.)

The runner software they provide is solid and I’ve never had an issue with it after administering self-hosted GitHub actions runners for 4 years. 100s of thousands of runners have taken jobs, done the work, destroyed themselves, and been replaced with clean runners, all without a single issue with the runners themselves.

Workflows on the other hand, they have problems. The whole design is a bit silly

(ofc, that'd only mean they stop updating the status page, so eh)

Edit: Confused GitLab and Bitbucket

https://github.com/neysofu/awesome-github-actions-runners

Orchestration, logging, caching, result storage.

It's not nothing. Whether it's worth it to you is a value judgement, and having run a bunch of different CI systems I'd say this is still at least competitive.

Maybe this is designed to scare people away from self-hosting altogether?

Of course entirely expected after MS buyout, if anything I'm surprised it took that long

The real mistake was GH not charging anything for self-hosted runners in the first place, setting an expectation.

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

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.

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.

- 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.

Alternatively, Forgejo, Gitea, or (based on praise I've seen from other people) maybe sourcehut.org.

I find GitLab's interface intolerable. Heavy reliance on javascript even for read-only access, nonintuitive organization, common operations hidden behind menus, mystifying icons... Every time I seek out a project's home and discover a GitLab instance, I find myself pausing to reconsider whether contributing to the project will really be rewarding enough to outweigh the unpleasant experience I'm about to have.

What does VCM stand for?

For a company, I'd recommend self-hosting forgejo (which also has actions), which powers codeberg.

(forgejo started as a fork of gitea)

And the best (maybe?) part in your case is that the CI is based on GH Actions, so you can probably reuse your workflows without the need to adapt them.

* its 7 VPS because we separated the tests by modules and we have 7 major modules. * edit: formatting

Given that GitHub runners are still slow as ever, it actually is a point in our favor even compared to self-hosting on aws etc. However, it makes the value harder to communicate <shrug>.

Is it that egregious?. I read it as they are redistributing the costs. It is in combination dropping the managed runner costs by a good margin and charging for the orchestration infrastructure. The log storage and real time streaming infra isn't free for them (not $84/month/runner expensive perhaps but certainly not cheap )

We don't need to use the orchestration layer at all, even if we want to use rest of the platform, either for orchestration or runners. Github APIs have robust hooks(not charged extra) and third-party services(and self-hostable projects) already provide runners, they will all add the orchestration layer now after this news.

--

Competition is good, free[2] kills competition. Microsoft is the master of doing that with Internet Explorer or Teams today.

Nobody was looking at doing the orchestration layer because Github Actions was good enough at free[1], now the likes of BuildJet, Namespace Labs etc are going to be.

[1] Scheduler issues in Github Actions not withstanding, it was hard to compete against a free product that costs money to build and run.

[2] i.e. bundled into package pricing,

[1]: https://status.codeberg.org/status/codeberg

- charge the same you would pay for the GitHub runners

- you have to factor YOUR server cost also, so self hosted will cost more than the platform option

- you jump to the platform runners and save on servers, sysadmin, DevOps, etc.

And then they grab you by the balls and raise the prices.

Now the playing field is more level, yay. Fun for those who choose to migrate away.

So the question becomes: is $0.002/minute a good price for this. I have never run GitHub Actions, so I am going to assume that experience on other, similar, systems applies.

So if your job takes an hour to build and run though all tests (a bit on the long side, but I have some tests that run for days), then you are going to pay GitHub $.12 for that run. You are probably going to pay significantly more for the compute for running that (especially if you are running on multiple testers simultaneously). So this does not seem to be too bad.

This is probably going to push a lot of people to invest more in parallelizing their workloads, and/or putting them on faster machines in order to reduce the number of minutes they are billed for.

I should note that if you are doing something similar in AWS using SMS (Systems Management Service), that I found that if you are running small jobs on lots of system that the AWS charges can add up very quickly. I had to abandon a monitoring system idea I had for our fleet (~800 systems) because the per-hit cost of just a monitoring ping was $1.84 (I needed a small mount of data from an on-worker process). Running that every 10 minutes was going to be more than $250/day. Writing/running my own monitoring system was much cheaper.

Or shortly summarized: lock in through pricing.

Pretty sure this will explode straight in their faces though. And pretty damn hard.

If you don't want to pay, you'd have to not use GitHub Actions at all, maybe by using their API to test new commits and PRs and mark them as failed or passed.

They don't care about people actually self-hosting. They care about people "self hosting" with these guys:

https://github.com/neysofu/awesome-github-actions-runners

Anyway, GitHub actions is a dumpster fire even without this change.

But you (yes, you personally) have to collect the results and publish them to a webpage for me. For free.

Would you make this deal?

the only rational outside rationale is this has the best financial projections, equitability with the customer be damned

gotta make up for those slumping ai sales somehow, amiright?

This isn't aimed at people actually self-hosting; it's aimed at alternative hosted runners providers. See this list

https://github.com/neysofu/awesome-github-actions-runners

It's there a particular reason you're extending the benefit of the doubt here? This seems like the classic playbook of making something free, waiting for people to depend on it, then charging for it, all in order to maximize revenue. Where does the idea that they're really doing this in order to deliver a more valuable service come from?

(plz correct me if i'm wrong)

This feels like one of the big issues that OSS projects might face when migrating to an alternative.

What might a less GitHub centric CI ecosystem look like for OSS community?

For private repositories, each GitHub account gets 2000 free minutes of runtime per month. Both self-hosted runners and GitHub-hosted runners count against that quota.

1. Services like 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.

Jenkins has been rock solid, we are trying to migrate to Argo Workflows/Events, but there are a complaints (like deploying argo workflows with helm, such fun!)

-- Winston Churchill (probably)

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

I think most do. Or at least the infrastructure/compute costs are not coming from their own dept budget anymore ;)

GitHub's log streaming also sucks. It's very laggy and chunked, whereas GitLab's is pretty much real-time.

There are multiple competitors in this space. If you are (or were) paying for Github runners for any reason, you really shouldn't be.

Self-hosted runners help bridge the gap with on-prem servers, since you can pop a runner VM inside your infra and give it the connectivity/permissions to do deployments.

This announcement pisses me off, because it's not something related to abuse/recouping cost, since they could impose limits on free plans or whatever.

This will definitely influence me to ensure all builds/deployments are fully bash/powershell scripted without GH Action-specific steps. Actions are a bit of a dumpster fire anyway, so maybe I'll just go back to TeamCity like I used before Actions.

You can throw tons of cores and ram locally at problems without any licensing costs.

Your data may be local, makes sense to work with it locally.

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.

Earthly did not work out, and dagger had the problem of we support everything but but nothing is great

"Any Network Egress to CircleCI will be charged. At this current time, this includes CircleCI Caches, Workspaces, and Artifacts and will be charged at the normal rate according to your Usage Controls.

The only network traffic that will result in billing is accrued through restoring caches and workspaces, and downloading artifacts to self-hosted runners. Retention of artifacts, workspace, and cache objects will result in billing for storage usage.

Since your builds will not be running on CircleCI's Infrastructure, you will not be charged compute credits"

https://support.circleci.com/hc/en-us/articles/2064321965685...

I think that's fair. In my personal opinion most people started using GitHub Actions because it “came for free with the VCS and/or our MS contract” and it was “good enough for the job”. Now might be a good time to look around at the alternatives again. There is a reason that f.e. CircleCI is doing fully focused CI/CD for 10+ years and is still going strong. Plenty of businesses don’t want to put all their eggs in one (MS) basket, for all kinds of reasons. I guess today one of these reasons became obvious.

Disclaimer: I work at CircleCI.

However, my experience with GitHub Actions was really poor. Some build that would run perfectly on my local machine and any other servers we have hosted would always time out on GitHub runners. I went back and forth from small runners to large runners and the result was always the same. Then I found that there are third-party companies just offering replacement runners for GitHub Actions at less than half the price for an amazing reliability and cost. It was a night and day difference.

Now... this move by GitHub is almost unbelievable. Charging folks to use their own machines

Given github ran 11.5 billion mins of actions in 2025, and most of them would've been on self-hosted runners, this move makes some sense from their POV.

However, this is still an... interesting... move, especially after bitbucket got all that hate a few weeks ago for doing something similar.

I realise 100% utilisation isn't realistic, but that still sounds very expensive when you're already BYOB.

> 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.

> Hosted Agents > > 2,000 minutes/month

:-o

Now the only alternative is to move builds, CI, etc. off of GitHub's platform entirely, and maybe your source control as well. In other words, a big pain. Github seems to have entered peak encrapification: the point where they openly acknowledge rent-seeking as their product approach, fully deprecating "building the best, most reliable, trustworthy product." Now it's just "Pay us high margins because the effort to migrate off is big and will take too long to break even."

Basically the modern day Heroku business model.

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

(Which, yes, has implications for energy use/climate change too for sure).

It doesn't look like i currently have access to the usage data on any of the lots-of-runners-lots-of-PRs projects I currently work on (which are still probably way less than some large companies).

On my larger organization, we have on average 20 to 30 *active* runners during business hours. Assuming 5 on the off-hours, my napkin math says it comes down to about 10 fully-utilized-runners per month, so about 864$/mo. For the size of my organization that is honestly totally acceptable.

This is assuming 0.002$ per minute of job being actively executed. If it turns out to be 0.002$ per minute of *runner being registered* on the control plane, it would increase quite a bit. We are still using the old HorizontalRunnerAutoscaler with actions-runner-controller, with quite a pool of prewarmed runners idling to pick up a job. It would be a strong reason to use the new RunnerScaleSet (to take advantage of the reactive webhook-based scaling) and keep a very lean pool of prewarmed runners.