Robots Atlas>ROBOTS ATLAS
Infrastructure

Monorepo

ActivePublished
Key innovation
Replacing many separate repositories with a single repository hosting multiple projects and an explicit dependency graph, enabling atomic cross-project changes and code sharing without publishing packages.
Category
Infrastructure
Abstraction level
Pattern
Operation level
SystemDeployment
Use cases
Developing large organizational codebasesSharing libraries across multiple applicationsAtomic changes spanning multiple packages at onceUnified CI/CD pipeline across many projectsMonorepos in AI/ML projects: shared libraries, data pipelines and model code

How it works

All projects live in a single directory tree within one repository. Dedicated tools (e.g. Nx, Turborepo, Bazel) analyse inter-project dependencies and build a task graph, so build, test, and lint operations run only for the projects affected by a change and their dependents. Task results are cached (locally and remotely), allowing unchanged work to be skipped. A single change can atomically modify several projects at once in one commit, with a shared CI pipeline validating the whole. Organizations with very large codebases additionally use specialized version-control systems that scale to billions of lines (Piper at Google, Sapling at Meta).

Problem solved

With many separate repositories (polyrepo), sharing code requires publishing and versioning packages, and a change spanning several projects fragments into many manually coordinated commits and pull requests. This causes context loss, duplicated configuration, and dependency-version drift. A monorepo addresses these by enabling atomic cross-project changes, a single source of truth for dependencies, and code sharing without the overhead of package publishing.

Components

Single version-control repositoryShared store of code for all projects

A single repository (e.g. Git) holding the entire organization's or product's code in one directory tree.

Project/package boundariesDivision into distinct, encapsulated units

Explicitly separated projects (applications, libraries, tools) with encapsulation, distinguishing a monorepo from mere code colocation.

Dependency graphExplicit relationships between projects

A model of inter-project dependencies used by tooling to determine what to build and test after a change.

Build system with cachingIncremental building and task execution

Tools (Nx, Turborepo, Bazel) that run tasks only for changed projects and cache results locally and remotely.

Evolution

2016
Google describes its monorepo in Communications of the ACM
Inflection point

The article by Rachel Potvin and Josh Levenberg, 'Why Google Stores Billions of Lines of Code in a Single Repository', popularized the large-scale monorepo.

Why Google Stores Billions of Lines of Code in a Single Repository (paper)

Hyperparameters (configurable axes)

Dependency graph granularityHigh

How fine-grained projects and their mutual dependencies are defined.

Build cachingHigh

Strategy for caching task results (locally and/or remotely), key to monorepo scalability.

Task orchestrationMedium

How build/test tasks are parallelized and scheduled based on the dependency graph.

Code ownership boundariesMedium

Ownership and permission rules (e.g. CODEOWNERS) defining team responsibility for parts of the monorepo.