What Is a Monorepo Architecture? Many Projects, One Repository
A monorepo architecture keeps many projects, services, or libraries in a single version-controlled repository with shared tooling and history.
A monorepo puts everything in one repository: multiple services, shared libraries, and tooling, all versioned together. It is not the same as a monolith (which is one deployable); a monorepo can hold many independently deployable services. The architecture choice has a large, direct effect on how CI is structured, because naive CI would rebuild the world on every change.
One repo, many projects
Multiple projects share a single repository, a unified history, and common tooling. A change can span several projects in one atomic commit, and shared libraries are used directly rather than published and versioned between repos.
Why teams choose it
- Atomic cross-project changes in a single commit.
- One place for shared code, tooling, and standards.
- Easy large-scale refactors across many projects.
- No version-skew dance between separate dependency repos.
The CI challenge
The defining monorepo CI problem is selective builds: rebuilding and testing everything on every commit is wasteful and slow. You need to determine which projects a change affects and build only those, using a build graph and change detection.
Affected-project detection
Monorepo build tools compute a dependency graph and, from the changed files, derive the set of affected projects. The pipeline then builds and tests only that set. Getting this right is what keeps a large monorepo CI fast instead of brutal.
Caching and parallelism
Remote build caches and task parallelism are essential at scale: unchanged projects reuse cached results, and independent tasks run concurrently. Without them, monorepo CI time grows with the whole repo, not with the change.
Scaling monorepo CI
Selective builds plus caching and parallelism keep monorepo pipelines fast, but they lean heavily on warm, cache-backed runners. Latchkey runners keep dependency and build caches warm so affected-project builds reuse prior work instead of starting cold.
Key takeaways
- A monorepo architecture holds many projects in one repository with shared tooling.
- It is not a monolith; it can contain many independently deployable services.
- Selective builds, caching, and parallelism are what keep monorepo CI fast.