The Infrastructure
Operating Bazel as shared build infrastructure
Design, operate, diagnose, recover, and evolve shared Bazel services across remote caching, remote execution, CI, build-service operations, dependency delivery, supply-chain evidence, and releases.
A build that works on one laptop can still fail when developers and CI share caches, workers, result streams, and dependency services. At that point, a failure may belong to the Bazel client, authentication, the cache, a worker, CI orchestration, or an artifact source. The infrastructure owner's job is to trace that boundary and change it without putting every build at risk.
Follow One Action Across The Shared System
6.1 Shared Bazel Services starts with the builds people actually run: developer, presubmit, postsubmit, release, and maintenance. For each one, define the latency, correctness, and availability outcome that matters; decide whether it needs a shared cache, remote execution, both, or neither; then follow one action from the client through those services. A rollout is not ready until its affected users, failure signals, and fallback path are explicit.
6.2 Shared Remote Cache establishes trustworthy content and result exchange across clients. Identity, transport, access control, retention, and diagnosis must agree before a cache hit is useful. 6.3 Remote Execution Infrastructure adds shared workers only when measured actions benefit from them. 6.4 Execution Modes and Persistent Workers then coordinates remote, local, worker, and dynamic strategies instead of assuming that one execution mode fits every action.
6.5 Bazel CI at Scale applies those services to CI: affected-target selection must stay conservative, distributed work must still produce complete evidence, and reused runners must not leak state between builds. 6.6 Build Service Operations connects client and service traces so operators can classify a failure before retrying, recovering, adding capacity, or changing cost policy.
6.7 Build Supply Chain and Releases protects the other end of the path. It connects dependency intake, offline boundaries, reviewed updates, build identity, provenance, signing, policy checks, and publication. Fast execution does not compensate for an input or release handoff whose producer cannot be verified.
Add Infrastructure At The Observed Boundary
Read 6.1 Shared Bazel Services first; its action path and rollout criteria apply to every later section. Continue to 6.2 Shared Remote Cache for cache operations. Establish that cache model before 6.3 Remote Execution Infrastructure, then add 6.4 Execution Modes and Persistent Workers when local execution or persistent workers share the workload.
CI owners should pair 6.5 Bazel CI at Scale with 6.6 Build Service Operations. Dependency and release owners can enter 6.7 Build Supply Chain and Releases after the planning article and return to build-service operations for the services that carry those workflows. Use optional mechanisms only when a measured bottleneck or failure mode calls for them; a favorite backend, fleet size, or hit-rate target is not evidence that the build needs it.
Shared Bazel infrastructure starts from the build journey, traces actions and failures across service boundaries, and changes those services with a tested fallback. The same evidence may favor a remote system, local execution, or no new service at all.
The H Monorepo Handbook handbook applies these service boundaries to repository-wide ownership, workflow, testing, risk, platform, and delivery decisions.
