GitHub Actions Pricing 2026: The Practical Playbook

GitHub Actions pricing 2026 isn’t just a line item change—it’s a structural shift. Hosted runner prices dropped in January 2026, but starting March 1 a $0.002 per‑minute platform fee applies to self‑hosted runner usage, and on March 16 there’s a hard gate: self‑hosted runners older than v2.329.0 won’t register. If you run CI at scale, those two dates reshape your budget, your runner strategy, and your upgrade sequencing.

What changed—and the exact dates you can’t miss

Here’s the thing: 2026 packs multiple GitHub Actions milestones into one quarter. The ones that matter for day‑to‑day operations are concrete and near‑term:

• January 1, 2026: GitHub‑hosted runner list prices dropped (up to roughly 40%, depending on OS and size). If you run most jobs on hosted Linux/Windows/macOS, your raw minute rate decreased.
• March 1, 2026: A $0.002/min “platform fee” now applies to self‑hosted runner minutes. Those minutes draw down your included plan allowance first, then bill at list price. Public repos remain free.
• March 16, 2026: Minimum version enforcement for self‑hosted runner registration. Versions older than v2.329.0 (released October 15, 2025) are blocked from configuring. Expect brownouts if you’re late.
• Also looming: Node.js 20 LTS reaches end of life on April 30, 2026. Any Actions or custom tooling pinned to node20 need attention.

Put differently: your March budget increased if you’re heavy on self‑hosted minutes, and your March reliability hinges on runner upgrades. Both matter at once.

GitHub Actions pricing 2026: how to forecast your new bill

Cost forecasting used to be a single dimension: hosted minutes times a rate. 2026 adds a second lever—self‑hosted minutes now pay for the orchestration plane. The simplest model is a two‑bucket worksheet:

1. Hosted minutes (Linux/Windows/macOS): quantity × updated rate (post‑January reductions).
2. Self‑hosted minutes: minutes × $0.002/min platform fee. These consume included minutes before charging overage.

Quick sanity checks I use with clients:

• If you run ~80,000 self‑hosted minutes/month, the platform fee exposure is about $160 before free minutes. Whether you ever pay overage depends on your plan allowance and other hosted usage.
• Shaving 10% off self‑hosted minutes (through smarter caching, matrix pruning, or parallelism caps) typically saves more cash than re‑platforming a handful of jobs.
• macOS is still the outlier: hosted macOS minutes are pricier, so offloading iOS builds to self‑hosted hardware may stay sensible even with the fee—run the numbers for your mix.

One subtlety: the platform fee “competes” with hosted minutes for your included allowance. If you were counting on those free minutes to absorb Linux runners, heavy self‑hosted usage can eat the allowance first. Budget owners should revisit thresholds and alarms this week.

Do you move workloads back to hosted runners?

Not necessarily. Hosted got cheaper; self‑hosted got a baseline fee. The winner still depends on your constraints. A practical decision grid I share with teams:

• Choose hosted when speed‑to‑scale and zero maintenance beat every other concern, or when workloads are CPU‑bound without large images/artifacts.
• Choose self‑hosted when you need GPUs, custom kernels, huge caches, on‑prem isolation, or predictable low latency to private registries and internal services.
• Choose hybrid when you can segment: keep heavy Docker builds, iOS CI, or ML inference tests on self‑hosted; move lint/unit/integration smoke to hosted. Use labels to steer.

The March shift nudges more orgs toward hybrid. It rarely flips the table by itself.

Minimum runner version enforcement: don’t get locked out

On March 16, older self‑hosted runners stop registering. Two practical implications often missed in planning meetings:

• Automation scripts that register ephemeral runners (in Kubernetes or autoscaling groups) must pull a compliant runner build. If your AMIs or container images bake an older tarball, your scale‑out will silently fail on a busy morning.
• Base image drift: the official runner Docker image moved from Ubuntu 22.04 to 24.04 in the early‑2026 releases. That can shift glibc, toolchains, and package names. Pin what you need; test what you can’t pin.

My rollout checklist for upgrades that won’t bite you:

1. Inventory every runner group and label, plus where each is provisioned (VMs, ARC on Kubernetes, bespoke Daemons).
2. Find images/AMIs referencing runner versions; bump them to v2.329.0 or newer and note the Ubuntu 24.04 base if you pull the official image.
3. Stage on a canary label (for example, self‑hosted,linux,x64,canary) and run your busiest five workflows against it for two days.
4. Flip registration scripts and autoscaling templates to the new bits; verify that tear‑down still deregisters properly.
5. Roll by environment or business unit; don’t big‑bang.

Node.js 20 EOL is right after your runner deadline

Node 20 LTS reaches end of life on April 30, 2026. That hits Actions in two places: third‑party Actions that still bundle node20, and your runs.using: node20 custom Actions. Teams that upgraded runners but forgot Action runtimes will discover breakages later—right when you’re closing a quarter.

Practical steps:

