This was the second month in a row I hit the GitHub Actions minutes limit. And I'd already switched to Pro to get more - 3,000 minutes a month for private repos, at the time of writing. The bill creeps from the €4-ish I actually want to pay into double digits, and for what? Running the same builds I could run on hardware I already own.

So I decided it was enough. I moved all of it onto self-hosted GitHub Actions runners: one small cloud box for deploys, and a 16GB mini PC sitting in my living room for the heavy lifting. Billed CI minutes are now zero. Here's exactly how.

Where the minutes actually went

First thing I did was stop guessing and look at what was eating the budget. It wasn't the deploys. Push to main, build two images, ship - that's a couple of minutes a few times a day. Annoying but not 3,000-minutes-a-month annoying.

The killer was a nightly cron that runs a batch of build-and-boot tests. It's a few dozen small jobs, each one building an image and booting it to make sure nothing's quietly broken. They run on every relevant pull request, and once more every night to catch base images drifting underneath us.

Self-hosted runners don't burn billed minutes

Here's the thing most people miss when they look at that bill: GitHub only charges for GitHub-hosted runners. A self-hosted runner doesn't consume your included minutes at all. The compute is yours, so GitHub stops counting.

That reframes the whole problem. I don't need to make CI cheaper. I need to run it somewhere I already pay for.

I briefly looked at the heavyweight option - the "run your own CI platform" tools like OVH CDS. They're genuinely good if you're an org with hundreds of pipelines and a team to babysit a distributed system. For one person trying to save €6 a month, standing up a fleet of microservices with its own database to replace 40 lines of YAML is the definition of a cure worse than the disease. I closed that tab.

A GitHub Actions self-hosted runner is the opposite of that. It's a single binary that runs as a systemd service and polls GitHub for jobs over an outbound connection. Setup is about ten minutes. You don't even change your workflows beyond one line:

jobs:
  build:
    runs-on: [self-hosted, my-label]   # was: ubuntu-latest

That's it. Everything else - the build steps, the cache, the deploy - stays exactly as it was.

The asterisk: GitHub already tried to charge for this once

I should be straight about the wobble here, because if you follow this stuff you already know about it. In December 2025 GitHub announced that starting March 2026 it would charge $0.002 per minute for self-hosted runner usage on private repos - a "cloud platform charge" for the orchestration layer, even though the compute is yours. The logic was that hosted-runner revenue had been subsidising free self-hosted usage, and they wanted that subsidy back.

The developer community reacted about how you'd expect to being told to pay per minute for software running on hardware they already own. The backlash was loud and fast, and within roughly a day GitHub postponed it. The hosted-runner price cuts (up to 39%, also announced that week) went ahead on January 1; the self-hosted charge got shelved "to re-evaluate."

Here's the part that matters for anyone betting their CI on this: postponed is not cancelled, and GitHub was careful never to say cancelled. They kept the framing of real control-plane costs and promised only to consult before trying again. Read plainly, the intent is still there, the rollout just blew up. So the honest version of "self-hosted runners are free" is free today, with a credible chance of a small per-minute platform fee returning later in some form.

Does that change the math? Barely, at the scale this post is about. The proposed rate was $0.002/min - my ~3,150 nightly minutes would have been about €6 a month, which is exactly the bill I was trying to escape, so that would sting. But the fee counts against your included plan minutes before it bills, so a lot of small users would never have paid a cent.

And here's the actual hedge: if GitHub does reintroduce a charge for running CI on my own hardware, I move the runners to self-hosted GitLab. GitLab is open-source, you can run the whole thing yourself - the server and the runners - and there's no per-minute platform fee skimmed off compute you already own, because there's no GitHub in the middle to take a cut. GitLab Runner uses the same one-binary, polls-outbound model, so it's a lateral move, not a migration into the unknown. The workflows would need porting from Actions YAML to .gitlab-ci.yml, which is real work, but it's a weekend, not a rebuild. The whole point of going self-hosted was to run CI on hardware I control. A platform fee doesn't undo that - it just decides which orchestrator I point the runners at.

First, the part you have to get right: scope these to private repos

