Multi-Repo Management: Why Monorepos Are Expensive and Polyrepos Are Chaos
Matthew Holmes
May 13, 2026 · // 9 min read
A CVE dropped. It had been public for 6 months. Nobody caught it because nobody owned the whole dependency graph. Three engineers spent a full quarter on remediation instead of the product initiative that was supposed to ship. If you’ve been in that room, the rest of this post will be familiar.
“Let’s just move everything to a monorepo.”
“No, let’s keep our microservices in separate repos.”
This is the debate every scaling engineering org has. Both options are painful at 100+ repos. For different reasons.
At 100+ repos, neither monorepos nor polyrepos work without tooling. Monorepos collapse under build time and merge conflict pressure. Polyrepos fragment into config drift, dependency chaos, and coordination overhead that compounds with every new repo. The question is how to apply the same code change to every repo in an org without creating 200 manual PRs or a 4-hour build queue — and without missing the repo that nobody owns.
The Monorepo Promise
You hope for one repo, atomic changes across services, shared tooling, and consistent CI/CD.
What you get: 4-hour build times, 100GB clone sizes, merge conflicts on every PR, one broken test that blocks everything, and a build system that becomes a full-time job.
Monorepos work well up to 30–50 services. After that, you need Google-level tooling. Most companies are not Google.
The Polyrepo Reality
You hope for team autonomy, independent deployment, clear ownership, and isolation of failures.
What you get: 120 repositories to maintain, config drift across teams, dependency hell, no way to make org-wide changes, and endless “which repo is this service in?” conversations.
Polyrepos work well up to 20 repos. After that, you drown in coordination overhead. Most companies have 50–300 repos.
Why Is Applying the Same Change to Every Repo So Hard?
The core challenge is not repo structure. It is change propagation.
In a monorepo: one change affects 80 services. You run the full test suite, wait 3 hours, and find one failing test in an unrelated service. Now you are debugging someone else’s code before you can ship.
In polyrepos: the same change needs to happen in 80 repos. You create 80 PRs, get 80 teams to review, track 80 merge states, and hope nobody made a typo.
Both structures make org-wide changes painful. Just differently painful.
What Actually Happens at Scale
Month 1: Things are fine. 30 repos. Teams manage well. Changes propagate easily.
Month 12: Cracks appear. 80 repos. Config drift starting. Teams complain about inconsistency.
Month 24: Chaos. 150 repos. Three different CI systems. Four different deployment patterns. Nobody knows who owns what. Simple changes take weeks.
Month 36: Crisis. 250 repos. Platform team spends 60% of their time on coordination. Security patches take 3 weeks. Config standardization is deemed impossible. The monorepo debate resurfaces.
This is the polyrepo death spiral.
The Common Multi-Repo Problems
1. Config Drift
The dream: standard CI config across all repos.
The reality: Repo A runs CircleCI with Docker. Repo B runs GitHub Actions with Kubernetes. Repo C runs Jenkins on a legacy VM. Repo D copied Repo B’s config and changed some things. Repos E through Z are some mix of all of the above.
Teams copy configs and modify them. Nobody enforces standards. Migrations are perpetually scheduled for “when we have time.” Platform changes end up requiring support for 5 different systems.
2. How Dependency Fragmentation Spreads Across Repos
The dream: keep all services on current dependencies.
The reality: React 16 in 45 repos, React 17 in 60, React 18 in 15, React 19 in 5, React 15 in 10 repos that are legacy and “we’ll upgrade later.”
Teams upgrade at different speeds. Breaking changes require work. Nobody has time to update old services. Shared libraries end up supporting multiple versions simultaneously.
In organizations with 100+ repos, dependency version fragmentation typically spans 3+ major versions, meaning any breaking change requires supporting and testing against all of them at once.
3. Ownership Confusion
The dream: clear ownership for every repo.
The reality: 40 repos with active team ownership. 60 repos owned in theory but low priority. 30 repos whose original owner left the company. 20 repos shared between 3 teams where nobody actually owns it. 25 repos where everyone assumes the platform team is responsible.
Teams reorganize. People leave. Services go legacy. Ownership records go stale. Simple changes require detective work just to find the right team.
4. Search and Discovery
A user searches for “payment processing.” Results: payment-api, payment-service, payments-gateway, checkout-payment-handler, billing-payment-processor, legacy-payments, new-payments-v2. Which one is in production? Nobody knows without asking around.
New engineers take weeks to understand service topology in this environment.
5. Tooling Inconsistency
Linting: ESLint in 60 repos, Prettier in 40, TSLint in 15, nothing in 10. Testing: Jest in 70 repos, Mocha in 30, Jasmine in 15, Karma in 10. Deployment: Kubernetes in 80 repos, ECS in 25, Lambda in 20, EC2 in 20.
Different teams made different choices. Tools evolved. Nobody migrated old repos. Platform improvements now have to support 4 different toolchains.
The Coordination Tax
Every org-wide change carries a coordination cost that grows with repo count.
At 20 repos: Creating PRs takes an hour. Merging takes two days. Coordination overhead is minimal.
At 80 repos: Creating PRs takes 3 hours. Merging takes 2 weeks. Coordination overhead: 15 hours.
At 200 repos: Creating PRs takes 8 hours. Merging takes 4 weeks. Coordination overhead: 60 hours.
The coordination overhead of org-wide changes scales exponentially with repo count. A change that takes 2 days to propagate at 20 repos takes 4 weeks at 200.
What Companies Actually Do
Tier 1: Give up on consistency. Let teams do what they want. Standardization is too hard. Result: maximum drift, minimum coordination overhead, complete chaos at scale.
Tier 2: Manual coordination. Platform team manually coordinates every org-wide change. Result: platform team spends 60% of their time on coordination, burnout is high, and initiatives slow to 2–3 per quarter.
Tier 3: Automation without coordination. Scripts and tools that generate PRs at scale. Result: 200 PRs created instantly, 40% merge rate, no visibility into blockers.
Tier 4: Coordination at scale. Automated PR creation plus tracking, notifications, and blocker management. Result: high merge rates, fast time to completion, platform team focused on technical work.
How Do You Propagate Changes Effectively?
Most companies choose polyrepos and then do not build the coordination layer. That is why it feels broken.
The change propagation problem does not go away on its own. It gets handled manually by whoever has the most context and the least ability to say no — until the quarterly planning meeting where someone asks how long a critical patch would take to roll out, and the honest answer is “three weeks, if we’re lucky.”
Tidra is a Maintenance Agent that executes defined code changes across your entire repo organization and delivers each one as a reviewable pull request. Dependency upgrades, runtime migrations, config updates, security patches. Your CI validates the change. Your engineers review it. Nothing merges without a human sign-off.
If your org already runs Renovate or has internal tooling for pieces of this, Tidra operates alongside it — handling the patterns your existing tools do not cover and the cross-repo coordination they cannot do.
What Platform Teams Need to Enforce Changes Across the Codebase
To make polyrepos work at scale, four layers have to exist.
How to apply the same code change to every repo in an org:
- Define the change once: a dependency version, a config pattern, a runtime target.
- Generate PRs automatically across all repos, applying the change consistently.
- Track merge status in real time: which repos merged, which are stuck, which have CI failures.
- Notify the relevant teams and send reminders to repos that have not merged within a threshold.
- Surface blockers immediately so the platform team can resolve them without polling 80 Slack channels.
- Detect drift on an ongoing basis and flag repos that have diverged from the new standard.
Without these layers, polyrepos devolve into chaos at scale. The platform team becomes a coordination team. And coordination does not ship anything.
Platform teams at organizations with 200+ repos report spending up to 60% of their time on coordination work when no automated change propagation layer exists.
The Hidden Benefit of Constraints
Monorepos force consistency because they cannot work without it. One build system, one test framework, one deployment pipeline. The constraint is the point.
Polyrepos give teams the freedom to make different choices. That freedom is real and often worth it. The problem is not the freedom — it is that most orgs add 50 repos before they build the tooling that makes those choices manageable.
Measuring Multi-Repo Health
Good indicators:
- Change propagation across all repos in under a week
- Config consistency above 80%
- Median dependency age under 6 months
- Fewer than 10% of repos with unclear ownership
Bad indicators:
- Simple changes taking 3+ weeks
- 5 or more CI systems in active use
- Dependencies spanning 3+ major versions
- 30% or more of repos with no clear owner
The Path Forward
Migrating to a monorepo is expensive. Staying with manual polyrepo coordination does not scale.
The practical answer: keep polyrepos, build automation for change propagation, enforce consistency with tooling, and make coordination invisible.
Monorepos work because they force consistency. Polyrepos work when you automate it.
At 100+ repos, you already have a coordination layer. The question is whether it is running on platform engineer hours or not.
See how Tidra propagates changes across polyrepos at scale
Book a Demo