Monorepo
A monorepo is a version-control repository that contains many distinct projects (services, libraries, tools) with shared tooling and atomic cross-project changes. Adopters include Google, Meta, and Uber; tooling has matured rapidly (Bazel, Nx, Turborepo, Pants) but the model still has real trade-offs against polyrepo.
Monorepo arguments: atomic cross-project refactors (rename an API and update every caller in one commit), uniform tooling (one CI config, one lint config), and visibility into every other team's code. Polyrepo arguments: independent versioning, smaller blast radius for permissions and CI, faster clone/checkout times, and clearer ownership boundaries. The dirty secret: most monorepo wins require investment in custom tooling (incremental builds, dependency graphs, partial CI) that small teams underestimate. The pragmatic threshold: teams with >50 engineers and high cross-team dependency see strong monorepo wins; teams with <20 engineers usually don't.
Related terms
- Polyrepo
A polyrepo (or multirepo) architecture puts each service or library in its own version-control repository, with independent CI, versioning, and release cadences.
- Continuous deployment
Continuous deployment automatically deploys every change that passes the test suite into production — no human gate between merging code and serving traffic.
- Semantic versioning (semver)
Semantic versioning is the package-versioning convention MAJOR.