Updates to GitHub Actions pricing

We’ve read your posts and heard your feedback from our announcement, Pricing changes for GitHub Actions.

1. We’re postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach.
2. We are continuing to reduce hosted-runners prices by up to 39% on January 1, 2026.

We have real costs in running the Actions control plane. We are also making investments into self-hosted runners so they work at scale in customer environments, particularly for complex enterprise scenarios. While this context matters, we missed the mark with this change by not including more of you in our planning.

We need to improve GitHub Actions. We’re taking more time to meet and listen closely to developers, customers, and partners to start. We’ve also opened a discussion to collect more direct feedback and will use that feedback to inform the GitHub Actions roadmap. We’re working hard to earn your trust through consistent delivery across GitHub Actions and the entire platform.

We're here to listen.

[fkorotkov]

Please address this issue actions/runner#620. This is by far the number one issue to properly auto-scale ephemeral runners at scale for operators like us.

[crohr]

That, or make the check run id available in the github context in workflow files so we can generate unique labels.

[h0lybyte]

Yeah, checks the date oh my, 5 years ago? nice.

[tedivm]

You can find all sorts of stuff in there- they're been so neglectful of the self hosted actions that it's embarrassing they're trying to charge for it.

They don't release containers that match the runners on the public at all. They don't handle proper rootless docker-in-docker. All issues that have come up repeatedly.

If they want to charge for things fine, but actually provide a service that doesn't require your users doing 90% of the work.

[cquanu]

Thanks for listening

[brtkwr]

Make your runners competitive vs customers hosting their own self-hosted runners.

Don't charge them the same per minute price as your own runners, that is just anti-competitive.

We are already paying for the privilege of using the "control plane" by paying for our Github accounts.

[fproulx-boostsecurity]

Well it’s still variable cost. Control plane is not free either. But definitely the pricing model they announced was not correct. They need a generous 0 cost control plane for self hosted that cover 80% of folks and then the rest needs to be billed not by the minute. More aligned with what it really costs since it’s not compute it’s mostly ingesting the logs which could be insane I’m sure people are dumbing gigabytes of junk ….

[mecaota]

I understand that it's a variable cost, but I can't accept that it's the same price as our company's minimum configuration runner. They should at least lower the price. Why should I pay a higher price for platform usage than AWS CodeBuild?

[MatthewAry]

The billing unit for self-hosted shouldn't be time based at all. The truth is that any dev with experience in systems engineering should know that while there are fixed overheads (not accounting for long-lived connections) for any given job being tracked, there are parts that are highly variable which are mostly a product of how "chatty" a runner is. We could make it so runners emit very few logs and yet under what's now the proposed billing model, it grossly simplifies these important differences.

If you have to charge, then this is how I think it should work:

• Self-hosted should NEVER be billed by minutes or count against "actions minutes"
• Self-hosted should have it's own quotas with caveats that could lead to additional charges:
  • Action runs excessively long (12 hrs?)
  • Log volume quotas per action

Something like this ☝️

Developers aren't dumb! You know this. That's why you got this reaction. The proposed billing model seemed unfair and didn't make any sense.

[andresvillenas]

Thanks for listening👂

[bhswilson]

Appreciate that you are "postponing" what appears to be a foregone conclusion, giving us time to get our own plans in order.

However,

1. We already pay for the control plane, to the tune of thousands of dollars.
2. Penalizing us for running actions self-hosted because you are unwilling to sign the necessary compliance contracts is a you problem and not an us problem and not something for which we should have to pay extra.

[RohovDmytro]

Whatever the overhead, it does not cost 0.002 cents per each minute. Also, it fully breaks the real quality solutions in the ecosystem. This is something to highlight.

[ThadHouse]

The biggest issue we had with the per minute is we are a volunteer organization and are using donated self hosted hardware to run our builds. This hardware was generally a few years old and slower. The new billing made it so that running older hardware was not feasible at all, since slower builds directly result in higher costs. Essentially telling us we need top of the line hardware in order to reduce our GitHub costs, which seemed backwards to me compared to a cost per run build.

