Bazel
Bazel is a build system that models code and dependencies as a graph of hermetic targets and rebuilds only what changed.
Definition
Bazel is a multi-language, multi-repository build and test system that describes builds in a declarative graph of targets with explicit inputs and outputs. Each action is hermetic and sandboxed, so identical inputs yield identical outputs and results are cacheable locally and remotely. Bazel tracks the exact dependency graph and only rebuilds targets whose inputs changed, which keeps incremental builds fast in large monorepos.
Context and scope
Adopted at monorepo scale across many languages and teams, where conventional build tools become slow and unreliable due to hidden dependencies.
Common misconceptions
- Bazel just caches builds — caching follows from hermetic, deterministic actions; without that property, caching would be unsafe
- It is only for huge companies — smaller teams adopt it for correctness and reproducibility, but the setup cost is real
- Hermetic means no network ever — hermetic means declared inputs; a build that uses the network declares it and is cached differently
Anti-patterns
- Calling out to undeclared files or the network from a rule, breaking hermeticity and cache correctness
- Copying whole directories as inputs, so every trivial change invalidates a wide rebuild
- Treating BUILD files as boilerplate rather than as the dependency model they are
Related concepts
Authoritative source
What it is
Bazel describes a build as a graph of targets, each with declared inputs, outputs, and a rule for producing them. It executes actions in sandboxes that see only their declared inputs, hashes inputs and command lines to cache outputs locally and remotely, and consults the graph to decide what is stale. Because the graph is explicit and actions are hermetic, a result computed once can be reused anywhere the same key appears, including across machines and repositories.
Why it matters
Conventional build tools infer dependencies from timestamps and directory layout, which breaks down in a large tree with many languages. Hidden dependencies cause wrong incremental builds, and full rebuilds become unavoidable and slow. Bazel makes dependencies explicit, so incrementality is sound and correctness is not traded for speed. The same model enables remote caching and remote execution, letting a fleet share work.
How to use it well
Keep actions hermetic and declare every input; an undeclared read or write silently breaks cache correctness and can produce wrong results. Define targets at a useful granularity so that a change invalidates a small set, and give rules precise inputs rather than whole directories. Invest in remote caching early to share results across developers and CI, and treat BUILD files as the living dependency model of the repository, reviewed with the same care as code.