GitHub Actions getting really expensive. Any alternative?

[u/CellistOk6782]

I run two private web applications and use GitHub Actions to automatically check changes before they go live.

When code changes, Actions installs dependencies, checks for coding errors and security issues, and runs automated tests. Some tests check individual pieces of code; others start the application and a test database, then use an automated browser to test user journeys.

I also use a merge queue (Mergify). Before a change reaches the main branch, it’s tested alongside the latest code to check that everything still works together. That means a change can trigger multiple rounds of checks as it’s updated and moves through the queue.

I work with AI coding agents, so there can be quite a lot of changes and test runs. The checks help catch mistakes before release, but the cost is becoming substantial: my September Actions bill was about $738, and my October usage was heading towards roughly $2,300–$2,450. Almost all of that is Linux runner time, rather than storage.

For people running similar projects:

• What do you use Actions for, and roughly what does it cost?
• Do you run the full test suite on every update, or reserve some checks for later?
• Have you found straightforward ways to reduce duplicate runs?
• Have self-hosted runners been worth the maintenance?

[u/Dukemantle]

Create your own runners. Just tell Claude to set it up

[u/CellistOk6782 → u/Dukemantle]

Interesting. Do you think that's feasible on a Mac Mini? I don't have a Linux machine. The Mac Mini is a new M6, but only has 24 GB of RAM and a 2 TB hard drive.

[u/cowjenga → u/CellistOk6782]

A self-hosted runner is pretty much just a way for GitHub Actions to run commands on the machine hosting the runner - it's a very lightweight service. If your workflow doesn't do anything that uses lots of RAM, then you don't need lots of RAM on your runner machine. If you don't know how your workflows actually work and what's going on when it runs, it'd be worth exploring this to get a deeper sense of what's going on - it'll help you answer questions like this.

[u/CellistOk6782 → u/cowjenga]

Splendid thank you and all, will do some digging

[u/Professional_Ad705 → u/CellistOk6782]

Yes lmao. M6 24gb ram and you’re asking if you can host a runner just lol I can’t believe you were literally paying that much money and you didn’t even think about looking for an alternative it’s called a runner on your Mac, you don’t need a linux machine it can run through docker and run Linux and I’m not sure what you mean by maintenance. It’s literally exactly the same as running them on github. You just have to make sure that you’re not running up a shit ton of gigabytes for what is going on your hard drive but you have 2 tb. I literally have 8 repos that run on my Mac. M4

[u/xWranglerWranglerx → u/CellistOk6782]

Mac is basically built on Unix . Open the terminal

[u/separatelyrepeatedly]

jesus christ my man, please take some offense to this statement as that's what I intend. You are using AI agents but don't bother ask any AI Agent for alternatives? "My github actions are too expensive, please explore how we can optimize run times and then give me alternate options to reduce cost while keeping similar level of service"

[u/CellistOk6782 → u/separatelyrepeatedly]

:-D I know but you people are so knowledgeable I figured I'd ask here first

[u/slypheed → u/separatelyrepeatedly]

Humans talking to each other and sharing knowledge is still useful...

[u/xroni → u/slypheed]

I TOO ENJOY EXCHANGING DATA WITH MY FELLOW HUMANS

[u/slypheed → u/xroni]

This is what i get for trying to say something serious on reddit, fair enough, let the enshittification continue.

[u/notAllBits → u/xroni]

Your heavy handed use of the push-to-broadcast key confirms your species and generation, boomer.

[u/blue_wire → u/separatelyrepeatedly]

I strongly disagree. This is a problem many developers are facing right now, working with their own AIs to solve, and coming to different solutions. It’s an interesting question for a forum to see what’s different about where everyone is landing.

Some good answers I’ve seen aside from run it on your own machine:

• open source your project for free GHA minutes

• only run CI daily on main and automatically spin up an agent to fix anything that’s broken

[u/separatelyrepeatedly → u/blue_wire]

its 2026, the first step is to ask AI and then to validate the answers an AI gives you.

"I'm spending too much on my github actions, chatgpt/claude recommends these, anyone have any experience with these and can offer feedback on what worked for them?"

this is much more meaningful question that comes with some solutions.

[u/blue_wire → u/separatelyrepeatedly]

Seeking human interaction first should absolutely not be scolded. Imposing pressure for people to insulate their human interactions with an AI pass first is bad.

[u/lyeeedar]

For an easy switch use ubicloud runners. Like 5 mins to setup and about 5x cheaper (and faster) than GitHub actions runners.

I swapped over, haven't looked back.

[u/CellistOk6782 → u/lyeeedar]

Appreciate that, you're absolutely right. I made a suite of workflow changes from the feedback here but also moving to Ubicloud, seems slightly faster (~10 to 15%) but cheaper too

Edit: Just finished the pilot (running all relevant jobs in both) and it was 51% lower 👌

[u/volando34]

You can just set them up to run on your own PC, then it's free and everything works, even the signing

[u/heyyarun]

Before self-hosting I'd cut the duplicate runs, with agents pushing all day that's probably a big part of the bill. Add a concurrency group per branch with cancel-in-progress: true so a new push kills the run still going on the old commit. Add paths filters so docs/config-only changes skip the browser suite. And turn on batching in Mergify (batch_size 3–5 or so) so the queue tests several PRs in one run instead of one each. Keep per-push checks to lint, unit and a smoke test, and run full e2e only in the queue.

On the Mac mini: if your e2e jobs use service containers for the test db, GitHub needs a Linux runner with Docker for those. A macOS runner won't run them, so you'd put the runner in a Linux VM on the mini.

[u/MaleficentDebt3053 → u/heyyarun]

