GitHub Actions Self‑Hosted Pricing: Your 2026 Plan

GitHub Actions self-hosted pricing is no longer theoretical. Since March 1, 2026, private and internal repo workflows running on your own machines accrue a $0.002 per‑minute platform fee. Combined with up to 39% price reductions for GitHub‑hosted runners that landed on January 1, many engineering leaders are rethinking where each job should run. If you own delivery and budgets, this is the moment to get intentional.

What changed in early 2026—and why it matters

Two levers moved in quick succession. First, on January 1, 2026, GitHub dropped prices for GitHub‑hosted runners (for example, baseline Linux 2‑core is $0.006/min; Windows 2‑core is $0.010/min; macOS standard is $0.062/min). Second, as of March 1, 2026, there’s a new $0.002/min platform charge for workflows that execute on self‑hosted runners in private or internal repositories. Public repositories remain free for standard runners; GitHub Enterprise Server customers are unaffected by this platform fee.

GitHub also says 96% of customers will see no change to their bill, and among the 4% affected, most experience small decreases while a minority see modest increases (median around $13). Those numbers make sense at platform scale, but your mileage depends entirely on how much you automated on self‑hosted to dodge runner costs in 2025.

There’s also a compatibility deadline in play: brownouts for outdated self‑hosted runner versions began on February 9, 2026, and full enforcement for registration requires v2.329.0 or later starting March 2, 2026. If your images bake in older agents, your autoscaling may quietly fail at registration time—minutes saved won’t matter if jobs stop queuing.

What does GitHub Actions self‑hosted pricing actually bill for?

Short answer: platform coordination time for private and internal workflows that execute on your self‑hosted runners. You still pay your own infrastructure bill (VMs, Kubernetes nodes, storage), and now you’ll also see platform minutes accrue at $0.002/min for those jobs. That usage can draw down your plan’s included minutes before overage pricing applies. Public repos stay free on standard runners. Larger hosted runners remain billable regardless of repo visibility.

Here’s the thing: for bursty or heterogeneous workloads, the January price cuts for hosted runners mean some jobs are now cheaper—or at least competitive—on GitHub‑hosted capacity, especially once you factor in engineering time to operate self‑hosted pools.

The quick math: should you switch back to hosted runners?

Let’s get practical. Suppose your organization runs 400,000 minutes/month on self‑hosted Linux for private repos.

• Self‑hosted platform fee: 400,000 × $0.002 = $800/month (plus your infra).
• Comparable hosted baseline Linux at $0.006/min: 400,000 × $0.006 = $2,400/month (infra included).
• If your infra to support those minutes costs $0.003–$0.004/min all-in (common for well-tuned autoscaling), your blended self‑hosted cost becomes $0.005–$0.006/min—roughly at parity with hosted after the price cuts.

Variables matter: cache hit rates, artifact sizes, image warmup, runner density per VM, and how often idle capacity sits around. If your runners aren’t tuned, the all‑in cost of “free” self‑hosting can exceed hosted rates—now more visibly so.

Use this 5‑lever framework to cut minutes 30–60% without slowing delivery

You don’t need a ground‑up migration to realize savings. Work these, in order:

1) Fail faster and skip work

• Add explicit path filters at the workflow and job level so only relevant jobs run.
• Move schema/lint/type checks to pre‑merge or pre‑commit hooks.
• Gate long integration suites behind changed‑component checks. Keep a nightly full sweep.

2) Make runners hotter

• Prebake common SDKs, package managers, and language toolchains into your runner base images.
• Keep warm pools for the busiest labels so jobs don’t pay cold‑start taxes. For Kubernetes‑based fleets, measure time‑to‑ready and right‑size node groups.

3) Attack I/O: caches and artifacts

• Optimize Actions cache keys to increase hits while avoiding cache poison. Beware over‑broad keys that fetch massive archives.
• Trim artifacts ruthlessly—store what you ship. Artifact storage is metered hourly; cutting retention from 30 to 7 days meaningfully reduces the bill.

4) Parallelize where it counts

• Shard slow test suites intelligently; run with a cap to avoid noisy neighbor effects.
• Split build and test across separate jobs so fast PR hygiene never waits on slow packaging.

5) Right‑place the workload

• Keep CPU‑bound, short‑lived builds on hosted runners if they’re compute‑efficient and latency tolerant.
• Reserve self‑hosted for cases that truly need local network access, custom hardware, or long‑lived caches.

If you want a deeper dive on minute‑by‑minute tactics, our team published a practical playbook you can adapt today. See GitHub Actions pricing in 2026: a practical playbook.

Architecture choices in 2026: ARC, runner scale set client, or DIY

You’ve got three viable patterns:

• Actions Runner Controller (ARC) on Kubernetes: battle‑tested autoscaling, solid for heterogeneous fleets, good isolation story with ephemeral pods. Overhead includes cluster ops, image curation, and networking quirks in restricted environments.
• Runner Scale Set Client (public preview): a lighter Go client that lets you scale runners across VMs or containers without Kubernetes. Great fit if you want fewer moving parts and still need autoscaling hooks and queue integration.
• DIY orchestrators: possible if you have unique constraints, but you’ll sign up for queue management, draining logic, version pinning, and more. It’s rarely cheaper in year two.

Strategic takeaway: if Kubernetes isn’t adding value elsewhere, the scale set client is likely the simplest self‑hosted path in 2026. If you already standardize on clusters for other workloads, ARC remains a strong default.

People also ask

Are public repositories still free?