[bhswilson]

I wouldn't characterize the hosted runners as "top of the line", either.

[ThadHouse]

No, but to make the most use of the cost per minute for self hosted runners, you would need to self host top of the line hardware. Slower and older hardware has very direct costs when runs cost per minute.

Basically was actions saying if you want to self host, you better not be self hosting old hardware. Because users using that are going to get fleeced.

We'd actually love to just use the GitHub runners for our private project. 99% of our code is open source and we're happy with actions and the speed. We just have 1 private project, and it's not feasible to pay for the runners in the private repo.

[JC3]

Thanks for listening. I would accept a flat cost per job over a per minute cost. Id also like to see some benefits for Pro members.

[adiologydev]

This is a welcome update. I understand that even though we run actions on our own hardware, the logs and other artifacts are still stored on GitHub's infrastructure.

There are two ways that I can think of going about this:

1. Let us retain those logs and artifacts on our own infrastructure OR
2. Let the users opt-in for longer retention (for a reasonable cost), and make the default retention limited to N number of action runs or N number of days (free as it currently is).

This is just a quick thought, but I'm sure the community and GitHub team can come up with something that will work out for everyone in the end.

[thejhh]

There are already extra costs for storage. That should not be the reason for this fee.

[adiologydev]

There are already extra costs for storage. That should not be the reason for this fee.

I am not sure if that contains log retention for actions.

[abhi1693]

Logs do cost extra already. We had to shorten the retention of logs to not get a huge bill

[adiologydev]

Logs do cost extra already. We had to shorten the retention of logs to not get a huge bill

Well in that case, this whole plan was extremely uncalled for. I'm hoping this backlash makes them realise what not to do moving forward.

[alexg-sh]

good boy

[naikrovek]

thumbs down because you are not in control of the situation and github is not your pet. i disagreed with the pricing but this response to this post is just a straight asshole move. if i could ban you from discussions on github, i would.

[overlook21]

Last update on actions/actions-runner-controller#2796 (comment)

The product owner made a bunch of promises the team never delivered on then the discussion mysteriously vanished off the face of the planet.

I suppose the purpose of this discussion is the same?

[ahatzz11]

multi-label support was announced as an upcoming feature as part of the pricing update: github/roadmap#1195

source

[overlook21]

So it really was a cash grab from the beginning, starting with the acquisition of the actions runner controller open source project.

Embrace, "extend", extinguish right?

[surgiie]

I sure hope they give this as much attention as they plan to do for the runner.

[molson504x]

I think the original announcement was kind of tone-deaf, disorganized, and it felt like it took away a huge part of why so many developers come to GitHub - because it is a developer-first and OSS-first platform. A lot of OSS projects don't have funding, which is why it's AWESOME that GitHub offers a place to host code for free, and offers so many cool tools to developers.

I think the negative reaction to the announcement was because the only justification that was made was "we're doing it to reduce the cost of GitHub hosted runners" and it never really said the truth - that a lot of organizations HAVE TO use self-hosted runners due to compliance and privacy reasons. Oh, and they do pay quite a bit to use the GH platform already.

Had the announcement said "guys this is a hella expensive feature to run even if the runners aren't run on our compute" and spelled it out, it would have made a lot more sense. Luckily, I had a hubber who I could reach out to who was able to provide that info to me.

As someone who works with a lot of enterprise customers, two recommendations for when you do this in the future:

1. BE TRANSPARENT. It's why we liked GitHub to begin with, and it's something that GH has been moving away from lately it seems........
2. Maybe start with your larger enterprise customers first, not your smaller OSS partners or free accounts. Your enterprise accounts can afford it. I've done the math with a few of mine, and it comes out to a very minimal amount of Operational Expense for them in the grand scheme of things. Your for-profit customers can afford the op-ex. Your not-for-profit customers or non-business customers probably shouldn't incur that cost. Odds are if they are running their own hardware to run actions they're doing it for a reason.

