Amazon Brazil Build System

Amazon has described Brazil as the build system that supported its internal service oriented engineering model long before monorepos became fashionable. The problem it addressed was not just compiling code. It was coordinating thousands of independently owned packages without forcing every team to move in lockstep.

In a micro repository world, each team owns its own source and publishes versioned build artefacts. That gives teams autonomy, but it creates a dependency management problem immediately. If service A depends on library B, and library B depends on runtime package C, every build needs a consistent picture of which versions belong together. Brazil tackled this by making dependency declarations explicit and by building against version sets rather than against whatever happened to be latest at the moment.

A version set is essentially a curated map of package names to exact versions. A team can have a private version set for development and testing, while a broader shared set represents versions that are safe for wider use. When a package upgrade is introduced, it is not automatically visible everywhere. It has to be merged into the relevant version set. This slows change down slightly, but it prevents one team from accidentally breaking everyone else by publishing a new incompatible dependency.

The local build flow starts from a package manifest that declares source inputs, dependencies, major version constraints, and build behaviour. Brazil resolves that manifest into a directed acyclic graph, fetches the exact dependency versions from the chosen version set, and then generates whatever language specific configuration the underlying compiler or build tool needs. In other words, the developer interacts with a higher level packaging model, while Brazil handles dependency resolution and reproducibility.

That reproducibility is the important operational feature. If a build succeeds in a given version set, Amazon wants another engineer or a remote package builder to be able to reproduce the same output later. That requires controlled inputs, deterministic dependency selection, and isolation from ambient machine state. Public talks about Brazil often emphasise snapshotting and repeatability for exactly this reason: a large company cannot debug production rollouts if every rebuild silently picks up different libraries.

Remote builders extend the same idea. Instead of trusting each laptop, a central build service can rebuild packages in standard environments for specific target platforms and architectures. The resulting artefacts are versioned and published back into the package ecosystem. This makes compliance, caching, provenance, and deployment automation much easier than ad hoc local builds.

The tradeoff is that autonomy is not free. A strict version set model introduces coordination overhead when many teams want the same upgrade. Cross cutting migrations can take time because each consumer has to accept a new dependency version into its set. The system also depends on disciplined package metadata. If teams declare dependencies loosely or hide build inputs in scripts, reproducibility degrades quickly.

Brazil is interesting because it shows a different answer to the same scaling problem that monorepos solve. A monorepo gives you one source tree and often one global revision. Brazil instead kept repositories separate and made the dependency graph first class. The core lesson is that large scale build systems are really change management systems. Compilation is the easy part. The hard part is deciding which versions are allowed to coexist, how builds stay reproducible, and how teams can move quickly without turning dependency updates into organisational chaos.