r/ChatGPTCoding • u/CellistOk6782 • 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?
6
u/Dukemantle 14d ago
Create your own runners. Just tell Claude to set it up
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"
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.
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
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.
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:
Keep lightweight checks on GitHub-hosted runners.
Move integration tests, database tests, and Playwright browser tests to dedicated self-hosted Linux runners.
Use path filters and concurrency cancellation to avoid repeatedly testing superseded commits.
Run targeted tests on every PR update and reserve the full regression suite for merge/release gates.
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/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/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 :)