A monorepo is a single version-control repository containing the source for multiple projects, libraries or services. The opposite approach, one repository per project, is often called a polyrepo. Google and Meta are well-known users of very large monorepos, and tools such as Nx, Turborepo, Bazel and pnpm workspaces support smaller ones.
Why it matters
A monorepo makes it easy to share code, change a library and all its consumers in one commit, and keep dependency versions consistent. One search covers everything and refactors can span projects atomically. The costs are tooling and scale: builds and tests must run only for what changed, access control is coarser and repository size can strain version-control tools. A monorepo is a repository layout, not the same thing as a monolith, since it can contain many independently deployed services.
Example
repo/
apps/
web/
api/
packages/
ui/
config/A change to packages/ui triggers a build of web only if web depends on it, which a monorepo tool works out from the dependency graph.
Common mistakes
- Running every test on every commit instead of only affected projects.
- Mixing up monorepo with monolith.
- Letting packages depend on each other's internals.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.