CONCEPT Cited by 1 source
Monorepo¶
Monorepo = a single shared version-control repository holding many services, libraries, tools, and other artefacts that would otherwise live in separate repos. Opposed to polyrepo (many repositories, one per service/library).
Why pick one¶
- Atomic cross-service change — one commit can edit a library and every consumer, so invariants stay enforced without version-bump-and-wait dances.
- Shared tooling + code — one build config, one code-search surface, one dependency tree, one set of lint/format/test configurations.
- Consolidated ownership signals — easier to see who touches what, reason about blast radius, coordinate migrations, enforce policy (see also patterns/bisect-driven-regression-hunt, patterns/centralized-forward-declarations).
What you pay¶
- Repo size + clone time. The single-repo discipline only scales if the on-disk footprint stays tractable. Canonical worst case: Dropbox's 87 GB server monorepo hitting >1 hour initial clone at 20–60 MB/day growth, on course for GHEC's systems/github|100 GB hard limit — see systems/dropbox-server-monorepo + sources/2026-03-25-dropbox-reducing-monorepo-size-developer-velocity.
- Tool-scaling. Git commands (status, log, grep), CI systems, code-search indexers, IDE language servers all have to stay fast against a repo that's an order of magnitude larger than typical. Drives investment in incremental / remote / content-addressed build systems (concepts/hermetic-build, concepts/remote-build-execution, concepts/content-addressed-caching, concepts/build-graph).
- Structural surprises. A monorepo's directory layout interacts with VCS internals in ways that matter at scale. Canonical instance: Dropbox's i18n path layout mismatched Git's 16-char delta-pairing heuristic, causing routine translation updates to produce pathological pack sizes — the bug was in the layout×heuristic interaction, not in anyone's commits.
Operational discipline¶
Monorepos are production infrastructure, not passive storage. The 2026-03-25 Dropbox post makes this explicit: "Repositories can feel like passive storage, something that simply grows over time. At scale, they are not passive. They are critical infrastructure that directly affects developer velocity and CI reliability." Concrete operational moves:
- Track repo size, growth rate, fresh clone time, per-subtree storage distribution continuously on an internal dashboard — patterns/repo-health-monitoring.
- Treat structural repo rewrites (e.g. server-side repack) like any production-infra change: test on a mirror first (patterns/mirror-first-repack-validation), roll out gradually with a rollback path.
- Align directory layout with the tooling's internal assumptions — in the Dropbox i18n case, reshape paths so similar-content files share the tail-16-char window the default Git heuristic uses.
Canonical wiki instances¶
- systems/dropbox-server-monorepo — 87 GB Git monorepo on GHEC, 77% size reduction via server-side repack after identifying the Git-heuristic / i18n-layout structural mismatch.
- Figma monorepo — context for the Figma device-trust commit signing workflow (every commit merging to a release branch must be S/MIME-signed with a device-trust cert).
- Canva monorepo — context for Canva's CI build speedups, which leans on hermetic + content-addressed + remote-executed Bazel builds to keep a large shared repo's CI fast.
Related¶
- systems/git / systems/github — the typical substrate.
- concepts/git-pack-file — the on-disk compaction layer that large monorepos stress.
- concepts/git-delta-compression — the specific Git heuristic that can go pathological at monorepo scale.
- concepts/hermetic-build, concepts/remote-build-execution, concepts/content-addressed-caching — the build-system side of keeping a big shared repo fast.
- patterns/server-side-git-repack — fix shape when the repo layer goes pathological on a managed SaaS.
- patterns/repo-health-monitoring — standing operational discipline.