Where code actually lives — one repository or many — sounds like a minor organizational preference, but it has real, direct consequences for how CI/CD pipelines have to be designed, and it’s a genuinely contested trade-off among engineering organizations, not a settled question with one obviously correct answer.
What each model actually means
A monorepo stores multiple projects, services, or applications within a single version-controlled repository, sharing one history and one set of top-level tooling. A polyrepo approach — the more traditional default — gives each project or service its own independent repository, with its own history, its own versioning, and typically its own CI/CD configuration.
Google is among the most publicly documented large-scale monorepo users; its engineering research paper on why Google stores billions of lines of code in a single repository lays out the reasoning and trade-offs the company found at that scale, and is a useful primary source for understanding the model’s real benefits and real costs, not just its reputation in either direction.
What a monorepo makes easier
Atomic cross-project changes. A change that touches multiple services — updating a shared library and every service that depends on it — can be made and merged as a single commit, tested together, rather than requiring coordinated, sequenced changes across several separate repositories.
Dependency consistency. It’s straightforward to guarantee every project is using the same version of a shared internal library, because there’s only one version of that library present in the repository at any given time — no risk of different services silently drifting onto different, incompatible versions.
Visibility. Code across the whole organization is discoverable and searchable in one place, which can meaningfully reduce duplicated effort and make it easier to find and reuse existing work.
What a monorepo makes harder
CI/CD tooling has to scale. Running the full test suite for every change, across a repository containing many projects, doesn’t scale — a monorepo generally requires build and CI tooling sophisticated enough to determine which specific projects a given change actually affects, and run only the relevant tests and builds, rather than everything. This is genuinely more complex tooling than a small, single-project pipeline needs, and it’s a real, ongoing engineering investment, not a one-time setup cost.
Access control gets coarser by default. Repository-level permissions in most version control systems apply to the whole repository; a monorepo containing everything means finer-grained access control across different projects has to be layered on deliberately, rather than falling out naturally from separate repositories with separate default permissions.
What a polyrepo makes easier
Independent versioning and release cadence. Each project can be versioned — following a scheme like semantic versioning so dependents know exactly what a version bump implies — tested, and released entirely on its own schedule, with CI/CD pipelines, discussed generally in What Is CI/CD?, that are simple and scoped to exactly that one project.
Clear ownership boundaries. A separate repository per service maps naturally onto separate team ownership, with access control that’s simple by default because it’s already scoped to exactly what that team owns.
What a polyrepo makes harder
Cross-repository changes require coordination. A change spanning multiple services — the same kind of change a monorepo handles atomically — has to be sequenced manually across separate repositories and separate pull requests, with real risk of one repository’s change landing before a dependent repository’s change is ready, causing exactly the kind of inconsistency a monorepo structurally avoids.
Dependency drift. Without deliberate tooling to prevent it, different services can end up on different, inconsistent versions of a shared internal library, each pinned independently, quietly diverging over time.
There’s no universally correct answer
Both models are used successfully at large scale by different organizations, which is itself evidence that the right choice depends on team structure, how tightly coupled the actual services are, and how much investment an organization is willing to make in either sophisticated monorepo tooling or disciplined cross-repository coordination — not on one model being objectively superior. The practice that makes either one work well, GitOps among them, has to be deliberately designed around whichever structure is actually in place, rather than assumed.
Key takeaway
A monorepo trades simpler cross-project coordination and dependency consistency for CI/CD tooling that has to scale to a large, shared codebase; a polyrepo trades that tooling complexity for the harder problem of manually coordinating changes that span multiple repositories. Neither choice is free, and the right one depends on how coupled your actual services are and how much you’re willing to invest in the specific tooling each model demands.
This article explains general repository strategy concepts; the right choice depends heavily on your organization’s specific structure and scale. See our disclaimer.