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

[guidestaramb-lgtm]

My opinion is that re -evaluating the efficiency and effectively manage equity for customer services and sales cloud engagement usage is being updated

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

[dubsalot]

Self-hosted should NEVER be billed by minutes or count against "actions minutes"

💯

I agree with another poster as well - the cost of the control plane / the actions queue should be included in the cost of our enterprise.

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

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

[chemaper]

Sorry, but this is not only a issue with OSS projects. BTW, OSS projects have other alternatives like forgejo. "Your enterprise accounts can afford it": you must be kidding. It is not a financial problem for Github that some OSS projects choose another free alternatives. It will be a financial problem for Github that their big paying customers were unhappy.

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

[fowl2]

Some alignment here with AzureDevOps would make sense - eg. including an equal amount of self hosted runners for each "pro" or enterprise user.

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

[laodongAI]

Recently, while using the GitHub Copilot service, I encountered severe unauthorized overcharging issues: there is a stark discrepancy between my actual usage amount and the deducted amount on the bill, with obvious excessive charges applied to my account.
In response to this billing problem, I submitted an official support ticket one month ago (Ticket No.: [Fill in your ticket number here]). However, to this day, no staff member has taken the initiative to contact me to communicate the situation, nor have I received any form of progress update.
Billing issues directly relate to users' property rights and interests, and are among the most critical core problems in platform services. As a globally renowned large tech enterprise, GitHub has turned a blind eye to such crucial user demands for over a month, and its abysmal work efficiency is shocking.
This disregard for users' core rights is not only irresponsible to users, but also exposes severe internal management chaos within the platform — the ticket handling process is a mere formality, and the user feedback channel is completely ineffective. In the long run, an enterprise lacking a sense of responsibility is destined to fail to win long-term trust from users.
Here, I strongly demand that the GitHub official team:
Immediately verify the detailed records of the unauthorized charges on my account and refund all overcharged amounts in full;
Assign a dedicated staff member to take over my ticket and provide a clear timeline for resolution;
Publicly explain the root cause of this incident, optimize the ticket handling mechanism, and prevent similar problems from recurring.

[samus-aran]

Hi @laodongAI

The community is unable to assist with nor escalate your ticket. It will be answered in the order it was received based on our support team's resources and the amount of tickets ahead of yours. We appreciate your understanding! In the future, please only open 1 ticket per incident.

No other Community Discussions team members will be able to provide additional help with account related questions.

[sophiasmithastri]

Many teams rely on self-hosted runners for security and predictable builds, so a surprise pricing shift can break planning fast. If you move forward later, please publish a clear cost model, real examples, and a longer notice period.

[macintoshplus]

For security reasons, self-hosted runners must be used on private code repositories. We use private runners to build software on a volunteer basis. If we have to pay for private runners, we will have to make the difficult choice of shutting everything down or migrating elsewhere, which will incur a cost we cannot afford.

Charging for minutes on private runners is unacceptable for nonprofits.

[MrSuddenJoy]

Charging for minutes on private runners is unacceptable for nonprofits.

@macintoshplus +1. Especially for not so well-established/popular ones.

[xenoterracide]

I feel the need to point out here the not-for-profit does not mean charity... I'm not again yours by any means. Even charities do not necessarily mean that the company does not make enough money to pay for something like this. Again I'm not scrutinizing your specific situation.

If You're currently a public project it would appear that they're not raising rates.

If you're working for a charity have you considered opening the code up for everybody? AGPL and SSPL will pretty consistently discourage corporations from stealing it. There are a few other licenses that you might consider for non-stealing too if that is the concern (I think there's an alternate to creative Commons non-commercial somewhere I would have to look at the list of non-open source licenses again)

[macintoshplus]

In my case this is more of charity. I don't charge users who download binaries made with private workers. The source code I'm compiling is already available in open source. The peculiarity is to compile this source code for Windows.

I need a private worker to be able to debug failed compilations.

