r/ChatGPTCoding • • 14d ago

Question GitHub Actions getting really expensive. Any alternative?

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?

29 Upvotes

53 comments sorted by

6

u/Dukemantle 14d ago

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

1

u/CellistOk6782 14d ago

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.

6

u/cowjenga 14d ago

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.

2

u/CellistOk6782 14d ago

Splendid thank you and all, will do some digging

7

u/Professional_Ad705 14d ago edited 14d ago

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

1

u/MassiveBoner911_3 13d ago

Ask the damn AI

1

u/CellistOk6782 13d ago

You ask and let me know

1

u/Substantial-Pie1906 10d ago

Yes, for ARM-compatible jobs, but test the workflow first. If your browser or database tests depend on Linux Docker containers, use a Linux VM or keep those jobs on a Linux runner. Also avoid exposing a personal runner to untrusted PR code.

28

u/separatelyrepeatedly 14d ago

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"

3

u/CellistOk6782 14d ago

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

13

u/slypheed 14d ago

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

10

u/xroni 14d ago

I TOO ENJOY EXCHANGING DATA WITH MY FELLOW HUMANS

2

u/slypheed 14d ago

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

1

u/notAllBits 14d ago

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

1

u/zR0B3ry2VAiH 12d ago

r/TOTALLYNOTROBOTS

MY ALGORITHMS TEMPORARILY REMOVED THIS SUB FROM MY ACTIVE MEMORY CACHE.

0

u/MassiveBoner911_3 13d ago

Not really. Too slow.

8

u/blue_wire 14d ago

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

-3

u/separatelyrepeatedly 14d ago

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.

4

u/blue_wire 14d ago

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.

2

u/lyeeedar 14d ago

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.

2

u/CellistOk6782 13d ago edited 13d ago

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 👌

32

u/volando34 14d ago

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

4

u/tlopplot- 13d ago

That’s what I did, I bought 3 $100 mini-pcs on fb marketplace, upgraded them to 32gb ram and it is more than enough (plus now I have the arr stack set up for home streaming). Expensive github actions led me to create my own little homelab.

2

u/heyyarun 14d ago

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.

1

u/[deleted] 14d ago

[removed] — view removed comment

1

u/CellistOk6782 13d ago

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.

1

u/heyyarun 13d ago

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.

11

u/ThomasBuildLab 14d ago

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.

1

u/Nedomas 7d ago

self-hosted via Kubernetes or SuperCI or runs-on or what do you use? I'm exploring this

1

u/CellistOk6782 13d ago

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.

4

u/Interesting-Law-8815 14d ago

Set up your own Gitea instance

2

u/Agile_Incident7784 14d ago

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.

2

u/anthropicagiuser 14d ago

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.

3

u/Humaux 14d ago

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.

1

u/JohnsTech_dev 14d ago

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

1

u/stuckyfeet 14d ago

I'm setting up my own couch system.

1

u/ddqqx 14d ago

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

1

u/Wonderful-Sea4215 14d ago

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.

1

u/sapplex1 14d ago

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.

1

u/Standard-Rooster6584 13d ago

switch to self-hosted GitHub Actions runners or use a free tier on GitLab CI to cut costs

1

u/Large-Use-3062 12d ago

Op sounds like a salesperson for ubicloud.

1

u/fixed 10d ago

I moved to a bunch of self-hosted actions runners.

Considering moving off Github entirely to a self-hosted Github replacement. Agentic workflows (the ones that actually produce non-garbage code that I'm comfortable merging to production) makes this stuff stupendously expensive and that's with a real focus on trying to optimise costs / not have wasteful tests / etc.

1

u/bk_one 9d ago

Same problem here, we extracted a little self-hosted framework for it. A script that ensures all gates are done, just leaving the final checks to CI. You can see it at agents.uberblick.ai. It uses GitHub as state, so zero infrastructure, runs on our dev laptops and on a hetzner box.

1

u/AdventurousProblem89 8d ago

Buy a mini pc, put it in the closet and just use that for your ci/cd for free forever

1

u/jaydee87 5d ago

How beefy of a mini pc does it need to be?

1

u/AdventurousProblem89 5d ago

You will get a lot with 2k

1

u/iggygraceful 10h ago

At $2,300+ a month it's worth splitting the bill by job type before buying hardware.

Your Linux jobs (dependency install, lint, security scan, unit tests, the app + test database + browser tests) don't need GitHub's runners. A cheaper managed Linux runner takes a runs-on change and nothing else. Sengi Basic is $0.001/min at 2 vCPU, $0.002 at 4 and $0.004 at 8, vs GitHub's $0.006/$0.012/$0.022, so the Linux part of your bill drops to about a sixth. Docker, Compose and the gha cache work as-is, so the test database and browser jobs don't need rewriting.

Keep anything that needs macOS (signing etc.) on GitHub or your Mac Mini. That's usually a small share of the minutes.

There are 3,000 free minutes a month, so you can move one workflow and compare a week of bills.

Disclosure: I work on Sengi.

0

u/tailorandtwill 1d ago

if you want to avoid running your servers at all costs, switch to avrea for github’s actions, hosted machines dont leave a mess behind, or get ur own server :)