thanks for the love! we are actively considering supporting other providers.

Hey, WarpBuild founder here. While it makes it harder for us to communicate this, we're still, we're still faster and cheaper even after the $0.002/min self hosting tax.

Overall costs go up for everyone but we remain the better option.

it's rather egregious that it is a "per minute" tax rather than a $0.002 per job.

Here are the practical implications and considerations to optimize for cost, given the new pricing. These are generic and ensure you think through your workflows and runners before making any changes.

1. Self-hosting runners or using WarpBuild/blacksmith runners is still cheaper Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) or using WarpBuild/... runners remains the cheaper option.

2. Prefer larger runners If your workflow scales with the number of vCPUs, prefer larger runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.

For example, using actions-runner-controller with heavy jobs running on 1 vcpu runners is not a good idea. Instead, prefer a 2vcpu runner (say) if it runs the job ~2x faster.

3. Prefer faster runners All else being equal, prefer faster runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.

For example, if you're self-hosting on aws and using a t3g.medium runner, it's better to use a t4g.medium runner since the newer generation is faster, but not much more expensive.

4. Prefer fewer shards If you have a lot of shards for your jobs (example: tests on ~50 shards), consider reducing the number of shards and parallelizing the tests on fewer but larger runners.

5. Improve job performance This is not new advice, but it's now more important than ever because of the additional GitHub self-hosted runner tax.

6. Use GitHub hosted runners for very short jobs For linters and other very short jobs, it's better to use GitHub hosted runners.

Hope this helps. Note: I'm the founder of WarpBuild. I'm biased, but the points above hold.

Thanks for the WarpBuild love!

Performance is the primary lever to pay less $0.002/min self hosting tax and we strive to provide the best performance runners.

With these changes, three things hold:

1. Services like blacksmith and WarpBuild (I'm the founder) are still cheaper than GitHub hosted runners, even after including the $0.002/min self-hosting tax.

2. The biggest lever for controlling costs now is reducing the number of minutes used in CI. Given how slow Github's runners are, or even the ones on AWS compared to our baremetal processor single core performance + nvme disks, it makes even more sense to use WarpBuild. This actually makes a better case for moving from slow AWS instances running with actions-runner-controller etc. to WarpBuild!

3. Messaging this to most users is harder since the first reaction is that Github options make more sense. After some rational thought, it is the opposite.

Overall - it is worse for Github users, but options like blacksmith and WarpBuild are still the better option.

"WarpBuild are still the better option."

what makes you think they won't hike the control plane price again? They can turn this knob arbitrarily to put you out of business.

The statement regarding the better option is as it stands today and does not account for all possible futures.

Reg. hiking it again, they'd have to either be extremely anti-competitive and selectively apply the pricing OR apply the hike uniformly by about double the current value to match our pricing while making it completely unviable for any large co to use self-hosted github actions in the first place.

I checked the WarpBuild website and got excited because the header in the menu says you have macOS Intel runners, but then you click through and it doesn't seem to be so?

Right now at my company our biggest complaint are macOS Intel runners from GitHub which somehow take 15+ minutes to provision and are the slowest of the bunch.

I can assure you WarpBuild has Mac runners that work very well. When I first switched GH only offered 1 Mac runner and it was horribly slow. Literally cut my build times in half by changing 1 line in my workflow file to use the WB runner.

Nowadays GH has more sizes by WB continues to beat them in price and performance.

It’s highway robbery what GH charges for the crap they provide. I can highly recommend WarpBuild for Mac (and Linux) runners.

I was talking specifically of macOS Intel runners. The sibling comment from the founder confirmed they don't have them.

We only have macos arm64 (M-series) runners. Can you point me to the intel reference so I can fix it?

Hover the top nav. Under "CI Runners" it's says:

macOS Runners Apple Silicon and Intel support

fixed it - sorry about that.

With these changes, three things hold:

1. Services like WarpBuild (I'm the founder) are still cheaper than GitHub hosted runners, even after including the $0.002/min self-hosting tax.

2. The biggest lever for controlling costs now is reducing the number of minutes used in CI. Given how slow Github's runners are, or even the ones on AWS compared to our baremetal processor single core performance + nvme disks, it makes even more sense to use WarpBuild. This actually makes a better case for moving from slow AWS instances running with actions-runner-controller etc. to WarpBuild!

3. Messaging this to most users is harder since the first reaction is that Github options make more sense. After some rational thought, it is the opposite.

ah! a fellow futurama lover, i see you

The lever that matters the most with the new $0.002/min tax is to reduce the number of minutes consumed.

Given that GitHub runners are still slow as ever, it actually is a point in our favor even compared to self-hosting on aws etc. However, it makes the value harder to communicate <shrug>.

Thanks for the email and the reminder that we can use fewer shards with larger runners.

Hey - thanks for the WarpBuild love!

Given github ran 11.5 billion mins of actions in 2025, and most of them would've been on self-hosted runners, this move makes some sense from their POV.

However, this is still an... interesting... move, especially after bitbucket got all that hate a few weeks ago for doing something similar.