Developers no longer need to navigate a labyrinth of folders inside a single 50GB .git directory. With modrepo, they clone only the modules they need. Want to work on the "notification service"? Clone modrepo/notifications and its dependencies. The root manifest provides the context, but the local disk remains lean.
The modrepo orchestrator can detect which modules changed in a pull request and run only their test suites. This is impossible in a classical monorepo without advanced remote caching (like Bazel). In a modrepo, each module’s CI pipeline is independent, yet the final manifest integration test ensures they work together.
How do you version a modrepo? There are two prevailing approaches: modrepo
The modrepo philosophy does not mandate one over the other; it depends on your coupling. High coupling → unified versioning. Low coupling → independent versioning.
One of the biggest complaints about monorepos is the lack of autonomy: teams cannot change their own tooling, folder structure, or release cadence without getting approval from a central authority. With modrepos, each team (or group of related teams) can own their repository entirely—choosing their own linters, branch strategies, and CI workflows—while still benefiting from shared tooling via remote configuration or templates. Developers no longer need to navigate a labyrinth
Let's be honest: Git is a masterpiece of text diffing. But machine learning models are binary blobs. Every time you retrain a 5GB transformer model and commit it to Git LFS, you feel a little piece of your DevOps soul wither.
The problems are systemic:
ModRepo solves this by shifting the paradigm. Instead of storing the file, ModRepo stores the metadata and a content-addressed hash of the file. The actual weights live in a scalable blob store (S3, GCS, Azure Blob), but ModRepo acts as the intelligent index.