On this page
Monorepo vs Polyrepo: Which Should You Use?
A monorepo holds all projects in one repository; a polyrepo splits them. Compare the trade-offs for sharing code, CI, and team autonomy.
Quick answer
- A monorepo keeps many projects in one repository; a polyrepo gives each project its own.
- Monorepos make cross-project changes and code sharing easy; polyrepos make teams and deployments independent.
- For a solo or small team, a monorepo is usually the right default.
The two strategies compared
| Attribute | Monorepo | Polyrepo |
|---|---|---|
| Repos | One for everything | One per project |
| Cross-project changes | One atomic commit | Coordinated across repos |
| Code sharing | Direct, easy | Via published packages |
| CI/CD | One pipeline, more complex | Independent per repo |
| Access control | Coarse (whole repo) | Fine (per repo) |
| Team autonomy | Less | More |
When to choose each
Choose a monorepo when you’re a small team, when projects change together, or when you want to share code and make atomic cross-project changes without versioning friction. Choose a polyrepo when you have independent teams, different release cadences, or strong isolation and access-control needs per project. Google’s monorepo and countless microservices-using-polyrepo orgs are the canonical examples of each end.
The trade-off
A monorepo trades repository simplicity for tooling complexity: at scale you need specialized build systems to avoid rebuilding and testing everything on every change. A polyrepo trades code-sharing ease for boundary management: sharing code means publishing and versioning packages, and cross-repo changes need choreography.
Where this bites vibecoders
AI agents increasingly work across many files at once, and a monorepo suits that: one repo gives the assistant the whole context in one place, and one commit can touch frontend, backend, and shared code atomically. The vibecoder’s mistake is usually over-splitting early — a repo per microservice for an app that’s really one product. Start with one repo and split only when a boundary earns it.
Where AI coding assistants get this wrong
- Splitting a small app into many repos because “microservices need their own repos.”
- Ignoring that a monorepo’s build must scale, and generating one that rebuilds everything.
- Sharing code by copy-paste in a polyrepo instead of a versioned package.
- Making cross-repo changes with no plan for coordinating releases.
Checklist
- Start with one repo; split only when a real boundary exists.
- In a monorepo, make builds incremental so one change doesn’t rebuild all.
- In a polyrepo, share code through versioned packages, not copy-paste.
- Match release cadence to the strategy you choose.
- Consider the assistant’s context: monorepos give it the whole picture.
FAQ
Is a monorepo one big codebase?
Yes in the sense of one repository, but it can still be organized into well-separated projects and packages. A good monorepo has clear boundaries within the single repo, aided by tools like Nx, Turborepo, or Bazel.
What tools help with monorepos?
Nx and Turborepo (JavaScript) and Bazel or Pants (polyglot) provide incremental builds, caching, and dependency graphs so a change only rebuilds what’s affected. They’re what make large monorepos viable.
Does a monorepo hurt deployment?
Not necessarily — you can deploy individual projects from a monorepo independently; CI just needs to detect which projects a change affects. The coupling is in the repository, not necessarily in the deployment.