Monorepo
Also known as: mono-repo, monolithic repository
A monorepo is a single version control repository that holds many projects, such as apps, services, and shared libraries, rather than splitting each into its own repository.
Google, Meta, and Microsoft are famous for using them. While a monorepo makes it easy to share code and change many projects at once, it only works well with tooling that builds and tests just what changed.
Monorepo, explained at three levels
At home
Think of keeping every family recipe in one big shared binder instead of separate notebooks in different kitchens. Anyone can find and reuse any recipe, and if you change a shared ingredient list, you can fix every recipe that uses it at the same time. A monorepo is that binder for software: one storage location holding many projects' code together.
At work
A monorepo is a single version control repository holding many projects, such as apps, services, and shared libraries, instead of one repository per project. Google, Meta, and Microsoft are well-known users. Businesses care because teams can share code easily and make changes that affect many projects in one reviewed step, though the approach needs strong build tooling to stay fast as the code grows.
At home
In separate repositories, updating a shared library means changing it, publishing a new version, and then updating each project that uses it, one by one. In a monorepo, the library and everything that uses it sit side by side, so one commit changes them all together and tests run against the result. Folders separate the projects, and build tools work out which ones depend on which.
At work
Monorepos depend on build tooling that understands the dependency graph. Tools such as Bazel, Nx, Turborepo, and Pants work out which projects a change affects, build and test only those, and cache results so unchanged work is never repeated, often sharing that cache across developers and CI. Code ownership files route reviews to the right teams, and Git features such as sparse checkout let developers download only the folders they need.
At home
A monorepo makes every project's dependencies visible in one graph. That's powerful, because a tool can tell exactly what a change affects, but without that tooling every change triggers every build and test, and the repository slows to a crawl. While shared code is the big attraction, in my opinion adopting a monorepo without investing in build tooling just moves the pain from dependency management to waiting for CI.
At work
At large scale, monorepos need hermetic, reproducible builds, as in Bazel; remote caching and execution; and version control that scales, which is why Microsoft built VFS for Git and later Scalar, and Meta built Sapling. Benefits include atomic cross-project changes, a single version of each dependency, and easier large refactors. Costs include tooling investment, coarse access control for sensitive code, and noisy history. Hybrid setups with a few domain-level monorepos are common compromises.
Real-world examples
At home
Carlos maintains a website, a mobile app, and a shared design library for his small business. Moving them into one monorepo meant a colour change in the library updated both apps in a single pull request.
At work
Lena is an engineering manager at a Vancouver software company with 80 repositories. Updating a security library took weeks of coordinated pull requests. After moving core services into a monorepo with Nx, the same update took one afternoon.
How it compares
| feature | Monorepo | Polyrepo |
|---|---|---|
| Code location | One repository for many projects | One repository per project |
| Cross-project changes | One atomic commit | Coordinated changes across repositories |
| Tooling needs | Smart build and test tooling | Simpler per repository |
| Team independence | Lower, shared standards | Higher |
Monorepos favour consistency. Polyrepos favour independence.
For analysts
The monorepo debate is really about how much teams should share. I'd decide that first, based on how often changes span multiple projects, and then choose the repository structure that fits.
History & origin
Google has kept most of its code in one repository for decades; a 2016 paper by Rachel Potvin and Josh Levenberg described it holding billions of lines of code used by tens of thousands of engineers. Meta built similar infrastructure, and Microsoft moved Windows development into a giant Git repository in 2017, creating tools to make Git scale. Google open-sourced Bazel, a descendant of its internal build system, in 2015. In the JavaScript world, tools like Lerna, Nx, and Turborepo (acquired by Vercel in 2021) made monorepos popular for smaller teams. In my view, monorepos are an organizational choice disguised as a technical one: they favour shared ownership over team independence.