On March 1, 2026, GitHub is introducing a new $0.002 per-minute cloud platform charge for self-hosted runner usage. While GitHub frames this as part of a broader pricing update that will benefit 96% of customers, the reality for users running their own infrastructure is quite different.

Update: GitHub Postpones Self-Hosted Runner Charges (December 2025)

Good news: GitHub has listened to community feedback and postponed the self-hosted runner charges that were scheduled for March 1, 2026.

In their announcement, GitHub acknowledged they “missed the mark with this change by not including more of you in our planning.” This is a significant win for the developer community and demonstrates that speaking up about unfair pricing actually works.

The Power of Transparency

While I’m glad GitHub has heard the community, this situation highlights why transparency matters. If GitHub had disclosed their actual costs for orchestrating self-hosted runners from the start, the conversation would have been very different.

Here’s what I’d like to see in GitHub’s “re-evaluation”:

Disclose actual costs: What does it actually cost GitHub to orchestrate builds on self-hosted runners? API calls? Webhook deliveries? Storage for logs? If these costs are real and significant, show us the data.

Align pricing with resource consumption: Per-minute charges for CPU time on customer-owned hardware never made sense. Pricing models based on actual GitHub infrastructure usage (API calls, webhooks, artifact storage) would be fair and justifiable.

Build trust through openness: Transparent, cost-based pricing is something most developers can accept. Hidden rationales and opaque pricing models breed skepticism.

What “Postponed” Really Means

Let’s be clear about what hasn’t changed:

  • The 39% price reduction for GitHub-hosted runners is still happening on January 1, 2026
  • Self-hosted runner charges are postponed, not cancelled
  • GitHub is “re-evaluating their approach” - which could mean anything

This is a reprieve, not a permanent reversal. The possibility of future pricing changes remains.

Your Voice Matters

GitHub has opened a community discussion to “collect more direct feedback.” This is your opportunity to help shape the outcome.

If you care about fair pricing for self-hosted runners, participate constructively:

  • Advocate for transparency about actual platform costs
  • Push for pricing models aligned with real resource consumption
  • Emphasize that self-hosted runner users already pay for their own compute

Community feedback changed GitHub’s timeline once. Continued engagement can influence the final approach.

The Bottom Line

This postponement is worth celebrating. It shows that community pressure and reasoned criticism can change corporate decisions.

But stay engaged. The fight for fair, transparent pricing in developer tools isn’t over - it’s just entering a new phase where we actually have a seat at the table.

If GitHub uses this time to build a transparent, cost-justified pricing model, everyone wins. That’s what I’m hoping for, and what I’ll be advocating for in their feedback discussion.

The analysis below was written on December 16, 2025, before GitHub’s postponement announcement.

The Announcement: Carrot and Stick

GitHub’s email announced two significant pricing changes:

The Carrot (January 1, 2026):

  • Up to 39% reduction in GitHub-hosted runner prices
  • Applies to all customers, varies by machine type
  • Makes GitHub’s infrastructure more cost-competitive

The Stick (March 1, 2026):

  • New $0.002 per-minute charge for self-hosted runners
  • Counts toward your plan’s included minutes
  • Effectively monetizes what was previously free

The strategic intent is clear: make GitHub-hosted runners cheaper while making self-hosted runners more expensive. The pricing change isn’t about cost recovery - it’s about steering users toward GitHub’s infrastructure.

The “96% Will See Lower Bills” Spin

GitHub claims that “96% of customers will receive a lower bill or see no change.” This sounds reassuring until you think about what it actually means:

What GitHub is really saying:

  • 96% of customers don’t use self-hosted runners at all, or use them minimally
  • That remaining 4% who invested in their own infrastructure? They’re about to get hit with new costs
  • Organizations that built CI/CD around self-hosted runners for cost control, compliance, or performance reasons are the target of this pricing change

It’s clever framing - bury the impact to a “small” percentage of users by highlighting price reductions for the majority. But that 4% likely represents many of GitHub’s most sophisticated users who built out self-hosted infrastructure precisely to avoid usage-based pricing.

Why This Pricing Model Is Problematic

Charging for Your Own Infrastructure

When you run a self-hosted runner, you’re already paying for:

  • Server hardware or VPS costs
  • Electricity and cooling
  • Network bandwidth
  • System administration and maintenance
  • Security and monitoring

GitHub provides the orchestration platform but none of the compute. Now they want to charge $0.002 per minute for builds running on your own hardware.

The Wrong Pricing Metric

