In version-control systems, a monorepo ("mono" meaning 'single' and "repo" being short for 'repository') is a software-development strategy in which the code for a number of projects is stored in the same repository. This practice dates back to at least the early 2000s, when it was commonly called a shared codebase. Google, Meta, Microsoft, Uber, Airbnb, and Twitter all employ very large monorepos with varying strategies to scale build systems and version control software with a large volume of code and daily changes. A related concept is the monolithic application, but whereas a monolith combines its sub-projects into one large project, a monorepo may contain multiple independent projects. Advantages There are a number of potential advantages to a monorepo over individual repositories: Ease of code reuse Similar functionality or communication protocols can be abstracted into shared libraries and directly included by projects, without the need of a dependency package manager. Simplified dependency management In a multiple repository environment where multiple projects depend on a third-party dependency, that dependency might be downloaded or built multiple times. In a monorepo the build can be easily optimized, as referenced dependencies all exist in the same codebase. Atomic commits When projects that work together are contained in separate repositories, releases need to sync which versions of one project work with the other. And in large enough projects, managing compatible versions between dependencies can become dependency hell. In a monorepo this problem can be negated, since developers may change multiple projects atomically. Large-scale code refactoring Since developers have access to the entire project, refactors can ensure that every piece of the project continues to function after a refactor. Collaboration across teams In a monorepo that uses source dependencies (dependencies that are compiled from source), teams can improve projects being worked on by other teams. This leads to flexible code ownership. Limitations and disadvantages Loss of version information Although not required, some monorepo builds use one version number across all projects in the repository. This leads to a loss of per-project semantic versioning. Lack of per-project access control With split repositories, access to a repository can be granted based upon need. A monorepo allows read access to all software in the project, possibly presenting new security issues. Note that there are versioning systems in which this limitation is not an issue. For example, when Subversion is used, it's possible to download any part of the repo