GitHub Actions Tripled Capacity and Cut Prices 39% in 2026: The Honest Math on CI Minutes vs PaaS Builds

On January 1, 2026, GitHub cut the price of every hosted Actions runner by up to 39%, weeks after revealing that a backend re-architecture had tripled concurrent-job capacity to 71 million jobs a day. If you run a git-push PaaS — or you just pay both a CI bill and a platform bill every month — that combination forces a real question: with GitHub's compute this cheap, should the build step live in Actions at all, or still on the platform's own fleet?

The short version up front: for a typical small team (600 runs a month, 6 minutes each, Team plan), CI on GitHub-hosted runners costs about $3.60 a month past the free quota — down from $4.80 before the reset. A self-hosted runner on a fixed-cost Hetzner box breaks even against GitHub's 4-core meter at roughly 2,100–3,500 minutes a month, depending on the chip. And PaaS-native builds (Render: $25 workspace fee, 1,000 minutes included, $0.005 per minute after) are cheaper per minute than GitHub's standard runner — but teams that test on GitHub and build on the PaaS pay two meters for every push. The per-minute rate was never the deciding factor; rounding, cold caches, and the double-meter trap are.

What GitHub actually changed in January 2026​

Three things happened in quick succession, and they point in different directions:

• Hosted runners got cheaper on January 1, 2026. GitHub's December 2025 pricing update cut GitHub-hosted runner rates by up to 39% depending on machine type, with larger runners seeing the biggest relative reductions. Free minute quotas stayed the same, and public repositories stayed free. The old→new Linux rates tell the story:

• Capacity roughly tripled behind the scenes. GitHub's January 2026 enterprise roundup says Actions consumed 11.5 billion minutes in 2025 (up 35% year over year) and now handles 71 million jobs a day — triple pre-upgrade capacity — after a complete backend re-architecture. Capacity is still actively managed rather than solved: the August 2026 availability report describes moving a third of jobs off a constrained cluster to buy headroom. But the direction is unambiguous: GitHub is spending to make queuing rare.
• The self-hosted runner charge was announced, then shelved. The same December 2025 update introduced a $0.002-per-minute "cloud platform charge" for self-hosted runners starting March 1, 2026. Community backlash was immediate, GitHub postponed the change within days to "re-evaluate," and it never took effect: the current billing docs state plainly that Actions usage is free for self-hosted runners. That non-event matters more than it looks — it preserves the "GitHub orchestrates, your hardware executes" pattern at zero orchestration cost.

Net effect: GitHub is simultaneously the cheapest metered CI vendor for small teams and a free orchestrator for teams with their own hardware. That squeezes a PaaS build step from both sides.

Both meters, line by line: the monthly-cost comparison​

Take a concrete team: a private repo on the Team plan (3,000 included minutes a month, Linux minutes counting 1:1), running 600 workflow runs a month at 6 billed minutes each — 3,600 minutes total. PR checks plus main-branch deploys, roughly 30 runs per workday. Here is what that costs four ways, at three workload sizes:

How to read each column:

• GitHub-hosted 2-core applies the 3,000-minute Team quota first: at 3,600 minutes you pay for 600 ($3.60); at 10,000 you pay for 7,000 ($42). Before the reset those were $4.80 and $56 — the 25% cut on this SKU is real but small in absolute dollars for small teams.
• GitHub 4-core larger prices every minute at the metered rate — most teams burn their included minutes on standard runners first, so treat this as the conservative upper bound. And it overstates the true cost for parallelizable builds: a job that takes 6 minutes on 2 cores might take 3.5 on 4, so you buy fewer minutes at the higher rate. Expect 30–40% back on CPU-bound work.
• Self-hosted is a Hetzner cloud box at post–June 2026 prices: a CAX31 (4 shared Arm vCPUs, 8 GB RAM) at €20.99/month ($25), or a CPX32 (4 shared AMD vCPUs, 8 GB) at €35.49/month ($42). GitHub orchestration is $0. Breakeven against the hosted 4-core meter is ~2,100 minutes on Arm, ~3,500 on x86 — past your free quota, the box wins quickly and then wins by more every month. (Had the $0.002 self-hosted charge taken effect, it would have added just $7.20 at 3,600 minutes — annoying, not decisive.)
• PaaS-native is Render's meter: a $25/month Pro workspace includes 1,000 build minutes, overage at $5 per 1,000 ($0.005/min). At 3,600 minutes: $25 + 2,600 × $0.005 = $38. Note the curiosity the table exposes: $0.005 a minute is less than GitHub's $0.006 standard rate. The builders aren't spec-identical, so per-minute comparisons across vendors are approximate — but the PaaS step is not winning or losing on rate.

Two honest conclusions fall out of the table. First, below ~3,000 minutes a month, GitHub-hosted inside the free quota is $0 marginal and nothing beats it — not your own box, not the platform. Second, the interesting fight is between self-hosted-at-scale and PaaS-native in the 3,000–10,000 band, where the PaaS charges $38–70 for what a $25–42 box does — and where the hidden costs below decide more than the rates do.