One hard rule before any setup, because it's the whole reason the architecture below looks the way it does. A self-hosted runner executes whatever a workflow tells it to, on your hardware, with whatever that box can reach. Point one at a repo that accepts pull requests from strangers and a fork PR can run attacker-controlled code on your machine - then it's your secrets, your cached credentials, and a foothold on whatever network the box sits on. Because the runner connects outbound to GitHub over a trusted channel, that malicious traffic looks exactly like normal CI and your network monitoring sees nothing.

This isn't theoretical. Researchers found GitHub's own runners, plus PyTorch and Tensorflow, exploitable through exactly this fork-PR-on-a-persistent-runner pattern, and GitHub's own docs say plainly that a self-hosted runner can be persistently compromised by untrusted code in a workflow.

So the rules the rest of this post quietly obeys:

• Private repos only. Every repo a self-hosted runner touches is one only I can push to. No fork PRs, no strangers, no untrusted workflow code. This single rule kills most of the attack class.
• The build box can't reach production. It talks outbound to GitHub and the registry, nothing else. It holds no key to prod (more on that split below).
• Run it unprivileged and capped. Not as root, and boxed into a resource slice so a runaway or hostile job can't take the whole machine.

If you take one thing from this post, take the first bullet. Everything else is optimisation; that's the line between "free CI" and "free foothold into your network."

Step one: a tiny cloud box for deploys

I started with deploys, because those are the part that touches production and I wanted them boring and reliable.

I had a small cloud VPS spare in Falkenstein, Germany - the €4-a-month kind, 4GB of RAM, same datacenter as our production servers. I installed Docker and the runner, registered it, flipped the deploy workflow to runs-on: self-hosted, and the first deploy went green on the new box.

Then I got a bonus I didn't plan for. Because that runner sits on the same private network as production, the deploy stopped going over the public internet entirely - it now reaches the production box over a private address. Which meant I could finally do something I'd been putting off: stop exposing production's management access to the whole internet and lock it down to just my laptop and that one runner.

So step one didn't just kill some billed minutes. It pulled production's management surface off the public internet as a side effect. Good trade for an afternoon.

Step two: the real horsepower was in my living room

The cloud box handled deploys fine, but it's a 4GB machine. The nightly batch on a single small runner is a slow, serial grind - and the heavier builds (the Next.js and Nuxt of the world) will happily try to eat more than 4GB and fall over.

The box with the actual horsepower was already in my apartment. A mini PC running my homelab - 16GB of RAM, four cores, on 24/7 anyway, currently busy serving Pi-hole and a photo library to nobody in particular. That's a better build machine than the cloud VPS by a wide margin, and it costs me nothing extra because it's already plugged in.

So I split the work by what it actually needs:

• Build and test jobs run on the living-room box. They only ever talk outbound - pull code from GitHub, push images to GitHub's container registry. They never touch production.
• Deploy jobs stay on the cloud box, on the private network, allowed to reach production.

The handoff between them is the registry. The homelab builds the image and pushes it; the cloud runner tells production to pull it. The two machines never talk to each other directly, so the homelab never needs a route into prod. That separation is the security rule from earlier made concrete: the build box is the softer target (it runs third-party action code), and I don't want a softer target holding a key to production.

                       BUILD HERE, DEPLOY THERE, PROD STAYS SEALED

  ┌──────────┐      ┌────────────────────────┐         ┌────────────────────────┐
  │ git push │      │ BUILD + CI             │         │ DEPLOY                 │
  │  → main  │ ───▶ │ sidekick · living room │         │ cloud box · Falkenstein│
  └──────────┘      │ 16 GB · 4 capped agents│         │ 4 GB · on prod network │
                    │                        │         │                        │
                    │ build images·run tests │         │ pull image · roll prod │
                    │ nightly test batch     │  image  │ reaches prod over the  │
                    │                        │ ──────▶ │ private net only       │
                    │ outbound only,         │  (GHCR) │                        │
                    │ no inbound port        │         │ prod mgmt closed to    │
                    └────────────────────────┘         │ the world              │
                                                       └───────────┬────────────┘
                                                                   │ private net
                                                                   ▼
                                                          ┌──────────────────┐
                                                          │   production     │
                                                          │   Falkenstein    │
                                                          └──────────────────┘

  Billed GitHub Actions minutes: 0
  Both boxes were already paid for, and the build box holds no route into production.

