Benchmark: Bazel builds 39.7x faster on Avrea than GitHub Actions
On GitHub Actions, a no-cache Bazel build takes 37 minutes 10 seconds. On Avrea, the same build, same 2 vCPU spec, one label change: 14 minutes 4 seconds without cache, 56 seconds with.
Why Bazel
Bazel powers CI at companies running enormous monorepos: tens of thousands of source files, multiple languages, aggressive caching. Building Bazel itself sits at the heavy end of that workload.
A Bazel build leans on every part of a runner at once. Compile steps use CPU. Link steps want RAM. And every action result reads from and writes to the remote cache, so a slow or rate-limited cache shows up directly in the build time.
How we ran the test
Built Bazel from source, with Bazel's remote cache enabled on the cached run. Both sides matched on paper:
| GitHub Actions | Avrea | |
|---|---|---|
| Runner label | ubuntu-24.04 | avrea-ubuntu-latest-2-vcpu |
| vCPU | 2 | 2 |
| RAM | 7.8Gi | 7.8Gi |
For the cached run, Bazel's --remote_cache pointed at Avrea's co-located cache, populated on a prior warm-up run and then read from. The GitHub Actions side didn't have a remote cache hooked up on either run. That's Bazel's default out of the box, and what most teams are actually running with.
We ran each configuration a few times and picked a typical run. Variance on Avrea was small: a few seconds on the cached runs, well under a minute on no-cache. GitHub Actions was noisier. Minute-level swings on the cold builds depending on which shared VM the job landed on.
Results
| GitHub Actions | Avrea | Speedup | |
|---|---|---|---|
| No cache | 37m 10s | 14m 4s | 2.6x |
| With cache | n/a | 56.1s | 39.7x |
Without caching, Avrea comes out 2.6x faster. With Bazel's remote cache pointed at Avrea's cache layer, a warm build finishes in 56 seconds. On the GitHub side there's no comparable cache in this test.
A quirk worth mentioning: Bazel's remote cache doesn't fully populate in a single warm-up run. The first run with caching enabled took 1m 3s, because some actions were still executing while cache writes were happening. The 56-second number is the run after that, with the cache fully primed.
Why it's faster
The hardware (the 2.6x)
A no-cache Bazel build is CPU-bound and disk-heavy. Compiler passes pin a single core. The build also churns through a big pile of intermediate object files.
Avrea's 2 vCPU runner is the same size as GitHub's on paper, but the hardware underneath is different. Sysbench single-core: ~6,500 events/sec vs GitHub's ~3,670. Disk writes: ~4 GB/s vs ~220 MB/s.
That's the 2.6x, before any caching gets involved.
The cache (the 39.7x)
Bazel's remote cache stores every action's output (compiled objects, linked binaries, test results), keyed by input hash. On a cached run, if the inputs haven't changed, Bazel reads the output back and skips the work.
Avrea's cache runs on the same infrastructure as the runners, so reads come straight off local NVMe. That removes the usual network-path bottlenecks: round trips to S3, rate limits, cold fetches. On a hash lookup, the restore is basically free.
On a fully-warm cache, what's left of the build is mostly Bazel walking the action graph and pulling outputs out of storage. The compiler barely runs.
Other benchmarks in this series
- Linux kernel (68x)
- Ghostty (27x)
- Kafka (6.6x)
- Next.js (142x)
- RisingWave (11.5x)
What Avrea is
Avrea is drop-in for GitHub Actions runners. Swap ubuntu-latest for avrea-ubuntu-latest and push.
Every run gets step-level CPU and memory metrics, searchable logs, and SSH into the live VM when you need to reproduce something. That last one matters with Bazel specifically: when a build wedges in a deep action graph, you want to poke at it, not rerun blind.
