Side by side
MonorepovsPolyrepo
What is the difference between a monorepo and a polyrepo?
Updated 3 min read8 differences
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.
Monorepo
A monorepo is a single version control repository that holds the code for many projects, such as several apps, services, and shared libraries, managed together.
Read the page on MonorepoPolyrepo
A polyrepo is a setup where each project, service or library lives in its own version control repository, with its own history, pipeline and release cycle.
Read the page on PolyrepoMonorepo and Polyrepo compared
| 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 |
The difference, explained
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.
Which one should you use?
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.
Renaming a prop in a shared UI library, both ways
# Monorepo: change the shared library and its users in one commit
git switch -c rename-button-prop
# edit packages/ui/Button.tsx and every caller in apps/web and apps/admin
npx turbo run test --affected # test only the projects the change touches
git commit -am "refactor(ui): rename Button's kind prop to variant"
git push # one pull request, reviewed and merged as a whole# Polyrepo: release the library, then upgrade each consumer separately
cd ui-kit
git commit -am "feat!: rename Button's kind prop to variant"
npm version major && npm publish # 3.0.0, a breaking release
cd ../web-app # a separate repository, its own pull request
npm install @acme/ui-kit@3.0.0
# update the callers, then commit and open a pull request
cd ../admin-app # and again here, whenever that team is readyReaders ask
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.