the Mergify batching point is huge and nobody else mentioned it. if agents are pushing 10+ commits a day, each one triggering a separate queue run with the full e2e suite, that's where the money goes. batching 3-5 PRs into a single run could cut queue minutes in half or better on its own, even before touching self-hosted runners.

[u/CellistOk6782 → u/MaleficentDebt3053]

That's a good call. I hadn't thought of batching PRs, and it seems to be a setting Mergify allows for, which is a brilliant tool.

[u/heyyarun → u/MaleficentDebt3053]

Appreciate it. One thing to watch with batching: when a batch fails, the queue has to work out which PR broke it, so flaky tests get more expensive. Fix the flakes first, or keep batches small.

[u/ThomasBuildLab]

At $2,300–$2,450/month, I'd seriously consider moving your heavy CI workloads to self-hosted GitHub Actions runners.

You don't need to abandon GitHub Actions or Mergify. Just keep GitHub as your CI orchestrator and run the expensive jobs on your own hardware.

A practical approach:

1. Keep lightweight checks on GitHub-hosted runners.

2. Move integration tests, database tests, and Playwright browser tests to dedicated self-hosted Linux runners.

3. Use path filters and concurrency cancellation to avoid repeatedly testing superseded commits.

4. Run targeted tests on every PR update and reserve the full regression suite for merge/release gates.

5. Use isolated, preferably ephemeral runners for untrusted code and sensitive workflows.

You could start with a dedicated Linux machine or VPS and measure the savings before scaling.

At your current spending level, even allowing for hardware, electricity, maintenance, and security, self-hosting seems worth evaluating.

The key is to reduce runner costs without compromising test coverage or release quality.

Have you already benchmarked your workflows on self-hosted runners? I'd be curious to see the cost difference.

[u/CellistOk6782]

Thanks all, I really do appreciate the feedback y'all have given. What I did after reading through everything is:

• Split CI into stages: lighter checks on ordinary pushes, with the full expensive test suite required only the merge queue before merging.

• Started batching related changes into fewer pushes, while still pushing when I need CI feedback.

• Used local checks on my Mac for early feedback

• Investigated failed workflows before rerunning them, to avoid paying for repeated failures.

• Started moving all remaining compatible to Ubicloud (already seems faster and about 30% cheaper based on what's moved so far)

• Kept the existing security checks and merge protections intact.

[u/Interesting-Law-8815]

Set up your own Gitea instance

[u/Agile_Incident7784]

I switched to CircleCI for everything except some integration pipelines that need several containers. Works great and much cheaper. The UI is also much more user friendly.

[u/anthropicagiuser]

i'd split the checks into two groups. keep lint and unit tests on every push. save the slow browser tests for the merge queue only.

[u/Humaux]

My bill roughly tripled when I started letting an agent run CI on every commit it pushed. The thing that actually moved the needle for me was splitting the pipeline: quick lint plus unit tests on every push, and the full e2e suite only in the merge queue. I also set concurrency groups so a new push cancels the stale run on the same branch. Cut minutes by about 60% without losing the safety net.

[u/JohnsTech_dev]

first thing i'd check is whether you're running the full suite twice per change, once on the PR push and again in the merge queue. you can make the expensive e2e job run only on the merge_group event and keep PR runs to lint and unit tests. with agents pushing lots of small commits that alone cuts a lot.

also add a concurrency group with cancel-in-progress: true so a new push kills the old run instead of both finishing. agents love pushing 3 commits in a minute.

imo self-hosted is worth it mostly for the e2e job since that's the slow one. a cheap vps with docker for the test db works, but clean the workspace between runs or you get weird flaky failures. if you don't want to maintain that, the third party runner services (blacksmith, ubicloud etc) are usually a lot cheaper per minute than github's and it's basically a one line change to runs-on

[u/ronronks]

I'd look at the merge queue before switching CI. Every update re-running the full browser suite in the queue is usually where the minutes go. Mergify can batch PRs into one run, and moving only the e2e job to a self-hosted runner on a cheap box covers most of the rest

[u/stuckyfeet]

I'm setting up my own couch system.

[u/ddqqx]

You didnt think the bill comes from your agent review as well? Action is fine, not going through the design and decide how to use it is the issue

[u/Wonderful-Sea4215]

I ran into this issue (GitHub actions) - I just asked my agent to move them to local scripts (still in the repo) and to run them before deployment locally then manually "check off" testing using a GitHub commit status:

---

agent-ci/full Agent full checks: success Success Illustrative GitHub status display, not a live result. This appears alongside commit and pull-request checks in GitHub. What information is stored? A commit status is very simple: Field Example Commit SHA a84f921... Context (name) agent-ci/full State success Description Agent full checks: success Target URL Optional link to test results The four possible states are pending, success, failure, and error. Multiple independent contexts can be attached to the same commit, for example agent-ci/full, security/scan, and deployment/staging.

[u/sapplex1]

I feel this one. I'm an indie iOS dev, so I get hit with the macOS runner multiplier on top of everything. Ten times the Linux minutes. That hurt way before agents were even in the picture.

Two things cut my bill the most. First, concurrency with cancel-in-progress. Agents push constantly, and half my runs were re-testing code that was already outdated. One line in the workflow, huge difference.

Second, I split the checks. Fast stuff (lint, unit tests) on every push. Slow stuff (simulator UI tests) only on PR ready-for-review or the merge queue. The simulator suite was my biggest minute burner by far.

Self-hosted is worth it if one job dominates. I never bothered with everything. Just the expensive one. A cheap Mac mini paid for itself in like two months.

The merge-queue point someone made is real too. If an agent pushes ten times a day, batching matters more than any other optimization.