Polyrepo Explained

Store each service in its own repository — providing strong isolation, independent lifecycles, and clear ownership boundaries for autonomous teams.

Polyrepo

A polyrepo (multi-repo) strategy stores each project, service, or package in its own separate Git repository, providing strong isolation, independent versioning, and clear ownership boundaries.

Explanation

In a polyrepo strategy, each microservice, library, or application has its own repository with its own CI/CD pipeline, dependency management, and release cycle. This provides strong boundaries: teams own their repositories independently, access control is granular, and a problem in one repo does not affect others. The tradeoff is that cross-repository changes require coordinating commits across multiple repos, shared code must be published as packages, and tooling consistency requires extra effort. Polyrepo works well when teams are autonomous, services are truly independent, and the overhead of package publishing is acceptable.

Bookuvai Implementation

Bookuvai uses polyrepo when services are owned by different teams or have different technology stacks. We maintain shared packages in a private npm registry, use automated dependency update tools, and standardize CI/CD templates across repositories for consistency.

Key Facts

  • Each project or service in its own separate repository
  • Strong isolation: independent CI/CD, versioning, and access control
  • Cross-repo changes require coordinating multiple commits
  • Shared code published as packages to a registry
  • Works well for autonomous teams with independent services

Related Terms

Frequently Asked Questions

When should I choose polyrepo over monorepo?
Choose polyrepo when teams are highly independent, services use different technology stacks, you need granular access control, or organizational boundaries align with service boundaries. Choose monorepo when teams share code frequently and need atomic cross-project changes.
How do I share code between polyrepo services?
Publish shared code as packages to a private registry (npm, PyPI, Maven). Use semantic versioning so consumers control when they upgrade. Automate dependency updates with tools like Dependabot or Renovate.
How do I make cross-repo changes?
Coordinate changes across repos by first updating the shared package, then updating consumers. For breaking changes, use API versioning or the expand-contract pattern. Tools like multi-gitter can automate similar changes across many repositories.