Skip to content
Latchkey

What Is a Monorepo?

A monorepo is a single repository that holds many projects or services together, sharing one history and one place to coordinate changes.

A monorepo puts multiple projects, libraries, and services into one repository rather than scattering them across many. It makes cross-cutting changes and code sharing easier, but it also demands smarter tooling, especially in CI, so that a change in one corner does not rebuild everything.

What a monorepo is

In a monorepo, several distinct projects live under one repository, often in separate directories. They share one commit history, one set of branches, and one place for issues and reviews. Companies adopt monorepos to make code sharing and atomic cross-project changes straightforward.

Benefits and challenges

The upside is unified versioning, easy refactoring across boundaries, and shared tooling. The challenge is scale: the repository grows large, and naive CI would build and test everything on every change. Effective monorepos rely on tooling that understands project boundaries.

Building only what changed

The key CI technique is to detect which files changed and run only the affected projects. Path filters scope a workflow to a directory so unrelated changes do not trigger it.

Path-filtered workflow trigger
on:
  push:
    paths:
      - "services/api/**"

Monorepos in CI/CD

Without care, monorepo pipelines become slow and expensive as every commit fans out to every project. Path filters, change detection, and build caching keep runs proportional to what actually changed. Managed runners that scale concurrency help here, since a monorepo can fan out many independent jobs at once.

Monorepo CI tips

  • Use path filters so workflows run only for affected projects.
  • Cache builds and dependencies to avoid redundant work.
  • Parallelize independent project jobs for faster feedback.
  • Keep history shallow in CI to speed checkouts of a large repo.

Key takeaways

  • A monorepo holds many projects in one repository and history.
  • It eases sharing and refactoring but demands smart CI tooling.
  • Path filters and caching keep pipelines proportional to changes.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →