# Monorepo vs Polyrepo

URL: https://softwaredictionary.org/compare/monorepo-vs-polyrepo
Last updated: 2026-10-06

In short: A monorepo keeps many projects in one repository so they can change together; a polyrepo gives each project its own repository, history and release cycle.

## What is the difference between a monorepo and a polyrepo?

A monorepo stores many related projects, such as apps, services and shared libraries, in one version control repository, usually in folders like `apps/` and `packages/`. A polyrepo setup, also called multi-repo, gives each project its own repository, with its own history, permissions, CI pipeline and releases. Both describe where code is stored, not how it runs.

The essential difference is how shared code moves. In a monorepo, a change to a shared library and to every project that uses it can land in one atomic commit and pull request, and everything always builds against the current version. In a polyrepo, the library is published as a versioned package, and each consumer upgrades in its own pull request when its team is ready; that gives teams independence, but versions drift apart and cross-cutting changes take many steps.

Each model needs tooling to scale. Monorepos rely on workspaces in npm, pnpm or Yarn, on build systems such as Nx, Turborepo or Bazel that cache results and run only the tasks a change affects, and on ownership rules such as a `CODEOWNERS` file. Polyrepos rely on package registries and on bots such as Dependabot and Renovate that open upgrade pull requests. Many organizations mix the two, with a few monorepos per product area.

A common misconception is that a monorepo means a monolith, or that microservices need a polyrepo. A single monorepo can hold dozens of independently deployed services, and a monolith can pull in libraries from other repositories. Another is that monorepos only suit giant companies; small teams often find one repository simpler, as long as CI builds only what changed.

| Aspect | Monorepo | Polyrepo |
| --- | --- | --- |
| Repositories | One for many projects | One per project, service or library |
| Cross-project change | One atomic commit and pull request | A new library release, then a pull request in each consumer |
| Shared code | Imported straight from the source, always at the current version | Consumed as versioned packages from a registry |
| Dependency versions | Usually one version of each dependency for everything | Each repository chooses; versions drift apart over time |
| Team independence | Lower: shared tooling, rules and main branch | Higher: own history, permissions, pipeline and releases |
| Access control | Everyone with access sees all code; `CODEOWNERS` sets reviewers by path | Set per repository, so code can stay private to a team |
| Tooling needed | Workspaces, plus Nx, Turborepo or Bazel to build only what changed | A package registry and bots such as Dependabot or Renovate |
| Scaling pain | Large clones, slower Git operations, CI that must skip unaffected work | Duplicated configuration, version drift, changes spread over many repositories |

## Choose Monorepo when

- Projects share a lot of code and often change together.
- Large refactors and dependency upgrades should land in one commit.
- One set of tooling, linting and CI configuration should apply everywhere.
- A small team works across the frontend, the backend and shared packages.

## Choose Polyrepo when

- Teams own separate services and release on their own schedules.
- Projects share little code, or share it through stable, versioned packages.
- Access must differ by project, for example for contractors or open-source parts.
- You want each repository small and need no extra build tooling.

## Frequently asked questions

**Is a monorepo the same as a monolith?**

No. A monolith is one application deployed as a unit; a monorepo is only a way of storing code, and it can hold many services that are built and deployed independently.

**Do big companies use monorepos?**

Some well-known ones do, including Google and Meta, with custom tooling built for that scale. Many others use polyrepos or a mix, so company size alone doesn't decide it.

**Can I move from a polyrepo to a monorepo?**

Yes. `git subtree` or `git filter-repo` can merge repositories while keeping their history, and workspaces then link the projects together. Teams usually move the most closely coupled projects first.

---

Software Dictionary: https://softwaredictionary.org/ · https://softwaredictionary.org/llms.txt