GitHub Actions Pricing 2026: The Real Cost Math

GitHub Actions pricing 2026 changed two big things: hosted runner list prices dropped on January 1, 2026, and a $0.002 per‑minute platform fee now applies to private‑repo workflows running on self‑hosted runners starting March 1, 2026. Public repositories remain free for runner minutes, and beginning March 1 self‑hosted usage can draw from your plan’s included minutes. There’s also an operational deadline on March 16, 2026: self‑hosted runners older than the enforced minimum version are blocked at configuration time. Here’s what that means in practice—and how to model, optimize, and ship a sane plan this month.

What actually changed in GitHub Actions pricing 2026?

Let’s separate signal from noise. As of January 1, 2026, GitHub reduced list prices for GitHub‑hosted runners (the exact reduction depends on OS and size). On March 1, 2026, GitHub added a $0.002/min cloud platform charge when your private workflows run on self‑hosted runners. The fee doesn’t apply to public repos, and Enterprise Server customers are out of scope. Starting March 1, self‑hosted minutes can consume the same included quotas your plan already has for Actions minutes.

Two more details matter for planning: (1) GitHub estimates the vast majority of customers see no increase—most either break even or pay less after the hosted runner price cuts; and (2) of the small cohort that does see an increase, the median bump is modest. That’s comfort, not a cost model. You still need your own numbers.

Finally, March 16, 2026 introduces a reliability gate: self‑hosted runner configuration is blocked if you’re under the enforced minimum version. Expect brownouts leading into the date; treat this as a security and stability upgrade, not just a checkbox.

The GitHub Actions pricing 2026 model you can run in an hour

Here’s the thing: spreadsheets don’t need to be fancy to be right. You can forecast within 10% accuracy with last quarter’s usage and a few knobs.

1) Pull last quarter’s minutes by runner type

Export Actions usage and split minutes into three buckets: private on GitHub‑hosted, private on self‑hosted, and public. If you don’t have a clean split, sample a representative month and scale.

2) Apply the new hosted runner rates

Hosted runner prices changed January 1. Multiply your private hosted‑runner minutes by the new per‑minute rate for each OS/size you actually used. Public stays zero.

3) Apply the self‑hosted platform fee

Multiply private self‑hosted minutes by $0.002. That’s the platform fee—compute and storage for your self‑hosted machines remain your responsibility and aren’t part of GitHub’s bill.

4) Subtract included minutes

Plans include a monthly allowance. As of March 1, self‑hosted minutes can consume that pool just like standard Linux/Windows/macOS minutes. Apply the allowance across your private minutes (hosted and self‑hosted) before calculating overage.

5) Add storage and data transfer if relevant

Artifacts and cache beyond your included quota are billed pay‑as‑you‑go. Rates vary by plan—verify in the pricing calculator for your org. Don’t guess; check your current usage and retention windows.

6) Sanity‑check with a sensitivity table

Create a small table that varies total minutes (+/‑20%), self‑hosted share (e.g., 25/50/75%), and cache hit rate. You’ll quickly see which levers matter.

Worked examples

• Startup with a single self‑hosted build box running 50,000 private minutes/month: platform fee ≈ 50,000 × $0.002 = $100. If your plan’s included minutes cover 30,000, only 20,000 count toward overage—adjust accordingly.
• Mid‑market org with 1,000,000 private minutes/month split 70% self‑hosted, 30% hosted: platform fee ≈ 700,000 × $0.002 = $1,400. Hosted minutes are billed at the new, reduced rates by OS/size. Public minutes remain zero.

If those numbers look smaller than the internet drama suggested, you’re not imagining it. The big bills come from scale, from inefficient pipeline design, or from high artifact/cache churn—often all three.

Optimization moves that actually move the needle

Let’s get practical. These changes are a permission slip to modernize CI. The goal is faster feedback with fewer wasted minutes and bytes.

Right‑size runners by workload, not by habit

Use the smallest runner that still meets your SLA. A 4‑vCPU machine finishing twice as fast as a 2‑vCPU equivalent may be worth the higher per‑minute hosted rate because total minutes drop. For self‑hosted, the trade is platform fee minutes versus your own compute cost; benchmark with real jobs, not lore.

Kill cold‑start tax with smart caching

Pipeline time disappears into dependency fetches and toolchain setup. Use layered Docker images or pre‑baked AMIs for self‑hosted runners, and pin cache keys by lockfiles not by branch. Revisit cache retention now that pay‑as‑you‑go storage is available—keep what you hit, evict the rest.

Parallelize where it pays

Matrix builds can halve wall time, but they also multiply minutes. Reserve heavy parallelism for long‑running integration and end‑to‑end suites where feedback speed matters, and collapse trivial jobs into a single runner to avoid orchestration overhead.

Make test time proportional to change

Adopt test impact analysis or change‑aware paths. If a commit only touches a UI package, don’t build and test the entire monorepo. Even a coarse “changed packages only” policy can cut minutes by 30–50% on large codebases.

Autoscale self‑hosted without Kubernetes