Thanks for everything that you, Hubbers, do! We appreciate you, even when we don't tell you.

[denysvitali]

It's good that you're doing damage control after the backlash, but I think for most of us the trust is already broken. Especially since you considered it to be a good thing to introduce the pricing change without even checking with the community whether this was a reasonable choice.

Aside from the pricing change, GH Actions is not a "premium service" that is even worth paying for. The "control plane" suffers from multiple issues (see recent problems about broker / backend problems not relaying the messages) and the GH Actions ecosystem is broken in so many ways (e.g: safe_sleep).

Personally, I'll switch to Woodpecker CI (again!) and move my repositories elsewhere. GitHub is introducing constant changes that are just harmful for their users.

I was also once a happy GitHub Copilot customer, but you ended up destroying another good product.
Whoever is calling the shots at GitHub should IMHO step down - you're ruining the company.

[intellix]

I know a company that literally just transitioned from Gitlab to Github and it's like boom one month later, another $1.8k/mo please

[eslym]

I want to highlight an issue specifically for small teams and individual developers.
Many of us run self-hosted runners because we have idle hardware and we want to avoid burning through the plan’s included minutes (e.g., 2,000 minutes on Free), which can otherwise stall development when CI triggers frequently.
If self-hosted usage shares the same included minutes pool as GitHub-hosted runners, then self-hosted loses a key purpose for us and becomes effectively meaningless as a way to keep CI unblocked.

Please consider a separate monthly free allowance for self-hosted runners (at least for Free/Pro/Team), or a model where self-hosted does not consume the same included minutes pool.
Also, could you provide more transparency on how the $0.002/min “cloud platform” fee was derived (main cost drivers, what’s included/excluded, and whether there will be tiers/discounts)?

[ikemo3]

I agree with this concern.

