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 :)

Love xterm.js! We use it to stream logs and as an in-browser terminal for our upcoming CI[1]. It's blazing fast especially with the WebGL renderer turned on.

[1]https://buildjet.com

Yes, we do! We launched 20 days ago and should soon be ramen profitable.

Deploying copy fixes!

This is happening far too often with such a vital product of the GitHub stack.

Our whole business[1] relies on GitHub Actions functioning. It just sucks.

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

Yes, job runs in a KVM VM. Nested KVM is supported on the hypervisor, but KVM is not enabled by default in guest OS, due to we run a guest kernel for faster booting time. We will offer an option to enable kvm kernel module in the future.

The feature pull request has been there for over a year[1], it’s nice that’s it’s released!

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 - 2x the speed for half the price. Easy to install and easy to revert.

[1] https://github.com/actions/runner/pull/660 [2] https://buildjet.com/for-github-actions

Hey HN, We opened up signups last week for BuildJet for GitHub Actions.

We started with building a full CI with speed and the YAML config as a USP. We got 4x speed and a much better YAML config structure, but despite these improvements, we noticed that it was quite a hard sell for people to migrate to a new unknown CI.

With this in mind, we decided to build BuildJet for GitHub Actions that uses the same infrastructure but plugs right into Github Action as a "self-hosted" runner, which is automatically set up for you with OAuth. This resulted on average a 2x speed improvement for half the cost(due to us being close to the metal). Easy to install and easy to revert.

Check it out!

Disclaimer - incoming self promotion.

Actually, most points in the article are the basis on why we created BuildJet.

We initially tried to solve these annoyances by creating a CI with speed and the YAML config as a USP. We got 4x speed and a much better YAML config structure, but despite these improvements we noticed that it people had a mental barrier to migrate to a new unknown CI.

But like OP we always enjoyed the experience of using GitHub Actions, so with this in mind. We decided to build BuildJet for GitHub Action[1] that uses the same infrastructure but plugs right into Github Action as a "self-hosted" runner, which is automatically set up for you with OAauth. This resulted on average a 2x speed improvement for half the cost(due to us being close to the metal). Easy to install and easy to revert.

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

Awesome work!

If you want to cut the CI run time even further. I'd recommend BuildJet for Github Action. We give you managed high-performance CI runners, which cuts both your CI time and price in half.

We plug right into Github Actions, so it's just one line change in your yaml file.

https://buildjet.com/for-github-actions

TillyPay? https://tillypay.com/

We had the same kind of problem, where we saw our tests and builds take 20-30 minutes. We also noticed that our own machine could run the tests significantly faster, mainly due to that desktop CPU can easily boost the clock speed for intense work load. Comparably most CIs use Cloud VMs which hardly go beyond 3 GHz. We found this quite strange.

After some talk we decided to build a CI service based on this premise, i.e desktop CPU outform Cloud CPUs for the CI use case. After some months we managed to create BuildJet.

I would say it at minimum cuts the the build time in half and the best part is that it plugs right into Github Actions, just need to change one line in your Github Actions configuration.

If it sounds useful for you, check it out: https://buildjet.com

4.1M clicks about to go down. https://i.imgur.com/0pxHInh.png

Yeah, your right, slightly off topic, just a bit frustrated with the chrome people just suddenly reporting problems or the fact that the dashboard is very old.

Didn't know about the Publish API, thanks for the suggestion will check it out.

Managing chrome extensions can be so annoying. I created a Chrome extension a couple of years ago, and the Chrome Webstore Dashboard was so annoying and non-maintained. The Chrome API's are quite nice though.