thinkafterbef

Finally proper stale-while-revalidate support!

JetKVM | Senior Fullstack Engineer | Remote (CET ±3) | Full-Time | Go / TypeScript / WebRTC | Open Source

JetKVM builds open-source KVM-over-IP hardware that lets you control any computer — BIOS and all — through your browser. After raising $6M on Kickstarter (the #3 most-backed tech project ever), we’re scaling production and software for tens of thousands of users.

We’re looking for a Senior Fullstack Engineer to work across our stack — Go, Node.js, React, and WebRTC — from backend APIs to low-level firmware integrations. You’ll shape architecture, improve video streaming and authentication, and ship features end-to-end in a small, fast-moving team. Open-source, async, and remote(CET+/-3).

Apply → https://jetkvm.com/careers

That's precisely what we will do!

You'll be able to customize the runner image however you want, and it will be running on very fast NVMe SSDs.

Disclaimer: Co-founder of https://buildjet.com/for-github-actions

While more cores can certainly help with certain types of projects, such as those that can be easily parallelized, this is not always the case. For example, web app projects won't benefit as much from additional cores.

Another important factor to consider is the single-core performance of each vCPU. Many server-class CPUs, such as those used by GitHub, are built with a very high-core count but with a very low single-core speed. In contrast, BuildJet uses consumer CPUs, such as the 5950x, which offer slightly less core count but an excellent single-core speed.

It's quite astonishing how slow "the cloud"/server-class CPUs can be, we compared my old MacBook Pro 2015 vs. a 2vCPU GitHub actions runner and the MBP 2015 won most of the time.

BuildJet's bet is that single-core performance is critical for a fast CI, and it appears that the self-hosting comments here on HN also agree.

(We're working our own CI, DM me if you're interested in the fastest CI on the market)

Yeah, it's kind of a trope by now. However, we felt it was justified when Google Lighthouse wanted to use BuildJet.

Oh, should probably add that to the docs. Anyway, they are 120 GB.

I'm a bit biased as one of the founders of BuildJet, but we solve this exact issue.

BuildJet for GitHub Actions, plugs elegantly into GitHub Actions. With 1-line change in your config, you get 2x speed for half of GitHub's price.

Check it out @ https://buildjet.com/for-github-actions

Hey founder of BuildJet here, With BuildJet for GitHub Actions, you can get up to 64 vCPU as a GitHub Actions runner. We plug right into your existing setup and have a significantly higher per core performance compared to the native runner.

Check us out here: https://buildjet.com/for-github-actions

Incoming shameless plug; if you don’t have to handle the hosting runners, but still to reap the benefits of having proper hardware (close to the metal). Check out BuildJet for GitHub actions[1] - 2x the speed for half the price. Easy to install and easy to revert.

[1] https://buildjet.com/for-github-actions

Nice wording with 'per core performance'. We had difficulties properly conveying this point in our product when comparing our CI runners[1] to GitHub Actions CI Runner. I will be using it in our next website update. Tack

[1]https://buildjet.com/for-github-actions

BuildKite lets you run their CI agents on your own hardware. Much like self-hosted runner in GitHub Actions. BuildJet for GitHub Actions is a managed service, where we provide the hardware and manage it for you.

Yeah, you're right, there is a tool called act[1] that lets users test the GitHub Actions CI runs toward their local machine. The implementation looks very similar to GitHub Actions official runner, e.g use the identical provisioning scripts[2]. It is a very nice tool but serves a different purpose than us.

Regarding general testability with GitHub Actions, I'd recommend checking out the tmate action[3], which lets you debug your CI run with SSH.

[1] https://github.com/nektos/act

[2] https://github.com/actions/virtual-environments

[3] https://github.com/mxschmitt/action-tmate

Hey, Parallelism can solve a subset of CI performance issues, but in our experience, it tends to increase complexity and not improving performance that much.

Regarding security, just like the default GitHub Action runners, BuildJet for GitHub Actions isolates each job in its own VM, with no shared states between jobs. The virtualization layer is based on Linux KVM, VMs are NATed behind a shared IP address, and the host machine runs all disks on full disk encryption. We will put a full security concept out on our website at a later stage.

The 4x faster came from our first attempt - writing a complete CI (UI + infrastructure). The performance improvements mainly came from good hardware, a more aggressive cache on dependencies, and a docker layer cache.

The 2x improvements is referring to our latest product BuildJet for GitHub Actions, which is a plug-in runner for your existing GitHub Action pipeline.

I hope that clarified it.

Hey! I think our thesis of the product is that GitHub Actions is good, but not fast and we fix that. Personally, I've had to wait for CI to finish when wanting to run tests before hot-fixing something on production - a faster CI would've been great.

Founder here! I'm more than happy to answer any questions that you might have :)