{"slug": "1-8x-faster-than-github-actions", "title": "1.8x faster than GitHub Actions", "summary": "A new public Git platform called rickub, launched Monday by developer ogirardot, published a self-run CI benchmark claiming its large runner (4 vCPU / 8 GiB) is 1.8× faster than GitHub Actions' ubuntu-latest (4 vCPU / 16 GiB) across 11 interleaved rounds. The benchmark, harness public at rickub/ci-bench and mirrored at ogirardot/ci-bench, measured median build times including ripgrep 15.2.0 at 12.7 s versus GitHub's 28.8 s (2.3×) and SQLite 3.45.1 at 42.2 s versus 80.9 s (1.9×), with all 22 runs succeeding. rickub runs on the company's own bare-metal MicroVM fleet in Europe using Ryzen 9700X hardware, while GitHub runs on Azure's standard fleet.", "body_md": "# 1.8× faster than GitHub Actions, and the two rows where they beat us.\n\nI 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…\n\nThat 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 :\n\n- git-features (push, pull, clone, fork, merge requests…) - of course;\n- security (sso, mfa, commit signing…) - “duh”;\n- a completely functional OCI-compatible registry - why not;\n- an integrated AI code review system (I’ve been less than enthusiastic about nearly every solution I’ve tried so far);\n- more importantly a “better” CI system;\n\nWith these goals in mind I launched [rickub.com](/p/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.**\n\nIt 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.\n\nNow 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](https://www.spec.org/) 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.\n\nThe harness is public: **[rickub/ci-bench](https://rickub.com/rickub/ci-bench)**, mirrored on **[ogirardot/ci-bench](https://github.com/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.\n\n## [**What I measured**](#what-i-measured)\n\n**What I measured**\n\nTwo 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:\n\n- **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).\n- **Real-world tier** : I picked four real life projects, cloned inside the timed window and built at pinned tags:\n  - **ripgrep 15.2.0** (Rust) — release build of a daily used tool;\n  - **SQLite 3.45.1** (C) — a real`configure && make -j` of the amalgamation\n  - **TypeScript 5.9.3** (Node) —`npm ci` plus a compiler build\n  - **Guava 33.7.1** (Java) — a Maven build of the guava module\n\nHonestly 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.\n\n## [**Apples to apples**](#apples-to-apples)\n\n**Apples to apples**\n\nLet’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](/p/rickub.com) runs on our own bare-metal MicroVM fleet in Europe (those are Ryzen 9700X); GitHub runs on Azure's standard fleet.\n\nIt’s a choice, but this choice has its consequences on the end user experience, so the measurements reflect that.\n\n## [**First results**](#first-results)\n\n**First results**\n\nI measured the medians over 11 interleaved rounds per platform and the p95 are in parentheses where it matters:\n\n| step | GitHub | rickub | \n|---|---|---|\n| ripgrep 15.2.0 (Rust) | 28.8 s | **12.7 s** (2.3×) | \n| SQLite 3.45.1 (C) | 80.9 s | **42.2 s** (1.9×) | \n| TypeScript 5.9.3 (Node) | 47.3 s | **22.9 s** (2.1×) | \n| Guava 33.7.1 (Java) | **38.0 s** | 40.3 s (GitHub +6%) | \n| Rust cold build (micro tier) | 13.0 s | **5.0 s** (2.6×) | \n| Docker build (micro tier) | 5.8 s | **3.1 s** (1.8×) | \n| **startup:** push → job start | 9.8 s **(p95 80 s)** | **4.3 s****(p95 4.7 s)** | \n| end-to-end pipeline | 243 s (197–342) | **134 s** (128–138) | \n\nThree 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.\n\nThe 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.\n\n## [**The row we lost — a learning opportunity**](#the-row-we-lost-a-learning-opportunity)\n\n**The row we lost — a learning opportunity**\n\nGuava 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.\n\nWhere 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.\n\nEqually: 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.\n\nA 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.\n\n## [**The cache experiment — where GitHub wins, and what it taught us**](#the-cache-experiment-where-github-wins-and-what-it-taught-us)\n\nWe 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):\n\n| metric (warm rounds, n=10) | GitHub | rickub | \n|---|---|---|\n| cache restore (67 MB) | **1.50 s** | 2.66 s | \n| warm build | 7.8 s | **5.1 s** | \n| cold build (same workload) | 16.7 s | **5.2 s** | \n| warm ÷ cold | **0.47** | 0.98 | \n\nTwo 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.\n\nSo interestingly, no cache is better than a slow cache infrastructure—another proof of today’s teachings :\n\n## [**What this does and doesn't prove**](#what-this-does-and-doesnt-prove)\n\n**What this does and doesn't prove**\n\nIt 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.\n\nIt 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.)\n\n## [**What's next**](#whats-next)\n\n**What's next**\n\nI’m honestly very happy with these first results, [rickub](/p/rickub.com) 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](https://rickub.com/pricing) possible.\n\nI 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.\n\nRun it yourself and prove me wrong, when you do I can guarantee we’ll do better.\n\n### Newsletter\n\nStay updated with new articles.\n\n## Keep reading\n\n### For a new golden age of FOSS\n\nArguing that the current Generative AI trend is a chance for disrupting existing staled eco-systems with free software for the common good\n\nFeb 23, 2026\n\n### Reverse engineering now and then\n\nReverse engineering, hacking and cracking has a long tradition of being tedious and intensive - how has it changed with our new AI tools\n\nMar 11, 2026\n\n### Le Cloud n'est pas la martingale\n\nJe vois de plus en plus de devs et autre afficionados technolo-geek commencer à ne jurer que par le cloud, alors à défaut de présenter une vision partiale et totalitairement contre, ce que je ne suis...\n\nJun 8, 2012", "url": "https://wpnews.pro/news/1-8x-faster-than-github-actions", "canonical_source": "https://ogirardot.writizzy.blog/p/rickub-1-8-faster-then-github-actions", "published_at": "2026-09-14 07:51:52+00:00", "updated_at": "2026-09-14 08:02:50.813380+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools"], "entities": ["rickub", "GitHub Actions", "ogirardot", "ripgrep 15.2.0", "SQLite 3.45.1", "TypeScript 5.9.3", "Guava 33.7.1", "Azure"], "alternates": {"html": "https://wpnews.pro/news/1-8x-faster-than-github-actions", "markdown": "https://wpnews.pro/news/1-8x-faster-than-github-actions.md", "text": "https://wpnews.pro/news/1-8x-faster-than-github-actions.txt", "jsonld": "https://wpnews.pro/news/1-8x-faster-than-github-actions.jsonld"}}