Polyrepo
A polyrepo (or multirepo) architecture puts each service or library in its own version-control repository, with independent CI, versioning, and release cadences. It's the default for most organisations and remains the right choice for teams without monorepo-scale tooling investment or strong cross-repo coupling.
Polyrepo trade-offs are the inverse of monorepo: cross-repo refactors require coordinating PRs across multiple repos (and often versioned releases between them); tooling sprawls (each repo has its own CI config, lint config, dependabot config); but each repo is small, fast to clone, and clearly owned. The pain point that drives teams toward monorepo is cross-repo type/contract changes: in a polyrepo world, every breaking API change requires coordinated release-pin-update cycles across consumers. Teams using polyrepos at scale invest in cross-repo tools — contract testing, generated SDKs, dependency dashboards — to reduce the coordination tax.
Related terms
- Monorepo
A monorepo is a version-control repository that contains many distinct projects (services, libraries, tools) with shared tooling and atomic cross-project changes.
- Semantic versioning (semver)
Semantic versioning is the package-versioning convention MAJOR.
- Contract testing
Contract testing verifies that two services communicate correctly without requiring both to be deployed for the test.