I'm an individual developer on the Pro plan, but the included minutes aren't sufficient for my needs, so I separately contract with Ubicloud. Ubicloud is 1/10th the price of GitHub Actions (before this change), but if this additional charge is applied, the total cost becomes 3.5x higher. (In other words, I'd be paying GitHub 2.5x more than Ubicloud!)

This is not justified as fair compensation. It's essentially creating a toll gate.

At minimum, per-minute billing for this is the wrong approach.

[andreaswittig]

Up until now, GitHub charged per user. The ecosystem adapted to that pricing model. Adding a new pricing dimension causes a lot of friction for the ecosystem. That's the reason for the backslash, IMHO.

[vwnj84]

It was really terrible from an Enterprise standpoint, because budgets are already set for different departments and development teams. They were told that all they needed to pay for was their infrastructure, not the scheduler, since that's a huge part of what they're already paying for with their per-person Enterprise license.

Then this was announced, and suddenly here at the end of the year, we get to tell everyone that's already scraping for pennies that there is now an additional unbudgeted cost. And then it's 'postponed' two days after the announcement and managers are flipping out that they cannot budget around this madness. I don't blame them.

[daztucker]

I have described elsewhere[0] the impact this would have on OpenSSH, but in brief:

1. our tests are fairly extensive and slow.
2. we have a significant number of tests on selfhosted runners, mostly covering platforms and hardware Github does not have.
3. the selfhosted runners are on a private repo, because Github's own documentation[1] strongly recommends against putting selfhosted runners on public repos for security reasons: "As a result, self-hosted runners should almost never be used for public repositories on GitHub, because any user can open pull requests against the repository and compromise the environment."
4. we can't make the repo public without incurring significant risk, since pull requests cannot be permanently disabled on a repo[2]

The last test run used an aggregate of about 3100 runner-minutes on the selfhosted runners, which in the original proposal would be about US$6.33 in costs per git push. If this proceeds as originally stated, we will be left with several unpleasant options: incur a significant cost, abandon our test coverage, expose ourselves to significantly more risk or migrate to another platform.

The original proposal said self-hosted runners remain free as long as you run them on public repos, but you also say you shouldn't do because it's unsafe, unless you can disable pull requests, which you probably can't.

[0] https://infosec.exchange/@daztucker/115734496888878255
[1] https://docs.github.com/en/actions/reference/security/secure-use#hardening-for-self-hosted-runners
[2] https://github.com/orgs/community/discussions/8907#discussioncomment-15274831

[42atomys]

Basic but honest for me:
if the main issue are We have real costs in running the Actions control plane :

• Turn the action control plane into a self-hostable engine sending/exchanging direct informations to Github Action UI. That reduce your "real costs" and let any people self-host the integral stack

[xinsight]

But of course, they'll never do that, because the "real costs" is a bogus argument.

Customers have the real costs when you use 1 second and get billed for 60 seconds.

[Vertexwahn]

The other end of the spectrum is also problematic - if your job runs 1000 minutes, the control pane has almost the same effort as for a 1-second job if there is no heavy logging involved...

[vleeuwenmenno]

Then why don't they charge a fixed amount for people who start a self-hosted runner job? That seems to make more sense anyway.

[Vertexwahn]

forgejo also provides runners (example: https://codeberg.org/jiji-wp/daph/actions/runs/26/jobs/0/attempt/1) - will create a mirror of my repo and play arround a bit with it - at least for Ubuntu CI jobs I think I can migrate easily...

[shivaraj-arch]

A small url fetch for a govt website fails in GitHub actions if those websites have blocked outside IPs and requests. And most countries do that for cybersecurity. Computes and IPs are localised to US and neighbours in github. Need choice of localised IPs for moderate loads in rest of world. Else again run for VPNs which again are localised in and around US and EU.

[pilif]

Our gripes with the self-hosted runners:

• make them better platform citizens. Ship proper OS packages, take configuration from a central config file
• publish the images used by the official runners. It's too hard to build the images to bring up custom runner VMs that work the same as the official GH images
• fix actions/cache so it can work with a cache server running in the same network as the self-hosted runners make the cache server configurable as part of the runner config.

All of these points we kinda lived with and/or used workarounds because we were aware that you need to provide incentives to use your hosted runners, so it's ok if the self-hosted experience is a bit subpar.

But now that you want to charge for self-hosted runners, they can't be worse than the GH runners. Make it as easy as possible to host and use self-hosted runners and I would actually not be completely averse to paying for them.

[Pospelove]

publish the images used by the official runners
they are public btw https://github.com/actions/runner-images

[robertsa1-els]

We were genuinely taken aback by the short notice for this announcement. Three months into a new year is not much time for an enterprise to secure sign-off for what amounts to thousands of dollars a month in extra cost, especially when there is no additional benefit. We also had no advance warning from our account team, who instead tried to position the change as a positive move towards Hosted Runners, despite knowing we rely on self-hosted runners for compliance reasons and for access to internal services.

The proposed costing model itself does not feel well considered. As an enterprise customer, we already pay for the GitHub Platform as well as for log and artefact storage. While the control plane certainly provides value, it is not a per-minute resource, and its cost should realistically be covered within the existing platform and storage charges. Had there been earlier engagement, I could imagine that a flat per-job fee might have been workable, given enough notice to secure the necessary budget.

I appreciate that using GitHub Code Agent on self-hosted runners removes a potential revenue stream, but again, this is the sort of issue that could have been addressed through proper consultation with customers who are taking this path.

As for the statement that GitHub needs to raise money to invest in the self-hosted platform: this should have been addressed before GitHub took ARC in-house from a community open-source project. It began strongly, but with key developers leaving and so much internal focus shifting towards Copilot, the project has clearly atrophied. PRs have stalled for months, so asking customers to now fund a revival does feel rather cheeky.

We have invested heavily in self-hosted runners and adopted ARC on the understanding that it was an active investment area (I still have the communications to that effect). As a result, we have increasingly felt like second-class citizens, and this announcement only reinforced that.

In future, please ensure account teams engage with customers well ahead of major pricing changes. Early visibility and genuine consultation would help avoid surprises like this and allow both sides to reach a more balanced outcome.

[j-schreiber]

This is pretty ironic, coming from a product team that has a "sleep" function that literally causes max CPU utilization instead of idling the CPU. Basically every runner that is "sleeping" consumes max CPU minutes.

Embrace, enshittify, extinguish, am I right?

[c0inzdotcom]

We started our blacksmith.sh and runs-on.com evals the day GH announced this. We'll be moving away from their runners all together because of this.

We do a quarter million jobs a day on ARC. No way we're paying for the displeasure too

[crohr]

@c0inzdotcom reach out if you need anything, thanks for trying RunsOn ;)

[Quanalogy]

I've been hosting CI solutions on Jenkins for 4 years, gitlab for 4 years and now github for one.

Until now I've used things hosted in the basement combined with cloud for 350 developers and never really had any runner related issues.

Now after a year moving to a new company with github I must say it is one of the most unstable, illogical and bug filled system I have ever used - on top of this you're making us pay to do the hard work of making it work... Really...
I see the EEE of Microsoft in this and it does not bode well for github as a platform.

A part from the sleep issue we've had issues with it not picking up jobs, 4 jobs blocking start of new jobs on a runner with a concurrency of 50 and other crazyness where one must ask if you've ever tried to use your own platform? It is probably the leftovers of azure devops spooking around here.

You write about investing more in windows, but really who is asking for this going into 2026?
My guess is Microsoft and then noone Else.

If you want people to use your hosted runners, go take a look at what gitlab does, I have never regretted putting a single dollar into that solution and they are years ahead of you.

Go make a better solution for runners, make it cheap (like it seems you're trying to) and accessible (which they are) and you'll eventually get there.
However offsetting cost on the self hosting is just insane - should we start to pay pr api request now as well?

I like that you're reaching out but openness have never been githubs strong suit and is one of the reasons I chose gitlab over github a couple of years back.
I hope you'll actually try to listen to the Community for once but this thread shows that it has been neklected for many years so I'm not really counting on it.

[RPGillespie6]

To me it sounds like GitHub (and probably Atlassian, who did something similar recently) are using the wrong money to fund things.

What (it seems like) GitHub is currently doing:

• using the money from cloud actions build minutes to fund the development and maintenance of everything actions related

This creates a conundrum - as soon enough customers migrate to self-hosted, suddenly you don't have enough money to fund actions anymore.

Proposed fix:

• use money from cloud actions build minutes to fund only the cloud actions-related scaling problems (compute, memory, storage, maintenance)
• introduce a new flat fee to monthly bill to fund general actions development and maintenance - this will affect all customers whether they are using self hosted or not, and scales with # of customers.
• Alternatively, depending on how hell-bent GitHub is to squeeze customers, the new fee could instead be a tiered monthly charge that scales based on the number of runners used instead of just the number of customers (i.e. a company that uses 5 self hosted runners would be in a different fee tier than a company that uses 100+ self hosted runners).

Either way, that feels more fair than charging customers by the minute for running stuff on their own hardware. Charging customers by the minute for using their own hardware makes them feel bad; like you are taking their hardware hostage and selling it back 1 minute at a time. This incentivizes throwing away perfectly good computers because they build more slowly (and thus incur more build minutes) vs. a newer one.

This is mainly a psychological "framing" problem. It's like when Blizzard devs originally implemented "exhaustion" in World of Warcraft in order to punish players for playing too long. That made players feel like crap. So instead they changed it so that players got a buff if they took a break. GitHub needs to do the same. Instead of punishing customers who invest time and energy in their own hardware, reward them for not burdening GitHub's cloud infra by allowing them to escape all cloud-related fees (build minutes).

[abo-L]

We’ve read your posts and heard your feedback from our announcement, Pricing changes for GitHub Actions.

1. We’re postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach.
2. We are continuing to reduce hosted-runners prices by up to 39% on January 1, 2026.

We have real costs in running the Actions control plane. We are also making investments into self-hosted runners so they work at scale in customer environments, particularly for complex enterprise scenarios. While this context matters, we missed the mark with this change by not including more of you in our planning.

We need to improve GitHub Actions. We’re taking more time to meet and listen closely to developers, customers, and partners to start. We’ve also opened a discussion to collect more direct feedback and will use that feedback to inform the GitHub Actions roadmap. We’re working hard to earn your trust through consistent delivery across GitHub Actions and the entire platform.

We're here to listen.

Hi @abo-L,

Did you have a comment to add, or are you just quoting the content above? If your comment isn't updated with additional context we're going to mark as unrelated to hide this and keep the thread productive.

Thank you!

[TheCallumInglis]

This feels like a positive and pragmatic decision. While it’s understandable that there are real costs involved in operating and supporting self-hosted runners, those costs are not directly comparable to GitHub-hosted runners. Framing usage in terms of per-minute billing for workloads running on users’ own infrastructure didn’t quite resonate.

A token, job, or invocation-based pricing model would feel more aligned with the value being provided and easier to reason about.

[llbbl]

What GitHub actually provides for self-hosted runners:

1. Job orchestration/queuing
2. Log storage
3. Artifact storage

Of these, only 2 and 3 cost GitHub anything meaningful, and those costs scale with storage, not runner minutes. Charging per-minute for a storage problem is the wrong pricing model entirely.

If GitHub does revisit this:

• Don't charge for self-hosted runner minutes — Enterprises already pay seat licenses
• Offer optional paid tiers for enhanced features (longer retention, observability, data streaming)
• Let users store logs/artifacts on their own infrastructure if storage is the real concern
• Be transparent about actual control plane costs

[Choms]

like other user noted, they are already charging for log and artifact storage

charging per minute for job orchestration is batshit crazy, GitHub's data plane is not costing them more than my actual infra is costing me for the runners...

[dairi256]

I haven't really heard anything about this, but I believe that you shouldn't pay money for self hosting something. If its all on our end, there is no need to pay for using it on our hardware.

[naikrovek]

Generally, I completely agree. I should not have to pay someone to run a virtual machine on my infrastructure using my hardware, my software, and my electricity. But in the case of GitHub runners, it is github.com which keeps track of jobs and which sends your runner jobs to do.

Whether that is worth $0.002/minute or not is up for debate, but the point is that GitHub does spend money on self-hosted runners. Self-hosted runners are a cost for GitHub. How much of a cost? I don't know, only GitHub knows.

[amiqat]

It can be monthly fee, not per minute

[gbarla2]

Honestly I did not understood the rationale of asking us to pay per minute while our own runner are doing the job. Very happy to ear that you are re evaluating your apporach. I would be also happy to discuss the subject with you further.
Thanks

[danra]

My gripe with the price increase for self-hosted runners is attempting to charge a premium for a barely-maintained service:

• The checkout action says in the readme that, while we're welcome to open bugs, fixing them would not be a priority nor would it be receiving contributions. That's despite this action being the most common action which almost any workflow uses.

• Accordingly, Why do I have to pull the lfs separately when using lfs: 'true' actions/checkout#270 has been open for over 5 years now, with people continually being bitten by it and bumping it.

• Checkout bricks a self-hosted runner and cannot recover actions/checkout#1148 has been open for 3 years.

• upload-artifact v3 has been deprecated, even though [bug] v4 hangs uploading from mac runners actions/upload-artifact#527 has been open for 2 years. To GitHub's credit here, a workaround was suggested that seemed to be working, but was later discovered to not fully resolve the issue, yet still v3 is not accessible nor is the v4 issue fixed. (Still, a good word to the actions team that did respond here, but unfortunately with limited resources).

• Given the above, I've found the repeated survey calls to "tell us what you think about actions" over the last couple of years ridiculous at best. Disruptive issues are being reported by users (additional ones mentioned by others above), re-discovered again and again, but receive no response by GitHub.

[amiqat]

Why not take monthly fee not per minute, same as azure devops, not make any sense to fee per minute on customer hardware