One detail that makes this painless: the runner connects outbound. There's no inbound port to forward, no firewall hole in my home router, and it works fine behind the carrier-grade NAT a lot of home connections sit behind. The runner dials GitHub; GitHub never dials the runner.

Keeping CI from taking down the house DNS

Here's the part nobody warns you about when you put a CI runner on a box you actually live with. That mini PC isn't a dedicated build server. It runs Pi-hole - which is the DNS for my entire apartment. If a build pegs all four cores and starves Pi-hole, every device in the house loses name resolution. That's not a CI incident, that's a "why is the TV not working" incident.

So the runners are capped. All of them live in a systemd slice with a CPU quota and a memory ceiling, leaving a core and a few gigs of headroom for the homelab stack:

# /etc/systemd/system/ci-runners.slice
[Slice]
CPUQuota=300%      # 3 of 4 cores, max, for all CI combined
MemoryMax=12G

That cap does double duty: it keeps the house DNS alive, and it's also the "run it capped" rule from the security section. A job that goes hostile or just runs away can't take the whole machine with it.

I also ran more than one runner agent on the box. A single agent does one job at a time, which turns that nightly batch into a long single-file queue. Four agents on a four-core box fan it out and bring a two-hour serial slog down to about half an hour. They share the same label, so GitHub load-balances jobs across them with zero workflow changes. The nightly run kicks off at 4am UTC, which is when I'm asleep and the house DNS has nothing better to do anyway.

What it costs now

Zero billed GitHub Actions minutes. The cloud runner is a box I was already paying ~€4/month for, doing deploys it was idle for anyway. The homelab is hardware that was already on. I dropped from a double-digit GitHub bill back to the €4 I was always happy to pay.

If you're hitting the same wall - overage emails, a Pro plan that still isn't enough, a CI bill that has nothing to do with how much you ship - the move is smaller than you think. One spare box, a binary, one line of YAML, and the discipline to only ever point it at repos you control. You probably already own the hardware.

FAQ

Do self-hosted GitHub Actions runners cost money?
Not in GitHub minutes today. GitHub only bills for its hosted runners - self-hosted runners don't touch your included minutes, you just pay for the machine. The caveat: in December 2025 GitHub announced a $0.002/min platform charge for self-hosted usage on private repos, then postponed it after backlash. It's not in effect, but it's postponed rather than cancelled, so treat "free" as "free for now." See GitHub's billing docs.

Can I run a self-hosted runner on a home network behind NAT?
Yes. The runner makes an outbound connection to GitHub and polls for work. There's no inbound port to open, no router config, and it works behind carrier-grade NAT. That's what makes a living-room box viable.

Are self-hosted runners safe?
Only if you scope them right, and getting this wrong is genuinely dangerous. The thing to never do is attach a self-hosted runner to a repo that accepts pull requests from strangers - a fork PR can run attacker-controlled code on your hardware, steal secrets, and pivot into whatever network the box can reach. Researchers found GitHub itself, PyTorch, and Tensorflow exploitable this exact way. Keep the runner on private repos you control, run it as an unprivileged user, cap it with a resource slice, and never let the box that runs untrusted action code hold credentials to production.

Should I run everything on the self-hosted runner, or keep some jobs hosted?
Split by what the job needs. Heavy, frequent builds are the ones worth moving - that's where the minutes go. A job that wants massive parallelism (a big test matrix finishing in five minutes across dozens of ephemeral machines) can actually be a poor fit for one or two self-hosted agents. Move the minute-burners, leave the rest.

What's the difference between a self-hosted runner and a full CI platform like Jenkins or CDS?
Scale and babysitting. A self-hosted GitHub Actions runner is a single agent that plugs into the GitHub Actions you already use - your existing workflows run unchanged. A full self-hosted CI platform replaces GitHub Actions entirely and is a distributed system you operate yourself. For one person or a small team, the runner is almost always the right call.