Software Engineering Glossary

Monorepo

Also known as: Monolithic Repository Mono-repo Single Repository

A monorepo is a version control layout where many projects, libraries, and services live in one repository instead of one repo per project or team. In a trunk-based, single-version monorepo, a change can update a library and all of its callers in one logical commit. It is a source layout, not a runtime architecture: the code can still ship as many independent services.

Key Takeaways

  • One repository contains many projects. The opposite layout is a polyrepo, where projects live in separate repositories.
  • Common benefits include atomic cross-project changes, coordinated dependency versions, and easier large-scale refactoring.
  • The cost is tooling. Builds, tests, search, and access control have to scale with the whole tree, not with one small project.
  • A monorepo is not a modular monolith. You can deploy hundreds of microservices from one repo, and you can split a monolith across many repos.

How It Works

  1. Projects sit in directories of one tree. Shared libraries can be referenced directly or managed through workspace-aware package tooling.
  2. Many monorepos use trunk-based development and short-lived branches, but the repository layout does not require a particular branching model.
  3. The build system tracks a full dependency graph so a change rebuilds only the targets that depend on it.
  4. Ownership files and visibility rules keep review and access scoped even though the code is in one place.

Where It Is Used

  • Google stores most of its code in one Piper-backed repository that engineers call google3.
  • Meta, Microsoft, and Uber also run large monorepos, each with custom source control or Git scale-out tooling.
  • Smaller teams use Git plus Bazel, Nx, Turborepo, or package workspaces to get a slice of the same benefits.

Related glossary terms