Live data from Hacker News

Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

warpbuild.com

1–10 of 89 posts

Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#1
Hey HN, I’m Surya and I’m excited to show you WarpBuild!

WarpBuild provides fast, secure `x86-64` and `arm64` Github actions runners. This speeds up your workloads by 30%, at half the cost, and takes ~2mins to get started.

We’ve been seeing pretty good results since we opened up signups a week ago and I’ve shared some numbers publicly here [1].

Currently, we support linux runners for Github organizations (not personal accounts) and MacOS support is coming soon (~Jan).

The way the runners work is deceptively simple: Runners are assigned to hardware that is ideal for build workloads with fast NVMe disks and high single-core performance.

The runners are allocated on VMs, not containers. This provides faster performance and enables use cases requiring (1) nested virtualization for running firecracker and other hypervisors, (2) k8s without relying on kind, and (3) Android emulators on `arm64` instances in test workflows.

We also have released a Github Action called `Action-Debugger` that allows you to SSH into a running workflow for simplifying pesky debugging[2].

The same set of packages that you’d get on Github hosted runners are pre-configured (on x86-64 runners) so everything works out of the box with no modifications needed.

A very minor detail that I’m rather proud of, and I’d love your thoughts on improving it further, is the onboarding flow for the ease of moving workflows to WarpBuild. We’ve also put in a lot of effort into making the workflow start up time where we are as fast or faster than Github.

[1] https://x.com/suryaoruganti/status/1732932591001735419 [2] https://github.com/WarpBuilds/action-debugger, h/t to tmate

Making builds faster by providing optimal hardware and configurations across CI providers is the first step in our mission to make build engineering better.

I’d love your feedback on the product and thoughts on other CI pain points we could solve to enable better collaboration and developer experience.

Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds
warpbuild.com

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#2
How do people rationalize using a service like this for anything other than toy projects? Sending your source code to some service, then adopting and executing the artifacts it produces, means this is the central, most critical aspect of your security story. For real projects it doesn't stand even a moment's scrutiny.

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#3
Congrats on the launch! I've spent some time recently with great success speeding up CI for my teams via alternate actions runners, and the increase in efficiency that comes with dramatic reductions in build times is worth it. When the cost is the same (or less), it's an absolute no-brainer.

How do you differentiate from BuildJet, which takes a similar approach?

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#5

Congrats on the launch! I've spent some time recently with great success speeding up CI for my teams via alternate actions runners, and the increase in efficiency that comes with dramatic reductions in build times is worth it. When the cost is the same (or less), it's an absolute no-brainer. How do you differentiate from BuildJet, which takes a similar approach?

We've had a few customers migrate over from BuildJet because WarpBuild is in active development. For instance, we are adding support for macos runners in Jan.

Our mission is broader than just fast runners - it's about better CI dev ex. This includes surfacing recommendations that would optimize build times, insights into the critical paths of workflows and more.

We're also investing in tooling to overcome issues that currently exist, such as an action to ssh into running workflows for easy debugging.

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#6
post #4

How can it be 30% faster when the vast vast majority of the execution time is spent doing things like building, bundling, etc. ie things independent of the action runner performance. Edit: Never mind. Misunderstood what this is.

Thanks for taking the time to read my little launch and glad that it's clearer what we do.

Try it out if you can, you will like the results :-)

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#7
It’s a great idea. I’d want even faster though, GitHub Actions are quite a bit slower than my Air M2. If you spun up a fleet of top of the line Hetzner boxes I’d expect it’d be 100% faster than actions. 30% faster for half cost is just a bit too small of a gain to make the leap.

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#8
post #2

How do people rationalize using a service like this for anything other than toy projects? Sending your source code to some service, then adopting and executing the artifacts it produces, means this is the central, most critical aspect of your security story. For real projects it doesn't stand even a moment's scrutiny.

A lot of smaller teams/companies don't really care about security, sadly... and is this really that different from Github Actions, CircleCI, Vercel, anything...?

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#9
> The runners are allocated on VMs, not containers. This provides faster performance

What? I haven't benchmarked it lately, but containers should (almost?) always have less overhead and better performance than VMs

(I do agree that VMs are far more flexible and let you do privileged things; it's only perf that I question)

Re: Show HN: WarpBuild – x86-64 and arm GitHub Action runners for 30% faster builds

#10

Congrats on the launch! I've spent some time recently with great success speeding up CI for my teams via alternate actions runners, and the increase in efficiency that comes with dramatic reductions in build times is worth it. When the cost is the same (or less), it's an absolute no-brainer. How do you differentiate from BuildJet, which takes a similar approach?

I migrated from BuildJet this week because BuildJet’s caching is broken. Installing cached pnpm dependencies takes about 12s on GitHub and WarpBuild runners. It takes 2m on BuildJet, which is about half the runtime, effectively negating the cost savings of BuildJet over GitHub.

I reported this issue to BuildJet over a week ago and haven’t received any response.

Post reply on HN