• Scan your workflows for uses: actions/*@ and vendor Actions. Upgrade to versions that ship node24 bundles.
• For private Actions, rebuild with node24, re‑package, and tag a backward‑compatible minor release.
• Where possible, migrate node20 setup steps to actions/setup‑node pinned at an LTS that’ll be supported through 2026.

CostOps in practice: a 30‑day plan you can actually follow

You don’t need a six‑month platform migration. You need four fast loops:

1. Visibility (Days 1–3): Export Actions usage by runner label and job name. Tag the top 20 jobs by total minutes and by concurrency spikes.
2. Stabilize (Days 3–10): Upgrade runners to ≥ v2.329.0 on a canary group; validate iOS/Android toolchains, Docker/BuildKit, and any GPU nodes.
3. Optimize (Days 7–20):
   • Cap matrix expansion on PRs; run the full matrix only on main and release branches.
   • Introduce warm caches for language package managers with deterministic keys.
   • Split giant workflows into reusable jobs; fail fast on lint/typecheck before computes spin up.
4. Rebalance (Days 15–30): Move predictable, lightweight jobs to hosted runners to leverage the price cuts. Keep heavy Docker builds, iOS/macOS, and GPU jobs self‑hosted. Re‑label accordingly.

Net result: most orgs cut 10–25% of minutes without touching product velocity, and they avoid the March 16 lock‑outs.

ARC, RunnerScaleSet, or plain VMs?

If you’re on Kubernetes, the Actions Runner Controller (ARC) remains the cleanest path for high churn workloads. RunnerScaleSet gives straightforward horizontal scale and lifecycle management. For smaller teams, a small VM pool with a cron job that rotates runners daily is still fine—just update the registration token logic and runner version.

My default advice: start with ARC where you already have a cluster and basic SRE hygiene. Otherwise, dedicate two or three VMs per environment and move to ARC when queuing or image management becomes a tax.

“People also ask” on GitHub Actions pricing 2026

Does GitHub charge for self‑hosted runners now?

Yes. Since March 1, 2026, self‑hosted minutes incur a $0.002/min platform fee. Those minutes count against your included allowance before any overage charges kick in.

Are public repositories still free?

Yes. Jobs on public repos remain free to run; the platform fee targets private and internal usage.

How many “free minutes” do I get?

It depends on your plan. What changed is that self‑hosted minutes now draw down that allowance. If you were using most of your allowance on hosted Linux, expect some cost shifting.

What’s the cheapest way to run macOS builds?

Do the math for your queue depth and concurrency. Hosted macOS got cheaper in January, but busy iOS shops often still win with self‑hosted Macs—even after adding the platform fee—because they avoid long queues and can tune Xcode images and caches aggressively.

Risk ledger: what can actually break in March?

Let’s be candid about the failure modes I’ve seen:

• Runner registration failures on autoscaling paths when images bake an older runner binary.
• Toolchain regressions after the base image moves to Ubuntu 24.04—especially for pinned glibc, legacy OpenSSL, or custom CUDA toolkits.
• Budget alerts tripping because self‑hosted minutes consumed the plan allowance earlier in the month than expected.
• Node runtime surprises as node20‑based Actions go stale approaching April 30, 2026.

None of these are catastrophic if you stage upgrades and watch cost telemetry closely.

A pragmatic optimization checklist

If you only have time for one pass this week, use this nine‑point list:

1. Upgrade all self‑hosted runners to ≥ v2.329.0; rebuild AMIs/images; test registration flow.
2. Enable a canary runner label and mirror your top five jobs for 48 hours.
3. Pin Docker BuildKit and cache mounts; invalidate on lockfile change only.
4. Split long workflows into reusable jobs and add fail‑fast gates early.
5. Introduce concurrency groups on PR pipelines to cancel superseded runs.
6. Set artifact retention to a sane default (24–72 hours) unless compliance requires longer.
7. Transition custom Actions to node24; bump third‑party Actions to node24 bundles.
8. Move lightweight, high‑fanout jobs (lint, unit) to hosted runners to exploit the price cuts.
9. Stand up basic cost dashboards by label and workflow; alert on allowance consumption.

Real‑world scenarios

Two quick examples to showcase how the math and operations intersect:

Mobile‑first SaaS: 40 iOS jobs/hour at peak, 12‑minute average runtime. Self‑hosted Macs still win because you cap queueing and reuse 300‑GB derived caches. The $0.002/min fee adds roughly $350–$400/month at your current scale—less than the developer time saved by 15–20 minute faster PRs.

API platform with heavy Docker builds: After caching layers properly and moving lint/unit to hosted Linux, self‑hosted minutes drop by ~20%. Your remaining self‑hosted builds pay the platform fee, but you cut peak cluster size and stabilize throughput. Net spend flat to slightly down, with fewer flaky builds.

What to do next (this week)

• Review your plan’s included minutes and set new spending alarms at 60% and 85% of allowance.
• Upgrade runners to ≥ v2.329.0 everywhere; canary and roll progressively.
• Refactor the noisiest workflows; cap matrix and add fail‑fast.
• Rebalance hosted vs self‑hosted by job type; document the policy with labels.
• Schedule the Node 20 to Node 24 migration before April 30, 2026.

Need a hands‑on plan?

If you want a turnkey roadmap, we’ve published focused guides and upgrade plans you can adapt. For a cost‑first take, start with an actionable pricing checklist. If you’re leaning into self‑hosted, our 2026 self‑hosted runner plan covers capacity modeling, labels, and maintenance windows. For orgs that need a fast escalation path next week, read what to change now on self‑hosted pricing and get in touch via our contact page.

Zooming out: what this means for platform teams

This year nudges CI economics toward transparency. You’re now paying a fair slice for orchestration even when you bring your own compute. That’s not a reason to ditch self‑hosted; it’s a reason to right‑size it. Platform teams that treat CI as a product—clear SLOs, cost telemetry, and predictable images—will come out ahead.

And if you’re juggling more than Actions right now—Android developer verification, Play fee updates, or Node.js 20 end‑of‑life—our editors maintain practical playbooks across the stack. You can browse recent briefings on our blog or see how we execute in our portfolio.

Final take

GitHub Actions pricing 2026 rewards teams that are intentional. Cut noise from your pipelines, keep specialized jobs on self‑hosted where they shine, and send the rest to hosted runners that just got cheaper. Upgrade runners before March 16, move your Actions off node20 before April 30, and give finance a forecast they can trust. That’s how you de‑risk March—and maybe even lower your CI total cost of ownership while you’re at it.