Monorepo

Programmers don’t just store their code on their desktop machine. They put it into a shared archive that records every change and gives several people access at the same time. Such an archive is called a repository, or repo for short. Large companies often have hundreds of programs and services – and thus a choice: a separate repo for each program, or everything together in one single, huge one. The second option is called a monorepo, from the Greek “monos” for “single.” So it isn’t a special technology, but a decision about how to organize code.

The dispute over duplicate building blocks

In every larger company there is code that many programs need. For example, a function that checks whether an email address is valid. Or a component that correctly displays amounts in euros. Such shared parts are called libraries.

If all programs sit in separate archives, each one must include its own copy of the library. If someone finds a bug, the fix has to be applied separately to twenty projects. Experience shows that some of them remain on the old, faulty version for months. In a monorepo, the library exists only once. A change takes effect everywhere immediately.

The second advantage is overview. Anyone who wants to know which programs use a particular function can search once across the entire archive. With fifty scattered repos, this question is practically impossible to answer cleanly. Google therefore keeps most of its code in a single monorepo – by its own account, several billion lines.

How an archive with millions of files stays manageable

Technically, a monorepo is initially just a folder tree. At the top are directories such as “apps” for the individual programs and “libs” for the shared building blocks. Each team is responsible for certain subfolders. Rules in a configuration file define who is allowed to approve changes in which area.

The main problem is size. If a team changes one line, strictly speaking all programs would have to be rebuilt and tested. That would take hours. That’s why companies use so-called build tools, such as Bazel or Nx. These tools know the dependencies between the folders. They calculate which programs are actually affected by a change, and only test those.

A common misconception: a monorepo is not the same as a monolith. A monolith is a program that runs as a single large block. A monorepo only states where the code lives – the finished programs can still be a hundred separate services. Conversely, a monolith can also be developed across many repos. The two terms sound similar and mean different things.

Monorepos in job postings and AI projects

The term appears mainly in job postings and developer discussions. When it says “experience with monorepos,” it means: the company has a lot of code in one place and needs people who can handle it. Well-known open-source projects such as React or Babel are also organized as a monorepo. Anyone can look at these archives online.

The question is especially relevant in AI development. An AI product usually consists of several parts: the code for training, the code for serving responses, a web interface, and tools for data preparation. These parts share many components, such as the description of how a model is structured. If they are kept separate, the versions easily drift apart – and no one knows anymore which code a model was actually trained with.

However, a monorepo is not an end in itself. For small teams with two or three programs, the effort for the tooling outweighs the benefit. Even large companies deliberately choose differently: Amazon and Netflix work predominantly with many separate repos, because there each team is meant to remain as independent as possible. Both approaches work – they merely shift where the effort falls.