Monorepo and multirepo: definitions without false equivalence
| Criterion | Monorepo | Multirepo |
|---|---|---|
| Cross-project changes | One commit or PR can cover multiple projects | Usually multiple repositories, versions, and PRs |
| Dependencies | Easier centralization and shared rules | Greater version independence |
| CI | Needs graph-aware selection, caching, and scaling | Smaller natural scope per pipeline |
| Access | Path ownership through rules and review | Natural isolation at repository level |
| Tooling | More shared standards | More freedom per project |
| Releases | Can be independent but need orchestration | Naturally separate pipelines |
A monorepo is one repository that contains multiple logically separate projects such as applications, services, libraries, or tools. Multirepo, also called polyrepo, keeps those elements in separate repositories. Repository boundaries are source-management boundaries, not automatically deployment boundaries. [1][13][15]
A monorepo can therefore contain dozens of independently deployed services, while a multirepo setup can contain modules of one large system. Treating repository strategy as equivalent to monolith versus microservices leads to poor architecture decisions.
What Google research shows: both models have real advantages
Google research comparing engineers with experience in both monolithic repositories and multiple repositories found codebase visibility to be a major monorepo advantage. It helps engineers discover reusable APIs, find usage examples, and update dependent code during API migrations. Centralized dependency management was also valued. [1]
The same study identified multirepo advantages: greater toolchain flexibility, stronger access-control boundaries, and more stability between projects. The authors also stressed that repository tooling is a major factor in how engineers experience either model. [1]
Cross-project changes: the clearest practical monorepo advantage
When one interface change requires coordinated updates to backend, frontend, libraries, and tests, a monorepo can place the entire migration in one commit or pull request. Google lists the ability to update dependent code during API migrations as an important benefit of a shared repository. [1][2]
In multirepo, the same change often becomes a sequence: update the producer, publish a version, update consumers, and coordinate several pull requests. Automation can reduce the friction, but repository boundaries remain integration-process boundaries.
Dependencies and versioning: centralization versus independence
Monorepos make it easier to keep common dependency versions aligned and to reference local packages directly. Yarn Workspaces lets packages in one project reference one another, while Constraints can enforce dependency-version or `package.json` rules across the workspace. [13][14]
Multirepo gives each project more freedom over versions and upgrade timing, but common libraries can drift across repositories. This model works well when contracts are stable and artifacts are published through package registries or other controlled channels.
CI in a monorepo: rebuilding everything on every commit is the wrong model
Large monorepos should not run every test and build after every change. Nx `affected` uses Git history and the project graph to calculate the minimum set of projects impacted by a change and can skip unrelated work. [4]
Remote caching can share completed task results across developer machines and CI, while distributed execution spreads remaining graph nodes across machines. Bazel addresses the same class of problem through remote execution and caching for build and test actions. [5][7][8]
Multirepo CI: smaller natural scope does not mean zero coordination
In multirepo, a single pipeline naturally sees less code, making it easier to limit builds and tests to one project. That is a real advantage when services are weakly coupled and owned by separate teams.
The coordination cost appears when repositories depend on one another. A shared-library or contract change may require artifact publication, multiple repository updates, version compatibility work, and integration testing. Google research describes stability as a multirepo advantage while also highlighting visibility and automated migrations as monorepo strengths. [1]
Architectural boundaries: a monorepo without rules becomes a problem quickly
A shared repository should not mean unrestricted imports between every project. Nx can declaratively enforce module boundaries with project tags and dependency constraints, blocking unwanted imports and unplanned domain coupling. [6]
In multirepo, some boundaries exist physically because code lives in separate repositories. That still does not replace architecture: projects can remain tightly coupled through APIs, databases, queues, or shared libraries.
Access and security: multirepo often has the simpler model
GitHub assigns roles and permissions at repository level, so separate repositories map naturally to cases where teams or contractors should see different codebases. Repository roles range from Read through Admin. [11]
In a monorepo, CODEOWNERS and rulesets can require reviews for paths and teams, but these are ownership and approval mechanisms. If an organization needs hard separation of code visibility between groups, separate private repositories usually map more directly to the access model. [10][12]
Releases and deployment: one repository does not mean one release
Yarn describes workspaces as multiple packages within one project and explicitly notes that they can be deployed independently. Gradle multi-project builds also split systems into logical subprojects with their own dependencies and tasks. [13][15]
A monorepo can therefore have separate pipelines and versions for applications, services, and libraries. Multirepo gives this independence by default, but needs stronger automation when several releases must be coordinated as one product change.
Repository size and Git: very large monorepos require deliberate tooling
Google has described an internal monorepo containing billions of lines of code, but also emphasized the custom infrastructure used to support it. The example proves that monorepos can scale very far, not that such scale is free or appropriate for every company. [2]
Current Git provides `sparse-checkout` to reduce the working tree to a selected subset of tracked files. It is one tool for working with large repositories, although Git documentation still marks sparse-checkout behavior as experimental and subject to change. [9]
2026 tooling reduces the cost of both approaches
In JavaScript ecosystems, monorepos have native workspace support plus mature project graphs, caching, and affected-only CI. In the JVM ecosystem, Gradle supports multi-project builds, while composite builds can combine independent builds and develop them together without first publishing artifacts. [13][15][16]
That last point also matters for multirepo: separate repositories do not have to mean a completely disconnected local workflow. Composite builds are an example of preserving independent build boundaries while still testing projects together. [16]
AI coding agents add a new decision factor
Nx documentation from 2026 argues that coding agents benefit from monorepo-wide source context, a queryable project graph, fast affected-only verification, and enforced boundaries. Because Nx is a monorepo tooling vendor, this should be treated as a product perspective rather than independent proof. [3]
In practice, shared context can help an agent change a contract and its consumers in one task. Conversely, multirepo can reduce the amount of code and permission scope available to a single agent session. This is a new criterion, not a deciding argument by itself.
When to choose monorepo
Monorepo is especially attractive when applications and libraries change together frequently, many teams share components, and the organization needs atomic refactors and a visible dependency map. Google research supports these benefits through code visibility, API discovery, usage examples, migrations, and dependency centralization. [1]
The requirement is investment in module boundaries, selective CI, caching, code ownership, and automation. Without those controls, repository growth can simply move complexity from many repositories into one oversized pipeline. [4][5][6]
- Frequent cross-cutting changes across frontend, backend, and libraries.
- Heavy shared-code usage and common engineering standards.
- Need for atomic refactors.
- A unified or compatible toolchain.
- Willingness to invest in dependency graphs, caching, and selective CI.
- No hard requirement to hide most code from other internal teams.
When to choose multirepo
Multirepo is a strong choice when domains have clear boundaries, teams need independent toolchains, lifecycles, and permissions, and cross-project changes are relatively rare. Google research identified tool flexibility, access control, and stability as meaningful advantages. [1]
Another strong signal is code that has restricted visibility, separate compliance requirements, or a distinct contractor population. GitHub's repository-level role model supports this separation directly. [11]
- Strong team autonomy and separate lifecycles.
- Different languages, toolchains, and build processes.
- Strict access or compliance requirements.
- Rare changes spanning many projects.
- Stable contracts and mature version management.
- Independent pipelines matter more than one platform-wide dependency graph.
Hybrid model and a practical 2026 decision
| Situation | Default direction | Why |
|---|---|---|
| Frequent changes across several apps and libraries | Monorepo | Atomic refactors and shared dependency graph |
| Different teams must not see all code | Multirepo | Repository permissions simplify isolation |
| Teams require different toolchains and lifecycles | Multirepo | Less centralized standardization |
| Strongly shared platform and libraries | Monorepo | Better visibility and dependency centralization |
| Many small services | Depends | Shared-change frequency matters more than service count |
| Mixed domain, access, and technology requirements | Hybrid | Domain monorepos plus selected separate repositories |
The choice does not have to be binary. An organization can keep domain monorepos for tightly related products, separate repositories for security-sensitive or client-specific components, and shared packages distributed through registries. Gradle composite builds even demonstrate a technical model for developing independent builds together. [16]
Before migrating, measure cross-project change frequency, shared dependency count, CI duration, the number of repositories touched by a typical feature, access requirements, and release-coordination cost. Those numbers should determine repository topology.