Pricing models that would make sense:

  • API calls to GitHub’s infrastructure (actual resource consumption)
  • Webhook deliveries (actual bandwidth and processing)
  • Storage for artifacts and logs (actual storage costs)
  • Number of active runners (fixed platform cost)

Pricing model GitHub chose:

  • Per-minute charges for CPU time on customer-owned hardware

Charging for compute time on infrastructure GitHub doesn’t provide seems designed more to make self-hosted runners economically unattractive than to recover actual operational costs.

Why not charge per API call back to GitHub or other metrics based on actual GitHub infrastructure usage? Those would align with GitHub’s real costs. Charging per minute for customer compute suggests the goal is revenue generation, not cost recovery.

Real-World Cost Impact

Let me break down what this means for my own infrastructure:

My Current Setup:

  • 16 self-hosted runners
  • Average 30 minutes of usage per build
  • 80-160 builds per month
  • Running on Free plan (2,000 included minutes for private repos)

Cost Calculation:

1
2
3
4
5
6

Monthly usage (low):  16 × 30 × 80  = 38,400 minutes
Monthly usage (high): 16 × 30 × 160 = 76,800 minutes

If private repositories:
Overage (low):  38,400 - 2,000 = 36,400 minutes × $0.002 = $72.80/month
Overage (high): 76,800 - 2,000 = 74,800 minutes × $0.002 = $149.60/month

The Comparison: My VPS hosting for these runners costs less than $75/month. Under this pricing model, GitHub would charge me as much or more than my actual infrastructure costs - just for the privilege of orchestrating builds on my own hardware.

Important Note: Public repositories remain free. If you’re running builds for open source projects, this doesn’t affect you. But private repository builds will count against your plan’s included minutes.

Impact on Different User Segments

Free Plan Users (2,000 minutes/month included):

  • Heavy self-hosted runner users with private repos will quickly exceed free tier
  • Forced choice: pay for minutes, upgrade to Team plan, or migrate to alternatives
  • Many chose self-hosted specifically because Free plan has limited hosted minutes

Team Plan ($4/user/month, 3,000 minutes/month):

  • Small teams with private repos running distributed builds will see new costs
  • Organizations sharding builds across multiple runners will exceed included minutes faster
  • May need to upgrade to Enterprise or pay overages

Enterprise Users:

  • 50,000 minutes/month included, but large-scale CI/CD easily exceeds this
  • Organizations with hundreds of runners could face thousands in monthly charges
  • Precisely the users who chose self-hosted for cost control and compliance

The Strategic Play

Let’s be clear about what’s happening here:

Making Self-Hosted Less Attractive

By lowering GitHub-hosted runner prices by 39% while simultaneously introducing self-hosted runner fees, GitHub is:

  1. Narrowing the cost gap: Hosted runners become more price-competitive
  2. Eliminating the “free” advantage: Self-hosted no longer saves money for heavy users
  3. Shifting burden: Organizations must choose between new fees or migration costs
  4. Leveraging lock-in: Workflows built around GitHub Actions are expensive to migrate

The Vendor Lock-In Playbook

This follows a familiar pattern:

  1. Gain market share: Offer free/cheap service with generous limits
  2. Build ecosystem: Create integrations and tools that increase switching costs
  3. Introduce friction: Once users are committed, change pricing model
  4. Extract value: Count on migration pain to retain customers despite higher costs

We’ve seen this with cloud providers (AWS data egress fees), databases (MongoDB licensing changes), and now developer tools platforms.

What This Means for Different Users

Free Plan Users with Self-Hosted Runners

You’re the most affected group. With only 2,000 minutes/month included:

  • Heavy usage will quickly exceed the free tier
  • You’ll need to either pay overages, upgrade plans, or find alternatives
  • The “free” tier becomes a paid service for self-hosted runner users

Organizations with Compliance Requirements

Many organizations use self-hosted runners because they must:

  • Run builds in specific environments
  • Meet security/compliance requirements
  • Keep code and data within their infrastructure

These organizations now face a choice:

  • Pay GitHub’s per-minute fees despite owning the infrastructure
  • Migrate to platforms with more favorable self-hosted runner pricing
  • Absorb the cost as “tax” for staying on GitHub

Open Source Projects

Good news: public repository builds remain free. This doesn’t affect open source projects using GitHub Actions.

The Exodus Question

Will organizations leave GitHub Actions over this?

Factors favoring staying:

  • Migration costs and effort
  • Workflow lock-in (Actions-specific syntax, marketplace integrations)
  • “Boiling frog” effect - gradual price increases are easier to absorb
  • Strong GitHub ecosystem integration

