suryao

Founder of WarpBuild here. We provide GHA runners that are much faster and about half the cost. This includes MacOS. Check us out.

https://warpbuild.com

Founder of WarpBuild here: we provide faster runners (also cheaper), and have some niceties around debugging workflows like ssh-ing into them, observability etc.

Ack. Will take a look.

Founder of WarpBuild here. We have faster compute: baremetal for amd64 workloads, AWS for arm64 etc.

We optimize for overall performance in real world jobs and have a broad selection of regions/OSes/arch available. There aren't any fixed subscription fees either.

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.

Small to mid sized OSS projects benefit heavily from this. There is a size beyond which the free runner sizes become insufficient, but the assumption is that some form of monetization is figured out by that time. For example, we have a lot of OSS projects using WarpBuild because performance and fast CI is important for productivity.

Without GitHub's free CI for public repos, the small projects and indies will get hit the hardest imo.

However, I do not know hard numbers to quantify the impact.

fixed it - sorry about that.

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.

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

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.

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>.

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.

Yep, the discussion there seems to be mostly around the pricing itself rather than what can be done about it (assuming users are still sticking with github).

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 is still cheaper than not Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) 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.

Note: I make WarpBuild, where we provide github actions runner compute. Our compute is still cheaper than using github hosted runners (even with the $0.002/min tax) and our runners are optimized for high performance to minimize the number of mins consumed. I'm generally biased, but I think the points 1-6 apply irrespective of WarpBuild.

I put together a draft of the levers that are available to control costs. Curious to know what other optimizations would make an impact to your org.

Founder of WarpBuild here. Our arm64 runners are ~2x faster than Blacksmith. This is because we use a newer generation of more powerful instances.

If you're building multi arch images, here is a page that may be useful: https://docs.warpbuild.com/docker-builders#multi-platform-bu...

We natively support multi platform builds in our drop in replacement action.

I've seen this pattern quite a bit with our users, and we've implemented "snapshots" for this.

It essentially makes a copy of your entire state of the runner, which you can then use in subsequent runs, with no concurrency limits.

This essentially automates out a lot of the work you're doing to make the jobs faster.

https://docs.warpbuild.com/snapshot-runners

We provide a product similar to Blacksmith.

For writing technical styled documentation, I've found fumadocs to be amazing.

It looks great out of the box and supports a product switcher, which can be used for maintaining related products or product versions. It also supports OpenAPI imports and API playgrounds.

The best part is that it is just a fully fledged (nextjs) app that is entirely customizable with relative ease. We just moved to it from Docusaurus and couldn't be happier.

Something like this may help by letting you ssh into the running instance so you can debug with the exact context: https://docs.warpbuild.com/tools/action-debugger

TLDR: disk is often the bottleneck in builds. Use 'fio' to get performance of the disk.

If you want to truly speed up builds by optimizing disk performance, there are no shortcuts to physically attaching NVMe storage with high throughput and high IOPS to your compute directly.

That's what we do at WarpBuild[0] and we outperform Depot runners handily. This is because we do not use network attached disks which come with relatively higher latency. Our runners are also coupled with faster processors.

I love the Depot content team though, it does a lot of heavy lifting.

[0] https://www.warpbuild.com

If you're building rust containers, we have the world's fastest remote container builders with automated caching.

You wouldn't really have to change anything on your dockerfile to leverage this and see significant speed up.

The docs are here: https://docs.warpbuild.com/docker-builders#usage

You might want to check out my product, WarpBuild[0].

We are fully usage based, no minimums etc., and our container builders are faster than others on the market.

We also have a BYOC option that gives 10x cost reduction and used by many customers at scale.

[0] https://warpbuild.com

There definitely are a ton of issues with GitHub actions. To add to the OP's list:

- Self-hosting on your aws/gcp/azure account can get a little tricky. `actions-runner-controller` is nice but runs your workflows within a docker container in k8s, which leads to complex handling for isolation, cost controls because of NAT etc.

- Multi-arch container builds require emulation and can be extremely slow by default.

- The cache limits are absurd.

- The macos runners are slow and overpriced (arguably, most of their runners are).

Over the last year, we spent a good amount of time solving many of these issues with WarpBuild[1]. Having unlimited cache sizes, remote multi-arch docker builders with automatic caching, and ability to self-host runners in your aws/gcp/azure account are valuable to minimize cost and optimize performance.

[1] https://warpbuild.com

This sucks for individuals and open source. For folks that have a heavy reliance on dockerhub, here are some things that may help (not all are applicable to all use cases):

1. Setup a pull through mirror. Google Artifact Registry has decent limits and good coverage for public images. This requires just one config change and can be very useful to mitigate rate limits if you're using popular images cached in GAR.[1]

2. Setup a private pull through image registry for private images. This will require renaming all the images in your build and deployment scripts and can get very cumbersome.

3. Get your IPs allowlisted by Docker, especially if you can't have docker auth on the servers. The pricing for this can be very high. Rough numbers: $20,000/year for 5 IPs and usually go upwards of $50k/year.

4. Setup a transparent docker hub mirror. This is great because no changes need to be made to pipelines except one minor config change (similar to 1). We wrote a blog about how this can be done using the official docker registry image and AWS.[2] It is very important to NOT use the official docker registry image [3] as that itself can get throttled and lead to hairy issues. Host your own fork of the registry image and use that instead.

We spent a lot of time researching this for certain use cases while building infrastructure for serving Github actions at WarpBuild.

Hope this helps.

[1] https://cloud.google.com/artifact-registry/docs/pull-cached-...

[2] https://www.warpbuild.com/blog/docker-mirror-setup

[3] https://hub.docker.com/_/registry