Public-alpha adoption surface
glorious.build
Pooled, cache-first Bazel + Nix build & runner substrate.
One substrate, from a laptop to a cluster
glorious.build is built around a single claim: a small, highly-mobile developer machine and a large, complex server substrate should share one build fabric — not two parallel setups you keep in sync by hand.
It is remote-first by design. A developer machine attaches to the same Bazel remote-cache, Nix binary-cache, and — for eligible target classes — the same REAPI remote-execution capacity the cluster uses, instead of reproducing the build farm locally. Bazel and Nix are both first-class, by role: Nix for hermetic, bit-reproducible toolchains and dependency closures; Bazel for the action graph, the remote cache, and remote execution.
Why one substrate
A serious build needs three things at once: autoscaling runner capacity, remote execution (REAPI actions dispatched to a shared executor, not your laptop), and a complex dependency graph that resolves identically on every machine that touches it. Most teams
stitch these together per repository — a runner fleet here, a cache bucket there, a bespoke toolchain in each MODULE.bazel. Those seams are where correctness and cache reuse break. This substrate exists to make
the three compose on one shared fabric instead of being re-stitched in every repo. Remote execution is
proven today for eligible target classes — forced-remote, with worker provenance and nonzero remote
processes — not broad/default RBE; the docs carry the verbatim
evidence.
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
Open, reproducible, governable, replaceable
State-of-the-art here means engineering credibility, not adjectives — the properties that make a build fabric supportable in the Linux-Foundation sense rather than a single-vendor black box.
Reproducible
Nix builds are content-addressed and bit-for-bit deterministic; the same inputs produce the same outputs on the laptop and in the cluster.
Replaceable
The substrate boundary is a checked invariant (a substrate-boundary conformance validator): swapping the underlying provider changes endpoint values and credentials and nothing else. GloriousFlywheel proves conformant today; consumers adopt the check in their own lanes — not estate-wide.
Governable
Endpoints are environment authority, never baked into source; enrollment is an explicit contract; authority fails closed (no valid OIDC identity, no access to pooled capacity).