What Is a Monorepo? | Vantage

Monorepo A monorepo (monolithic repository) is a single version-controlled repository that holds the code for multiple distinct projects, services, or packages. All teams commit to the same repository, sharing tooling, build configuration, and dependencies. This contrasts with a polyrepo approach where each service or project lives in its own repository. Companies like Google (Piper), Facebook (Mercurial), and Microsoft (GVFS) have operated at extreme monorepo scale. Tools like Nx, Turborepo, and Bazel manage build performance in large monorepos.

Why monorepo matters

The fundamental trade-off is atomic cross-project changes versus team autonomy. In a monorepo, changing a shared library and all its consumers in a single commit is atomic and safe. In a polyrepo, the same change requires coordinating releases across repositories, creating version incompatibilities and delayed integration. For closely coupled services — a platform with multiple apps sharing a design system and API types — a monorepo is dramatically simpler. For independently deployed services owned by different teams, a polyrepo gives teams the autonomy to own their release cadence.

How it works

All projects live in subdirectories of a single repository. Shared code lives in packages/ or libs/ directories. Build tools understand the dependency graph between packages and only rebuild affected packages when code changes. CI runs targeted tests — only the services that depend on changed code are retested. Versioning strategies differ: some teams version all packages together (lockstep), others version independently (each package has its own version). Access control at the directory level can simulate team ownership within a shared repo.

Common mistakes

• Mixing tightly and loosely coupled services in the same monorepo — services that deploy independently on different cadences create noise for each other

• No build caching — a monorepo without caching is a monorepo where every CI run rebuilds everything, which does not scale

• No clear ownership model — without CODEOWNERS or directory-level policies, everything belongs to everyone and nothing belongs to anyone

• Treating a monorepo as a single deployable unit — services in a monorepo should still deploy independently

• Not investing in tooling — a monorepo without proper build orchestration (Nx, Turborepo) becomes slower as it grows