GitHub Actions Self‑Hosted Runner Pricing: What Now

GitHub Actions self-hosted runner pricing isn’t theoretical anymore. As of March 1, 2026, GitHub adds a $0.002 per‑minute platform charge to workflows that run on self‑hosted runners, with public repositories exempt. And on March 16, 2026, GitHub will block runner configuration/registration below v2.329.0. If your delivery engine leans on self‑hosted Linux, Windows, or macOS runners for speed or control, you need a plan this week.

Quick timeline and what actually changes

Here’s the thing: there are two overlapping changes and they pull in different directions for your budget and operations.

First, billing. Starting March 1, 2026, GitHub bills self‑hosted runner minutes at $0.002 per minute via a new platform fee. Your included plan minutes now apply to self‑hosted usage as well, and public repo jobs remain free. GitHub previously reduced hosted runner rates (effective January 1, 2026), so hosted may now be cheaper than you remember—depending on machine size.

Second, enforcement. Starting March 16, 2026, GitHub enforces a minimum self‑hosted runner version at configuration/registration time: v2.329.0 or newer. If you bake older runners into images or AMIs and try to register them after that date, registration will fail. Existing runners still need to stay reasonably up to date to keep receiving work, but the hard block is at configuration time.

GitHub Actions self-hosted runner pricing: facts you can model

The per‑minute fee is simple multiplication. You’re charged:

Billable self‑hosted minutes × $0.002, minus any free minutes included in your plan.

Scenarios to anchor your forecast:

• 10,000 minutes/month of self‑hosted CI → about $20 per month, plus your infra costs.
• 250,000 minutes/month → about $500 per month, plus infra.
• If your org has generous included minutes, apply them first. From March 1, self‑hosted minutes count against that pool before you see additional line items.

Will most teams see a large increase? GitHub’s own framing says the vast majority won’t. In practice, heavy self‑hosted shops will start to notice the delta, especially if they’ve built for very high parallelism.

Why GitHub is doing this—and what it means for architecture

Self‑hosted runners have always leaned on GitHub’s control plane: job orchestration, logs, artifacts, APIs, audit trails, and more. The platform fee aligns costs to consumption, and it comes alongside investments that matter for enterprises: multi‑label support returning, a Scale Set Client for autoscaling without Kubernetes, and better observability streams.

Translated: GitHub wants to make self‑hosted first‑class for complex estates, but not cross‑subsidized by hosted runner pricing. Expect better tooling—and a meter attached.

Compliance clock: the v2.329.0 runner requirement

Mark March 16, 2026. From that date, runners below v2.329.0 can’t register. For teams with immutable images (AMIs, VM templates, golden containers), this bites fast: any pipeline that spins up fresh runners at job time must bake in the updated runner binary before running the registration script.

Gotchas I’ve already seen in audits this week:

• Ephemeral pools with stale base images: rotation continues to pass health checks but fails during registration after a scale‑up event.
• Docker‑in‑Docker builds: runner upgrades can change cgroup or BuildKit mount behavior; re‑validate cache paths and volume mounts.
• macOS fleets: Intel vs Apple silicon labels drift after rebuilds; watch job routing and capacity headroom.

Cost‑down tactics that won’t hurt developer speed

Let’s get practical. You can trim real dollars without turning your CI into molasses. Use this four‑step MOVE framework over two sprints:

M — Measure the minutes that matter

Export last 30–90 days of Actions usage. Split by runner type, repo, and workflow. Identify top 10 minute consumers and their median versus p95 runtime. Minutes saved on your slowest flows produce the biggest wins.

O — Offload what fits to hosted

If hosted runner prices dropped for your instance sizes, consider moving generic Linux jobs, static analysis, or doc builds back to hosted. Reserve self‑hosted for jobs that need privileged Docker, big cache disks, custom kernels, GPUs, or macOS.

V — Version and verify your runners

Standardize runner upgrade paths. Pin runner v2.329.0 or later in your Packer scripts, images, or Helm charts. Add a canary pool that runs the next runner version one week early. Block merges to your runner templates unless the version gate passes.

E — Eliminate waste

Stop the silent drains:

• Artifact retention: set explicit retention by job type. Do you really need 30 days for every debug tarball?
• Caching: use scoped keys and restore‑only on PRs where warm caches are high‑hit; don’t re‑save identical caches each run.
• Concurrency: cap duplicate pipelines on rapidly rebased branches.
• Matrix builds: pare the Cartesian product. Run smoke tests across all targets; run deep suites on a nightly schedule.

People also ask: quick answers you can share

How is the $0.002/min charge calculated?

GitHub tracks wall‑clock minutes consumed by workflows on self‑hosted runners. Those minutes are multiplied by $0.002. Your plan’s included minutes offset that total first. Public repo jobs are still free.

Do public repositories pay this fee?

No. Standard hosted and self‑hosted usage on public repositories remains free. Private repos and larger hosted runners incur costs.

What happens if my runner is older than v2.329.0?

