Public-alpha adoption surface
glorious.build
Pooled, cache-first Bazel + Nix build & runner substrate.
GloriousFlywheel is a VCS-agnostic, cache-first build and runner fabric for teams that use Nix and Bazel. It combines shared, capability-shaped runner pools, Nix binary-cache acceleration, and Bazel remote-cache attachment so that developer laptops and CI jobs run against the same substrate instead of every repository standing up its own one-off runner fleet.
The crux isn’t raw compute — it’s correctness. The goal is pooled build, test, and runner behavior that works the first time, through explicit enrollment into a shared cache and runner contract, instead of another standalone runner bolted onto a single repo.
Two ways to use it
Self-host — available now
Run your own implementation overlay of GloriousFlywheel against your own cluster, object storage, and credentials: shared runner pools, Nix cache acceleration, and Bazel remote-cache attachment, scoped to your org. This is the adoption path that works today.
Read the adoption docs →Pooled backend — pilot-gated
A shared, operator-run pooled cache and runner backend is the direction GloriousFlywheel is built toward — it is not a public, self-serve service today. It's available only as paid, invitation-only design-partner pilots.
Request a design-partner pilot →What’s ready now vs. planned
Ready now
Shared capability-class runner pools
Ready for pilot use
Nix binary-cache acceleration
Ready once cache trust is configured
Bazel remote-cache attachment
Ready once a remote cache endpoint is set
Local developer cache attach
Alpha — via an operator-provided profile
Planned / gated
Target-scoped Bazel remote-execution (RBE) proofs
Proof lane, per approved target class
Broad / default Bazel RBE
Product goal — not ready yet
Non-GitHub forge adoption
Staged — GitHub is the primary forge today
Pooled backend as a public, self-serve product
Commercial direction — paid design-partner pilots only