Deplomo
Accedi
Guida al deploy di monorepo

Deploy di un monorepo: più servizi da un unico repository

Fai il deploy di più servizi da un monorepo su Deplomo: configura Turborepo e gli workspace pnpm, la cartella radice, il percorso del Dockerfile e il contesto di build. Puoi pubblicare anche con la CLI.

risposta breve

Per ogni app all’interno del monorepo, ad esempio apps/web o apps/api, crea un servizio separato sulla piattaforma cloud. Tutte le app sono collegate allo stesso repository e branch; il campo Root Directory indica da quale cartella avviare la build, mentre i Watch Paths evitano di ripubblicare i servizi non interessati. Per consultare tutte le guide, visita la sezione Guida al deploy dedicata.

Ultima revisione:6 settembre 2026

Il modello di deploy dei monorepo su Deplomo

Un repository può contenere più servizi separati. Con il deploy multi-servizio, ogni app ha comandi di build e avvio, variabili d’ambiente, dominio e scalabilità propri; tutte le app fanno però parte dello stesso progetto:

repo/
├── apps/
│   ├── web/       # servizio frontend
│   └── api/       # servizio backend
├── packages/
│   └── shared/    # pacchetto di codice condiviso
├── package.json
└── pnpm-lock.yaml

Configura la cartella radice, il percorso del Dockerfile e il contesto di build

  • Cartella radice (Root Directory): Percorso della cartella dell’app rispetto alla radice del repository, ad esempio apps/api. Il rilevamento dello stack e l’esecuzione degli script iniziano da questa cartella.
  • Percorso del Dockerfile: Percorso del Dockerfile rispetto alla radice del repository, ad esempio apps/api/Dockerfile. Se ti serve un ambiente isolato specifico, puoi usare la piattaforma avanzata container cloud di Deplomo.
  • Contesto di build (Build Context): Il valore . consente di rendere disponibili nel comando Docker COPY i file condivisi nella radice e il lockfile.

Deploy di Turborepo e degli workspace con pacchetti condivisi

Se le app nel monorepo hanno bisogno del codice in packages/shared , imposta la radice del repository come contesto di build:

# Configurazione del deploy nella dashboard Deplomo
Cartella radice:       apps/api
Percorso Dockerfile:  apps/api/Dockerfile
Contesto di build:       .
Percorsi monitorati:
  apps/api/**
  packages/shared/**
  pnpm-lock.yaml

Con questa configurazione, le modifiche ai pacchetti condivisi avviano automaticamente una nuova build per tutti i servizi che ne dipendono.

Percorsi monitorati (Watch Paths): evita build non necessarie

Per ogni servizio collegato a Git, il nuovo deploy parte solo se i file modificati corrispondono ai percorsi monitorati:

  • apps/api/** Include tutti i file e le sottocartelle dell’API.
  • packages/shared/** Rileva le modifiche alle librerie condivise.
  • Aggiungi il nome del lockfile nella radice del repository per includere gli aggiornamenti delle dipendenze.

Deploy di più servizi in un monorepo con CLI di Deplomo

Con la CLI di Deplomo puoi pubblicare facilmente i servizi del monorepo dal tuo ambiente locale:

cd repo
deplomo deploy . \
  --name api \
  --root-dir apps/api \
  --dockerfile apps/api/Dockerfile \
  --build-context . \
  --port 8080

Domande frequenti

Che cos’è un monorepo e quali vantaggi offre ai team di sviluppo?

Un monorepo è una strategia per gestire il codice in cui più progetti e servizi software indipendenti sono conservati in un unico repository Git. Questo approccio semplifica notevolmente la condivisione del codice, il coordinamento dei pacchetti e le modifiche trasversali.

Come si fa il deploy di un monorepo su Deplomo?

Collega il repository e crea un servizio separato per ogni app, specificando la relativa cartella radice (Root Directory). Con i percorsi monitorati (Watch Paths), il sistema rileva le modifiche e ricostruisce e pubblica solo i servizi interessati.

Sono supportati Turborepo e gli workspace pnpm?

Sì. Puoi configurare il contesto di build per usare Turborepo e gli workspace di pnpm, Yarn o npm, mantenendo accessibili i file nella radice e i pacchetti condivisi.

Come incide sulle risorse il deploy di più servizi da un unico repository?

In un progetto con più servizi, ogni servizio viene eseguito nel proprio container con CPU e RAM assegnate. Le risorse complessive rientrano nei limiti del pacchetto mensile della zona scelta.