If you don’t want to run Actions Runner Controller (ARC), GitHub’s Scale Set Client is a lightweight path to autoscaling on VMs or cloud instances. It queues jobs, manages secrets, and lets you grow into more sophisticated setups later. If you already run ARC, validate your Helm charts and metrics stack before the March version cutoff.

Reduce artifact churn

Artifacts are great for handoffs, but they’re also a hidden bill. Compress, deduplicate, and shorten retention. Prefer registry‑based handoffs (container images, package registries) over uploading massive zips between jobs.

March 16 runner enforcement: treat this like a security upgrade

On March 16, 2026, GitHub blocks self‑hosted runner configuration if you’re below the enforced minimum version. Brownouts in late February and March exist to surface breakage early. Treat this as a security and operability upgrade window: update runners, validate labels, and confirm registration flows for autoscaling pools. If you run ARC, test your controller and chart versions in a staging cluster, and document your rollback plan.

• Upgrade every self‑hosted runner to the enforced minimum version or newer.
• Pin actions (including actions/cache) to stable majors and verify Node/runtime compatibility.
• Rebuild base images to pick up OS security fixes and the new runner.
• Test registration from a cold start for autoscaled pools; watch logs for throttles.
• Audit runner labels and required labels in workflows; remove stale selectors.

For a deeper operational playbook—brownout timelines, upgrade sequencing, and impact testing—see our guidance on shipping a real plan for these changes in our step‑by‑step rollout article.

People also ask

Does the $0.002/min fee apply to public repositories?

No. Public repository workflows remain free for runner minutes, whether hosted or self‑hosted, though storage policies still apply.

Will my included minutes cover self‑hosted usage?

Yes, as of March 1, 2026, private self‑hosted minutes can consume the included minutes from your plan before overage charges apply.

Is it cheaper to move everything to self‑hosted?

Not necessarily. You still pay the platform fee for private minutes, plus your own compute, storage, and ops time. For many teams, a hybrid model—bursty or specialized jobs on self‑hosted, the rest on GitHub‑hosted—wins on both speed and cost.

How do I estimate storage and egress?

Use the pricing calculator tied to your plan and read your last three months of artifact and cache usage. Retention tweaks often produce bigger savings than switching CI providers.

A pragmatic checklist to cut minutes and risk this week

Ship these in order. Each item is fast, measurable, and reversible.

• Enable concurrency groups to cancel superseded builds on feature branches.
• Cache by lockfile; prime caches nightly for hot paths (build toolchains, package managers, language runtimes).
• Split unit vs. integration tests; run unit tests on pull request, push integration to post‑merge or nightly.
• Adopt a small runner for lint/typecheck and a larger one for compile/test; don’t use a sledgehammer for a fly.
• Set artifact retention by job type (e.g., 3 days for CI zips, 30 days for release bundles).
• Introduce a change‑aware monorepo job that filters builds to changed packages.
• Upgrade all self‑hosted pools to the enforced minimum runner version; test autoscaling from zero.

How to decide: hosted vs. self‑hosted in 2026

Self‑hosted is great when you need specialized hardware (GPUs, large RAM), strict network locality, or when you can keep runners warm and highly utilized. Hosted excels for bursty workloads, lower ops overhead, and simpler governance. The 2026 pricing nudges you to be explicit: if you’re paying the platform fee for self‑hosted, make the most of it—pack jobs, keep runners busy, and minimize idle minutes. If you can’t, lean on hosted and let the new rates work for you.

Zooming out, stick to three questions: (1) What’s the fastest path to a green check for your developers? (2) Where is your biggest cost per merged PR? (3) Which set of knobs (runner size, parallelism, caching, retention) gives you the best speed‑per‑dollar without new risk?

What to do next

Here’s a tight action plan you can knock out in under two weeks:

1. Pull last quarter’s usage and build the three‑bucket split (public, private hosted, private self‑hosted). Build the sensitivity table.
2. Upgrade self‑hosted runners to the enforced minimum version; stage and then roll to prod.
3. Benchmark: run your top three workflows across two runner sizes and record minutes, cache hits, and pass rates.
4. Turn on concurrency cancellation and deduplicate artifacts; tighten retention for CI‑only zips.
5. Adopt a hybrid policy: default to hosted; move only heavy, specialized, or consistently hot jobs to self‑hosted pools.
6. Re‑forecast with real measurements; set a monthly budget alert and minutes guardrails.

If you want a head start, our team has been helping clients ship these changes with zero downtime. Read our hands‑on what teams should change now and the practical playbook, then bring us in through our engineering services page to pressure‑test your pipeline and budgeting model.

Bottom line

GitHub Actions pricing 2026 didn’t break CI/CD. It made the economics more explicit. If you treat the $0.002/min platform fee as a forcing function to streamline minutes and storage, you’ll come out faster and, for many workloads, cheaper. The March 16 runner enforcement is your reliability checkpoint—use it to reset technical debt, validate autoscaling, and future‑proof your pipeline. The teams that win are the ones that measure, iterate, and ship a plan while everyone else is still arguing on Slack.