Factors favoring migration:

  • Total cost exceeds value provided
  • Principle: refusing to pay for your own compute
  • Strategic: reducing vendor lock-in exposure
  • Economic: redirecting GitHub fees toward infrastructure improvements

For users on the free plan with heavy self-hosted runner usage, the math strongly favors evaluating alternatives. When you’re paying GitHub more than your VPS costs, the value proposition breaks down.

My Path Forward

Number of API calls, fixed costs for runners based on size - these make sense. They align with GitHub’s actual operational costs and would be predictable, measurable charges.

Being charged by the minute for CPU time on runners you own? That’s fundamentally different.

This feels less like cost recovery and more like a strategic move to make self-hosted runners economically disadvantageous compared to GitHub-hosted alternatives. The 39% price reduction on hosted runners isn’t coincidental - it’s part of a coordinated strategy to shift users to GitHub’s infrastructure.

For those of us sharding builds over many small machines - a best practice for fast, parallel CI/CD - this pricing model particularly penalizes efficiency. Organizations running dedicated CI/CD infrastructure will face bills potentially exceeding their actual infrastructure costs.

I’ve begun looking at Forgejo and Gitea as potential alternatives. Gitea Actions is designed to be compatible with GitHub Actions workflows - their documentation states “an unmodified GitHub Actions workflow should run on Gitea Actions without any issues.” Forgejo Actions is designed for “familiarity” rather than strict compatibility, requiring some minimal changes like moving workflows to .forgejo/workflows/ and adjusting runner labels. If the migration path is as straightforward as the documentation suggests, that significantly lowers the switching cost - exactly what makes reconsideration feasible.

Conclusion

GitHub’s pricing announcement is masterfully framed: headline a price reduction benefiting 96% of users while quietly introducing fees that significantly impact the 4% who invested in self-hosted infrastructure.

The combination of cheaper hosted runners and expensive self-hosted runner fees reveals the strategic intent: push users toward GitHub’s infrastructure where GitHub controls both the compute and the pricing.

For organizations on free or lower-tier plans with meaningful self-hosted runner usage, this represents a fundamental shift. What was once a cost-effective approach (use your own infrastructure to avoid consuming hosted minutes) now comes with its own per-minute charges.

The question each organization must answer: Is GitHub Actions’ orchestration worth paying more than your infrastructure costs?

For me, with projected bills of $70-150/month on the free plan - exceeding my actual VPS costs - the answer is increasingly unclear. The existence of platforms like Forgejo and Gitea that claim GitHub Actions workflow compatibility makes the migration path less daunting than it might have been.

When a platform charges you more than your compute costs just to orchestrate builds on your own hardware, it’s time to question whether that platform remains the right choice.

Final thought: This pricing change will likely accelerate the trend toward platform diversification. Organizations will think twice before committing entirely to GitHub Actions, recognizing that today’s “free for self-hosted” can become tomorrow’s metered billing. The lesson: avoid lock-in, design for portability, and maintain credible alternatives.

Frequently Asked Questions

When is the GitHub Actions pricing change happening?

The GitHub-hosted runner price reduction (up to 39%) takes effect January 1, 2026. The self-hosted runner charges originally scheduled for March 1, 2026 have been postponed while GitHub re-evaluates their approach based on community feedback.

How much will GitHub charge for self-hosted runners?

The postponed pricing was $0.002 per minute for self-hosted runners. This would have counted against your plan’s included minutes (2,000 minutes/month on Free plan, 3,000 on Team plan). The final pricing model is still under review.

Will the self-hosted runner charges apply to public repositories?

No. Public repositories remain free for both GitHub-hosted and self-hosted runners. The pricing changes only affect private repository builds.

What caused GitHub to postpone the pricing change?

Strong community feedback and backlash from developers. GitHub acknowledged they “missed the mark” by not including more community input in their planning. They’ve opened discussions to collect direct feedback before implementing any charges.

What are alternatives to GitHub Actions?

Popular alternatives include:

  • Forgejo Actions - Self-hosted, GitHub Actions compatible
  • Gitea Actions - Open source, GitHub Actions workflow support
  • GitLab CI/CD - Integrated CI/CD with free self-hosted runners
  • Jenkins - Traditional CI/CD with full control

How can I provide feedback on GitHub’s pricing?

GitHub has opened community discussions for feedback. Visit the GitHub Community Discussions forum to share constructive input on fair, transparent pricing models for self-hosted runners.

Sources

This post was created using Claude Code, with research, fact-checking, and structural assistance from Claude Sonnet 4.5.