Monorepo vs Polyrepo for CI/CD

Monorepo or many repos. CI/CD trade-offs.

Monorepo

The monorepo versus polyrepo decision shapes how an engineering organization works for years. The two approaches trade off different things: shared tooling versus team autonomy, atomic changes versus independent lifecycles, holistic coherence versus per-service isolation. Each has companies that have built large successful engineering organizations on it; each has companies that have struggled with it. The right choice depends on the org's specific structure, scale, and culture.

What monorepo offers:

• Atomic cross-service changes.: A change that affects multiple services lands in a single PR. The PR updates the shared library, the calling services, the tests, all in one commit. The atomicity prevents the half-deployed state where some services have the new behavior and some have the old.
• Shared tooling investment.: Build tooling, test tooling, deploy tooling, all built once for the whole monorepo. The investment is amortized across every service in the repo. Teams using individual repos rebuild similar tooling per repo, often inconsistently.
• Best for tight integration.: Services that change together, depend on shared libraries with frequent updates, and need to remain in sync benefit from monorepo. The cost of staying in sync is paid by the build system, not by manual coordination across teams.
• Refactoring at scale.: Renaming a function across 50 services is one PR in a monorepo. In a polyrepo it is 50 PRs across 50 repos coordinated across many teams. The monorepo makes large-scale refactoring tractable; the polyrepo makes it expensive.
• Examples: Google, Meta, Microsoft, Twitter (historical).: The largest engineering organizations on the planet generally use monorepos. The pattern scales; the tooling investment is justified at large scale; the operational benefits of unified tooling outweigh the costs.

Monorepo is a real architecture choice, not a default. The investment to make it work at scale is substantial; the benefits compound when the investment is made.

Polyrepo

Polyrepo is the alternative: each service has its own repo. Each repo has its own CI, its own deploy pipeline, its own dependency graph. The model is decentralized; teams operate independently within the bounds of their service.

• Independent lifecycles.: Each service evolves on its own schedule. Team A can ship to their service today; Team B can pause shipping to theirs for two weeks; both decisions are local. The independence is what makes polyrepo work at smaller scale where coordination overhead is the bigger problem.
• Isolated CI.: Each repo's CI runs only when that repo changes. The build does not cascade across the entire codebase. CI runs are fast because they cover one service. This is the operational benefit that monorepos work hard to replicate.
• Best for team autonomy.: Teams that want to control their own tech stack, their own deploy cadence, their own tooling can do so without coordinating with other teams. The autonomy is the cultural benefit of polyrepo; some organizations value this above the integration benefits of monorepo.
• Service boundaries are explicit.: The repo boundary is the service boundary. There is no temptation to share code that should be a service contract; the repo boundary forces the team to decide what is shared via API versus what is duplicated.
• Examples: most B2B SaaS, most early-stage companies.: Most software organizations use polyrepo. The model is the default; the tooling is mature; the team autonomy maps well to standard organizational structure.

Polyrepo is the default for most teams because it works well at small to medium scale. Most companies that have grown large with polyrepo have not necessarily switched to monorepo; the migration cost is high and the existing model is functional.

Decide

The decision is not "which is better" but "which fits the organization's specific context." Both work; neither is universally correct. The factors that drive the decision are scale, culture, integration patterns, and existing investment.

• Larger organizations trend toward monorepo.: Past 1,000 engineers, the coordination cost of polyrepo dominates. The monorepo's unified tooling and atomic refactoring become valuable enough to justify the investment. Most large companies that started polyrepo eventually invest in monorepo-like patterns even if they keep the repo structure.
• Smaller organizations and per-team work fits polyrepo.: Under 100 engineers, polyrepo's team autonomy and operational simplicity dominate. Investing in monorepo tooling at this scale is overinvestment; the simpler model works fine.
• Hybrid is common.: Many organizations split: monorepo for the core platform, polyrepo for peripheral services. The pattern matches where integration is needed (core) versus where autonomy matters (peripheral). The hybrid captures benefits of both at the cost of operational complexity.
• Both work; pick one and commit.: The migration between models is expensive. Picking and committing for years is what produces operational benefits; switching every two years produces overhead without payoff. Choose deliberately; live with the choice.
• Tooling determines feasibility.: Monorepo without proper tooling (Bazel, Nx, Turborepo, custom build systems) is unworkable at scale. Polyrepo without proper tooling (consistent CI, shared deploy infrastructure, dependency management) becomes inconsistent. Either choice requires real tooling investment.

Monorepo versus polyrepo is one of those engineering architecture choices that ripples for years. Nova AI Ops integrates with both repository patterns, surfaces the operational metrics across the chosen architecture, and helps teams see whether their model is delivering the benefits they chose it for.