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
Imagine keeping every family recipe in one big binder instead of separate notebooks in different kitchens. Everyone can find and reuse any recipe, and updating a shared ingredient list updates it for everyone.
At work
A monorepo puts a company's code projects in one place. Teams can reuse each other's code easily, and a change that affects many projects can be made and reviewed in a single step.
At home
In separate repositories, updating a shared library means updating it, publishing a new version, and then updating every project that uses it. In a monorepo, you change the library and its users together in one commit.
At work
Monorepos need tooling for selective builds and tests (only what a change affects), caching of build results, code ownership rules for reviews, and scalable version control. Common tools include Bazel, Nx, Turborepo, and Pants, plus Git features such as sparse checkout.
At home
Without smart tooling, every change triggers every build and test, and the repository slows to a crawl. In my opinion, adopting a monorepo without investing in build tooling just moves the pain from dependency management to waiting for CI.
At work
Benefits include atomic cross-project changes, consistent dependency versions, and easier large-scale refactoring. Costs include tooling investment, access control challenges for sensitive code, and noisy commit history. Polyrepos suit organizations that value independent release cycles. Hybrid approaches, 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.