1.8× faster than GitHub Actions, and the two rows where they beat us.

I have not been very vocal about it, but for a good amount of recent times I got fed up with the current state of Git providers, and at first, as every person in our industry rightfully does, I started sulking and ranting to myself, to my colleagues, friends and family…

That is until I decided to do something about it and as I don’t really like to make a complete fool of myself I decided to try and make a platform I could be proud of, with everything I need :

• git-features (push, pull, clone, fork, merge requests…) - of course;
• security (sso, mfa, commit signing…) - “duh”;
• a completely functional OCI-compatible registry - why not;
• an integrated AI code review system (I’ve been less than enthusiastic about nearly every solution I’ve tried so far);
• more importantly a “better” CI system;

With these goals in mind I launched rickub.com last monday, my take on a new public git platform, now what does that mean to do “better” : my goal is to provide a cleaner, faster, more energy-efficient platform than any system on the planet.

It starts with the interface, more reactive, lighter, but my deep focus for the last months has been to do better on the Continuous Integration platform and DevXp than what is currently considered the baseline pushing the boundary using technologies like MicroVMs.

Now every CI provider claims to be fast. None of them publishes numbers you can check, because there is no official benchmark for CI platforms — nothing like SPEC exists for build infrastructure. So I drafted one, pointed it at my own platform and at GitHub Actions, and ran the same race eleven times.

The harness is public: rickub/ci-bench, mirrored on ogirardot/ci-bench. The protocol is simple: same repository, same commits, same workflows to both platforms, alternating which platform receives each push first, and records per-step timings for every run. All 22 runs succeeded; no step was skipped, no run excluded. Good thing being, you can run it yourself if you want.

What I measured

Two tiers of work, all pinned, all cold, every job on both platforms starts from a fresh machine, which is structural on both sides, not a tuning choice:

• First a naive micro tier: a Rust build (cold and warm) + tests, a Docker image build, and a runner probe (single-core CPU loop, scratch-disk write/read).
• Real-world tier: I picked four real life projects, cloned inside the timed window and built at pinned tags:
  • ripgrep 15.2.0 (Rust) — release build of a daily used tool;
  • SQLite 3.45.1 (C) — a real configure && make -j of the amalgamation
  • TypeScript 5.9.3 (Node) — npm ci plus a compiler build
  • Guava 33.7.1 (Java) — a Maven build of the guava module

Honestly i wanted to bench on building ClickHouse, but a full build needs dozens of cores and ~100 GB of disk… no shared-runner tier on any provider runs that. Next time maybe.

Apples to apples

Let’s compare what we can compare: vCPU count. rickub's large runner (4 vCPU / 8 GiB) against GitHub's ubuntu-latest (4 vCPU / 16 GiB). Our infrastructures are not the same: rickub runs on our own bare-metal MicroVM fleet in Europe (those are Ryzen 9700X); GitHub runs on Azure's standard fleet.

It’s a choice, but this choice has its consequences on the end user experience, so the measurements reflect that.

First results

I measured the medians over 11 interleaved rounds per platform and the p95 are in parentheses where it matters:

Three of the four real projects finished about twice as fast on rickub, and the whole pipeline (every step, both tiers) ran 1.8× faster end to end at the median.

The variance story is stronger than the medians: rickub's eleven runs span 128–138 s wall-clock; GitHub's span 197–342 s, and one round waited 80 seconds in queue 🤦 before a single instruction ran.

The row we lost — a learning opportunity

Guava is the only step GitHub won, by 6%, and it is the most informative number in the table. A single-module Maven build is dominated by dependency download and single-threaded compilation, so the least CPU-bound workload we tested.

Where a build is not CPU-bound, the gap closes or flips, that’s great news! We still have work to do and a great idea on where to go next.

Equally: our storage-burst probe (a 2 GiB sequential write) came out comparable between platforms, a cache-warm 2 GiB burst is noisy and mostly measures luck.

A build is of course dominantly impacted by pure CPU/RAM/Disk speed but it’s also affected by the caching infrastructure around it — how much depends entirely on how good your cold path is.

The cache experiment — where GitHub wins, and what it taught us

We also ran a controlled cache round: the same Rust workload with actions/cache restore/save (identical key and paths on both platforms, hit flags read from the action itself, ten warm rounds after a prime):

Two honest results. GitHub's cache service is faster than ours right now — 1.8× at restore — and that's a real gap for now. And the counterintuitive one: on rickub, the cache bought nothing — the warm build equals the cold build, because a 5-second cold build has nothing left to halve; the whole cache dance nets out to +2.7 s of restore overhead.

So interestingly, no cache is better than a slow cache infrastructure—another proof of today’s teachings :

What this does and doesn't prove

It proves: for these five workloads, on this hardware, at this hour, jobs on rickub finished ~1.8–2.3× faster at the median, the advantage held at p95, and jobs started 5.5 s sooner after push — with one bare-metal node that a single person can rent for the price of a dinner.

It doesn't prove: that a young fleet sustains GitHub's planetary queue depth (queue waits like that 80-second p95 happen everywhere, including here); that your workload behaves like ours — which is exactly why the harness, the traces, and every run id are public. (The cache round closed the other gap: warm-path behavior is now measured too — see the cache section above.)

What's next

I’m honestly very happy with these first results, rickub now has more than 40 users and they’ll be the judge in the end, I’ll strive to provide them with the best DevXp I can and will keep improving to provide the best bang-for-the-buck possible.

I already had plans to provide a new dedicated “faster” runner class to do even better on raw performance, but after all these results I now know how central caching must be in the next steps.

Run it yourself and prove me wrong, when you do I can guarantee we’ll do better.