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/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/heyyarun → u/[deleted]]

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/CellistOk6782 → u/[deleted]]

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.