What the per-minute rate hides​

Four mechanics move the real bill more than any 2026 price cut:

1. Per-minute rounding punishes short jobs. GitHub rounds every job up to the nearest whole minute. A lint job that runs 40 seconds bills a full minute; a matrix of twenty such jobs bills 20 minutes for 13 minutes of work. One monorepo's public cost audit found two sub-10-second jobs doing ~23 minutes of real work per 120 runs while billing 240 — roughly 35% of the entire bill for a git diff and an echo. Self-hosted runners and PaaS builds don't round; at high run counts with short jobs, rounding alone can exceed the whole self-hosted hardware line.

2. Ephemeral runners start every build cold. A GitHub-hosted runner is a fresh VM per job: no warm Docker layer cache, no warm package cache, no incremental build state unless you explicitly restore it from the cache service (10 GB per repo, with its own eviction behavior). Teams routinely report 2–4 minute dependency-install prefixes on every run. A self-hosted runner — or a PaaS builder with a persistent cache volume — amortizes that prefix toward zero. When half your 6-minute job is npm ci, the meter you're actually comparing is cache hit rate, not dollars per minute.

3. The double-meter trap: testing on GitHub and building on the PaaS. This is the pattern the "default CI layer" framing encourages: Actions runs tests, then a deploy hook fires the platform build. Each push now bills twice — test minutes on GitHub's meter, build minutes on the platform's. Split our typical 3,600 minutes evenly and that's $0 to GitHub (1,800 test minutes fit inside the 3,000-minute quota) plus $25 + 800 × $0.005 ≈ $29 to Render — versus $3.60 for doing everything on GitHub-hosted, or $25–42 flat for doing everything on your own box. Push past both quotas and the hybrid bills on both meters at once: the operationally pleasantest pattern is financially the worst of both.

4. Storage and side meters. Actions cache, artifacts, and Packages storage share pooled allowances with hourly accrual — delete on day 11 and days 1–10 still bill. Container images pushed per-build to a registry add storage and egress. None of this is new in 2026, but every "CI costs $X" spreadsheet that omits it understates by 10–20% at scale.

Which pattern for which team​

The table plus the hidden costs reduce to three if/then rules:

• If you fit in the free quota (~3,000 min/mo on Team, 2,000 on Free): run everything on GitHub-hosted standard runners. Marginal cost $0, zero hardware to babysit, and the 2026 capacity work means queues are rarer than they were. Don't build infrastructure to optimize a $0 bill.
• If you run past ~3,500 metered minutes a month with cacheable builds: put a self-hosted runner on a fixed-cost box (Arm first — the CAX31's ~$25/month breaks even earliest) and keep GitHub as the free orchestrator. You get warm caches, no rounding, and per-minute costs that fall toward zero as volume grows. The postponed $0.002 charge is worth watching — if it ever revives, re-run the breakeven — but today the orchestration is free.
• If you want one throat to choke: build on the PaaS. You're paying a premium over the $25 box at scale ($38–70 in our band), and you should demand something for it: atomic build-and-deploy, instant rollbacks, and preview environments per PR. If your PaaS gives you a bare build log and a meter, you're paying premium rates for commodity compute.

And the documented default — the integration a git-push platform should bless in its docs — is the split the meters already suggest: tests on GitHub inside the free quota, build-and-deploy atomic on the platform via a deploy hook. Tests are short, parallel, and quota-shaped; builds want warm caches and must stay atomic with the deploy anyway. Document the handoff (workflow step that curls the hook with the tested SHA), warn about the double meter outside quotas, and let heavy teams graduate to self-hosted runners without changing the handoff.

What a PaaS operator should do about it​

GitHub's 2026 moves read as a deliberate squeeze on the "CI vendor + PaaS" stack: cheaper hosted minutes pull small teams toward doing everything in Actions, while free self-hosted orchestration pulls heavy teams toward their own boxes. A git-push platform competing on per-minute build rates will lose to both — $0.005 already undercuts GitHub's $0.006 and it doesn't matter. The operator checklist that follows from the math:

1. Compete on cache, not rate. The build that reuses warm layers beats the build billed by the cheapest minute. Persistent per-app build caches are the feature; the meter is table stakes.
2. Never rebuild identical source. Content-addressed build skipping — same SHA in, same image out, no meter ticked — is the single biggest bill reduction available, and it composes with every pattern above.
3. Make the Actions handoff first-class. A deploy hook plus an official workflow snippet turns GitHub's free quota into your onboarding funnel instead of your competitor.
4. Keep build+deploy atomic. The one thing neither GitHub-hosted nor self-hosted gives a tenant is "this image is the thing now serving traffic, with one-click rollback." That atomicity is what the PaaS premium actually buys — price it, name it, and don't apologize for it.

GitHub spent 2026 making CI compute cheap and plentiful. That's good for everyone who pushes code — and clarifying for everyone who sells the step after CI. The platforms that thrive are the ones that stop charging for minutes and start charging for certainty.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.