Yes, standard hosted and self‑hosted usage for public repos remains free. Larger hosted runners are always billable.

Do included minutes apply to self‑hosted now?

Yes. The $0.002/min platform usage can consume included minutes associated with your plan before overage charges kick in.

What about GitHub Enterprise Server?

Enterprise Server customers running Actions on‑prem are outside this cloud platform fee. Different licensing applies there.

Does caching or artifact storage change?

Caching strategy directly impacts runtime; artifact storage is still billed by hourly usage. Shrinking what you upload and reducing retention windows are immediate wins.

A 30‑day optimization sprint you can run this month

Week 1 — Baseline and guardrails
• Pull 90 days of Actions usage by repo, job, and label. Rank minutes and failure causes.
• Freeze workflow sprawl. Require code owners on workflow files; set budgets and alerts.
• Enforce actions/checkout and common security guardrails to cut flaky reruns.

Week 2 — Eliminate waste
• Add path filters to the top five minute‑eaters; gate heavy tests behind changed‑component checks.
• Trim artifact retention from 30 to 7–14 days; split artifacts into “deployable” vs. “diagnostics.”
• Prebake toolchains into runner images; warm small fixed pools per busy label.

Week 3 — Re‑place workloads
• Pilot a hosted‑first strategy for short CPU‑bound jobs; keep self‑hosted for network‑sensitive or cache‑heavy tasks.
• If you’re on ARC, test runner density and pod resource requests; reduce idle nodes. If you’re DIY, evaluate the runner scale set client to retire glue code.

Week 4 — Lock in and document
• Codify cost policies in reusable workflow templates; ship an internal “minute budget” dashboard alongside DORA metrics.
• Document a rollback: if hosted queues spike, how do you burst to self‑hosted reliably? Practice the switch.

Cost scenarios you can copy‑paste

Scenario A — Mostly hosted, some self‑hosted for releases
• 250k hosted Linux minutes = ~$1,500
• 50k self‑hosted minutes for release packaging = $100 platform + infra (~$150–$250) → $250–$350
Outcome: Operationally simple; use self‑hosted where network access is essential.

Scenario B — Heavily self‑hosted monorepo
• 600k self‑hosted minutes = $1,200 platform + infra (~$1,800–$2,400) → $3,000–$3,600
• Compare 600k hosted Linux = ~$3,600
Outcome: Parity hinges on runner density, cache hits, and artifact slimming.

Scenario C — Mixed OS
• 150k Linux + 50k Windows hosted = $900 + $500 = $1,400
• Add macOS builds (say 10k minutes) = ~$620
Outcome: Windows/macOS tilt cost curves toward hosted unless you can drive very high cache reuse via self‑hosted.

Don’t get tripped by version enforcement

GitHub requires self‑hosted runners at v2.329.0+ for configuration as of March 2, 2026, with brownouts starting February 9. Update golden images, AMIs, and Helm charts accordingly. If your fleet auto‑updates after registration, that won’t help—registration is where the block happens now. While you’re at it, confirm your runner images are compatible with Ubuntu 24.04 if you track the upstream actions‑runner Docker image.

Pro tip: bake the runner version as a variable in your infrastructure code and expose it in metrics. Failing silently at registration can look like “no capacity available” when the real issue is a stuck agent.

When should you stay self‑hosted?

Stay self‑hosted when at least one of these is true:
• You need access to private networks, data planes, or hardware that can’t be exposed to hosted runners.
• Your cache reuse yields repeatable 30–50% time savings versus clean hosted environments.
• You can maintain >70% average runner utilization without developer pain (queue times, flakiness, security drift).

Otherwise, adopt a hybrid approach—and put short‑lived, compute‑heavy jobs on the now‑cheaper hosted runners.

A few gotchas teams hit in week one

• Idle minutes still cost on self‑hosted if a job is waiting on network or external services.
• Artifact bloat is a silent biller. One repo blowing 20+ GB/day across parallel jobs adds up quickly.
• macOS jobs rarely pencil out on self‑hosted unless you’ve industrialized Apple hardware at scale.
• Old Node.js or Java toolchains can waste minutes compiling from scratch. If you’re still on Node 20, plan your move before April 30, 2026. Our guide lays out the risk envelope: what breaks and how to upgrade fast.

Benchmarks to watch after you change anything

• Median queue time per label (goal: low and stable).
• Median/95th job duration (subtract checkout/install time to isolate compute).
• Cache hit ratio and cache size trends per repo.
• Artifact GB‑hours by repo (and by job).
• Runner utilization (per pool) and failed registration counts.

Where ByBowu can help

If you’re weighing a hybrid architecture or need an outside view on cost/performance tradeoffs, our team has shipped these migrations across SaaS, fintech, and mobile backends. Start with our concise checklist: self‑hosted runner pricing: what to do now. If you need hands‑on help, explore our CI/CD modernization services and see client outcomes in our 2026 pricing playbook.

What to do next (this week)

• Pull last quarter’s usage and model costs with and without self‑hosted minutes.
• Enforce runner v2.329.0+ at image build time; redeploy pools.
• Move two CPU‑bound jobs to hosted runners as a pilot; compare cost and time to green.
• Add path filters to your top three minute‑eating workflows.
• Cut artifact retention and size; measure GB‑hours saved.

Zooming out: the new fee doesn’t kill self‑hosted. It just ends the illusion that coordination is free. Treat placement as an engineering decision, not a habit. Do the math, run the pilots, and write down the policy so it outlives the calendar quarter.