Pricing Changes for GitHub Actions

Original Article ↗ Hacker News Discussion ↗

New Pricing Change & Justifications

  • GitHub will charge a $0.002/minute “platform” fee on all Actions workflows, including self‑hosted runners; public repos remain free.
  • Many see it as paying per-minute to use their own hardware, especially galling since the fee matches the cheapest GitHub-hosted runner’s per‑minute rate.
  • Defenders argue the control plane (orchestration, logs, job status, marketplace integration) has real costs and was effectively subsidized before.
  • Critics counter that orchestration is relatively cheap, storage is already billed separately, and per‑job pricing would better match costs than per‑minute billing.

Impact on Self‑Hosted & Third‑Party Runners

  • This materially changes unit economics for third‑party runner providers and cloud self‑hosting setups; examples show 30–50% effective CI cost increases.
  • Several such providers say they remain cheaper and faster than GitHub’s own runners even after the “self‑hosted tax,” but admit the optics are worse.
  • Some suspect the move is aimed less at true on‑prem self-hosting and more at undercutting competing managed runner services that were 3–10x cheaper.

Quality, Reliability, and Value Perception

  • Many describe Actions as brittle and flaky: slow job scheduling, slow shared runners, missed or out‑of‑order webhooks, hanging jobs, and long‑standing bugs.
  • There’s frustration that GitHub is monetizing self‑hosted usage before fixing long‑reported CI issues; some say they tolerated problems only because it was free.
  • Others report solid experiences with the runner binary itself and argue most fragility comes from workflows and orchestration.

Cost Calculations & Behavioral Effects

  • Examples range from solo founders facing ~$140/month new spend to orgs seeing $200–700/month increases or ~30% higher CI compute costs.
  • Suggestions to mitigate: make jobs faster, use bigger/faster runners to reduce minutes, reduce sharding, set aggressive timeouts, and keep very short jobs on GitHub‑hosted runners.
  • Some insist even a small fee is unacceptable “rent” on their own hardware; others note the absolute amounts are tiny relative to engineering salaries.

Alternatives and Migration Paths

  • Many discuss moving to or expanding use of: GitLab CI, Jenkins, Buildkite, CircleCI, Gitea/Forgejo with Actions (via act), Woodpecker, Tangled, OneDev, or fully custom webhook-based CI that reports via GitHub’s status API.
  • Several report already self‑hosting GitLab or Forgejo/Gitea successfully; others consider hosted non-profits like Codeberg or SourceHut (with caveats about uptime/feature gaps).
  • Some welcome the change as finally making room for non‑GitHub CI vendors again, after “free with the VCS” made it hard to compete.

Broader Reactions: Lock‑In, Enshittification, and CI Philosophy

  • A large portion of the thread frames this as classic “enshittification” and lock‑in: make it free, get everyone dependent, then charge once alternatives are weakened.
  • Microsoft’s history and other recent SaaS moves (including Bitbucket’s similar change) are cited as signs that the “VC‑subsidized free infra” era is over.
  • There’s side debate about whether small projects should even rely on cloud CI vs local builds; most working in teams argue CI remains essential for shared discipline, reproducibility, and long‑running tests.