← Back to resources
// technical · structure

Monorepo or multi-repo

One repo for everything, or one repo per service? The choice shapes your daily dev life for years. Here's when a monorepo is a gift, when it becomes a burden, and how I decide.

TechnicalJul 21, 2026~7 min · intermediate
monorepopnpmTurborepoworkspacesCI
// contents
01The two models02When monorepo wins03When it becomes a burden04How I decide05Sources & further reading
01

The two models

monorepo

everything in one place.

shared code without publishing a package
a cross-cutting change in one commit
atomic global refactor
multi-repo

one repo per service.

clean boundaries and permissions
simpler CI per repo
independent deployments
02

When monorepo wins

For a single product with front, back and shared code — the typical SaaS case — a monorepo is almost always the right call. Sharing types between front and back alone often justifies the structure.

arborescencecopy
# un monorepo type (pnpm workspaces + turborepo)
my-product/
  apps/
    web/          # le front Next.js
    api/          # le backend
  packages/
    ui/           # composants partages
    config/       # tsconfig, eslint communs
    types/        # types partages front <-> back
  turbo.json      # orchestre build/test/lint entre les paquets
  pnpm-workspace.yaml
✓

Tools like Turborepo only rebuild/retest what changed, with a shared cache: a big monorepo’s CI stays fast.

03

When it becomes a burden

01
Siloed teams

Teams that share nothing benefit from separate repos, with their own permissions and cadence.

02
Very different stacks

A Go service, a JS front, a Python data pipeline: shared tooling becomes a headache.

03
Crawling CI

Without cache or incremental build, every push rebuilds everything. The monorepo turns slow.

04
Release cycles

Services that must deploy at very different rhythms live better apart.

04

How I decide

one product, one team, shared code → monorepo, no hesitation;
independent services, separate teams → multi-repo;
in doubt, start monorepo: it’s easier to extract a service than to merge two;
whatever the choice, keep a CLAUDE.md per folder to frame the agent.
i

The per-subfolder CLAUDE.md is exactly the point of the basics of Claude Code.

05

Sources & further reading

01pnpm — WorkspacesOfficial docs for pnpm-workspace.yaml and the workspace: protocol used to link internal packages.↗02Turborepo — Structuring a repositoryThe apps/ + packages/ layout described above, exactly as Turborepo recommends it.↗03Turborepo — Remote CachingThe cache shared between the team and CI: the concrete answer to “monorepo = slow CI”.↗04Nx — Getting startedThe alternative to Turborepo: dependency graph, affected tasks, cache — for monorepos and polyrepos alike.↗05monorepo.toolsFeature-by-feature comparison of monorepo tools — useful when picking the tooling.↗06Potvin & Levenberg — Why Google Stores Billions of Lines of Code in a Single Repository (CACM, 2016)The monorepo taken to the extreme: atomic changes and global refactors, at the cost of custom tooling.↗07GitHub Actions — Workflow syntax (paths / paths-ignore)Filtering workflows by path: the bare minimum so a monorepo doesn’t replay the whole CI on every push.↗

There's no universal winner: monorepo shines on a single product with shared code, multi-repo on truly independent services. In doubt, start grouped and extract later. The worst choice is changing your mind every six months.