TechnicalApr 24, 2026~7 min · intermediate

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.

StackmonorepopnpmTurborepoworkspacesCI

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

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.

arborescenceBASHCopy

# 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

Good reflex

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

When it becomes a burden

Siloed teams

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

Very different stacks

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

Crawling CI

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

Release cycles

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

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.

Worth noting

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

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.↗

In short

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.

Turborepo docs ↗