Existing runners might keep working for a while if they’re already registered, but any attempt to configure/register a runner below v2.329.0 after March 16, 2026 will be blocked. Treat this as a hard prerequisite for image rebuilds and auto‑scaling groups.

Model your new CI bill in 10 minutes

Build a spreadsheet with three columns per workflow: monthly runs, average runtime (minutes), and runner type (hosted vs self‑hosted). Add a fourth column for “migratable?” where “yes” means the job can move to hosted without loss of capability. For self‑hosted minutes, apply $0.002/min and subtract your included minutes pool. Iterate by moving one job at a time from self‑hosted to hosted and re‑calculating. The goal isn’t zero self‑hosted; it’s the right mix.

If you run macOS self‑hosted for iOS, you’ll likely remain there. But you can still harvest savings by trimming matrix width, pruning artifacts, and sharing derived caches (e.g., build intermediates) across jobs in a single runner workspace.

Edge cases and enterprise‑scale considerations

ARC and Scale Set Client estates: if you use Actions Runner Controller (ARC) or the new Scale Set Client to autoscale runners, pin the runner version in your images and scripts. Add a pre‑flight that verifies the runner version before configuration. For pull‑through caches or private registries, validate that your images include the new runner binary before you rotate underlying nodes.

GPU and high‑mem runners: hosted price cuts may still not compete with your reserved cloud capacity for massive training or e2e browser runs. Run those jobs on self‑hosted; just reduce idle pools and right‑size instance types. For Chrome/Playwright fleets, centralize browser downloads in images to avoid cold start penalties that inflate minutes.

Security programs: if you run AI agents or codegen in CI to propose patches, keep egress tightly controlled on self‑hosted networks. If you haven’t added outbound allowlists, adopt an egress firewall pattern; it reduces attack surface and prevents surprise data exfiltration from agentic steps.

Speaking of security, don’t sleep on runtime deprecations. Node.js 20 reaches end of life on April 30, 2026. Pair your runner upgrades with a Node runtime uplift and lock down with deterministic installs. We’ve published a focused playbook for that upgrade path.

Concrete checklist for the next 10 days

1. Freeze your runner inventory today. List every image/AMI/template in use. Note the baked runner version.
2. Patch to v2.329.0+ across Linux, Windows, and macOS images. For ARC, pin the container tags that include the updated runner.
3. Canary and cut over. Route 10% of self‑hosted jobs to upgraded pools for 24–48 hours. Watch logs, mounts, labels, and cache hit rates.
4. Trim the top five time sinks. Reduce artifact retention, cap concurrency, and shrink matrices where possible.
5. Re‑balance hosted vs self‑hosted. Migrate one or two generic workflows back to hosted to test the new price/perf reality.
6. Set a monthly CI cost review. Treat CI like any other cloud bill. Assign ownership, define a budget guardrail, and review exceptions.

For iOS teams: watch the April deadline

If you ship to the App Store, you’re juggling two clocks. The Actions changes hit in March. Then Apple’s SDK/Xcode deadline lands in late April 2026. That means new Xcode images, updated SDKs, different signing toolchains, and likely longer build times on your macOS runners until caches settle. Budget a temporary minutes spike in April and May while the toolchain churns.

Our iOS‑focused guides break down the Apple timelines and how to stage your CI updates so review submissions don’t stall. If you’re running split Intel/Apple silicon fleets, we also cover label hygiene and capacity planning so jobs don’t strand on the wrong arch.

What to do next

Here’s a focused action list you can execute this week:

• Add runner version checks to every image build; fail the build if the version is below v2.329.0.
• Export last 90 days of Actions minutes; sort by workflow, then by p95 runtime. Fix the worst offenders first.
• Move one safe workflow back to hosted to test real‑world performance and new pricing.
• Slash artifact retention to 7 days for PR jobs; keep 30 days for releases only.
• Stand up a monthly CI Ops review with a named owner and a standing agenda: usage, waste, regressions, and open risks.

Where we can help

If you’d like a second set of eyes on pipeline economics, we’ve been tuning GitHub Actions for teams that run both hosted and self‑hosted at scale. We can audit runners, reshape matrices, and set up version gates so you never get caught by a registration block again. See how we work with clients on our engineering services, browse relevant playbooks on the blog, and if you’re navigating a March fire drill, grab time on our calendar via Contacts.

For deeper dives:

• Our field notes on the March enforcement window and upgrade traps: GitHub Actions Self‑Hosted Runner: March 2026 Plan.
• Planning an April Node upgrade alongside runner updates? See Node.js EOL 2026: Your 45‑Day Upgrade Playbook.
• Locking down CI network egress for AI‑assisted pipelines? Start with Egress Firewalls for AI Agents: A Practical Playbook.

Final take

Self‑hosted isn’t going away—it’s evolving. The new platform charge changes the math; the version gate changes the operational heartbeat. Teams that measure minutes, right‑size what truly needs self‑hosted, and institutionalize runner hygiene will come out ahead. Those that wait will pay twice: once in invoices, then again in downtime when a stale image refuses to register on March 16.

Make the next ten days count. Your future CI bill—and your developers—will thank you.