[dukxamin-beep]

For security reasons, self-hosted runners must be used on private code repositories. We use private runners to build software on a volunteer basis. If we have to pay for private runners, we will have to make the difficult choice of shutting everything down or migrating elsewhere, which will incur a cost we cannot afford.

Charging for minutes on private runners is unacceptable for nonprofits.

[dukxamin-beep]

For security reasons, self-hosted runners must be used on private code repositories. We use private runners to build software on a volunteer basis. If we have to pay for private runners, we will have to make the difficult choice of shutting everything down or migrating elsewhere, which will incur a cost we cannot afford.

Charging for minutes on private runners is unacceptable for nonprofits.

[xenoterracide]

I think you should add a feature that when somebody goes to merge I can kick off a job against the merge that will happen before the merge actually happens. Git itself has a hook for this. The reason though for adding this is that I for example have a fairly expensive job that right now I run on PR's once the pr is not in draft state. The reality is that it really only needs to run before the pr is merged into the default branch. Meaning I can run it a lot less if you would give me the facilities to do so and this would benefit both of us.

[WyriHaximus]

You can probably do by only triggering on approvals for the expensive jobs: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_review

[xenoterracide]

this would require me to do more intervention than I'd like, kind of... but I'll be honest, I kind of remember that GitHub has this feature (or something similar) and it's gated behind paying customers... I'm a free customer and sounds like I'll continue to be... but they could reduce their costs if they wanted to. This feature is also gate-kept on GitLab behind paying accounts. Really this feature is... please support and respect https://git-scm.com/docs/githooks#_pre_merge_commit on the server side.

[AlanGreene]

Sounds like you're looking for merge queues. You can configure workflows to run when the PR is added to the merge queue, and it will automatically get merged after the required checks pass.

[xenoterracide]

Pull request merge queues are available in any public repository owned by an organization, or in private repositories owned by organizations using GitHub Enterprise Cloud.

basically... but my point is that it's a gatekeeper feature to reduce people's usage, where it would be useful even for non-orgs to reduce workflow usage.

[AJMTSolutions-Admin]

Never add pricing for this. Keep it as is if thats what it takes. I pay for the hardware, and labor to config.

[allyunion]

"We have real costs in running the Actions control plane"

So, the solution should be to give us the ability to run our own Actions control plane and have us run the necessary infrastructure, than you charging us extra for it.

If GitHub wants to charge customers for the Actions control plane on top of self-hosted runners, then customers should have a path to run or self-manage that control plane themselves rather than being forced to pay GitHub for orchestration over infrastructure they already host.

[naikrovek]

that doesn't make sense, really. the control plane is what accepts the event that happens when a workflow is triggered. If you say "so fire off a webhook" then think about what must be listening to know when to fire the webhook. that thing that is listening is the control plane.

It might work in the case of a workflow_dispatch event, to simply fire a webhook, but there are many other events which trigger workflows, and most of them need to be internal to GitHub in order to work.

They can't just externalize that control plane to end users.

[armeensp-hash]

that doesn't make sense, really. the control plane is what accepts the event that happens when a workflow is triggered. If you say "so fire off a webhook" then think about what must be listening to know when to fire the webhook. that thing that is listening is the control plane.

It might work in the case of a workflow_dispatch event, to simply fire a webhook, but there are many other events which trigger workflows, and most of them need to be internal to GitHub in order to work.

They can't just externalize that control plane to end users.

[MrSuddenJoy]

@armeensp-hash what is that you were trying to say? You just quoted someone's else post.

[v-coder247]

Hi @anakinCode9, thanks for being a part of the GitHub Community!

In our Community Code of Conduct, we ask that members contribute in a positive and constructive way. This type of post is considered "off topic" as GitHub Community Discussions focuses primarily on topics related to GitHub itself or collaboration on project development and ideas. Any repeat and future violations may result in a temporary or indefinite block from the Community.

We appreciate your understanding.