Docker

Environnements

Patrimo utilise deux fichiers Docker Compose distincts :

Fichier	Usage
docker-compose.yml	Développement local (hot-reload, bind-mount source)
docker-compose.prod.yaml	Production standalone — utilisé par Coolify

Extension .yaml pour la prod

Le fichier de production utilise l'extension .yaml (et non .yml). Coolify détecte automatiquement ce fichier lors de la configuration du service.

Développement

cp .env.example .env
# Éditer POSTGRES_PASSWORD et AUTH_SECRET
docker compose up

Ce qui se passe au démarrage :

1. PostgreSQL 16 démarre et attend le healthcheck (pg_isready)
2. L'image app est construite (cible dev du Dockerfile)
3. npx prisma migrate deploy applique les migrations versionnées
4. npm run dev lance Next.js sur le port 4000

Le code source est monté en volume (- .:/app) → le hot-reload fonctionne sans rebuild.

Services :

Service	Port	Description
app	4000	Next.js dev server
db	5432	PostgreSQL 16
docs	3001	Docusaurus dev server

Production

En production, Coolify clone le dépôt depuis GitHub et build les images directement depuis le code source. On ne lance pas docker compose up manuellement en prod.

Le fichier docker-compose.prod.yaml est un fichier standalone — il ne nécessite pas de fichier d'override. Il définit :

• Service app : build depuis le Dockerfile racine (cible runner), port exposé 3000 (sans binding hôte — routé par Coolify)
• Service db : postgres:16-alpine, volume nommé postgres_data, healthcheck pg_isready
• Service docs : build depuis docs-site/Dockerfile (cible runner), port exposé 80
• Variables injectées par Coolify (aucune valeur hardcodée dans le fichier)

Pas de healthcheck applicatif dans le compose prod

Le healthcheck de l'application (/api/health) est géré directement par Coolify, pas dans docker-compose.prod.yaml.

Voir Coolify pour la configuration du déploiement.

Dockerfile multi-stage

Le Dockerfile à la racine utilise plusieurs stages :

Stage	Rôle
base	Node 22 Alpine + dépendances système
deps	npm ci — dépendances de prod
dev	Cible dev (inclut devDeps, CMD = npm run dev)
builder	Build Next.js (npm run build)
runner	Image finale minimale — copie .next/standalone

Stage runner — détail : les modules Prisma natifs sont installés via npm install --ignore-scripts --no-audit --no-fund prisma (plutôt que par COPY manuel des binaires). Le fichier prisma.config.ts est également copié dans ce stage (requis par Prisma 7).

Entrypoint de production

Le script entrypoint.sh exécuté au démarrage du container de production :

npx --no prisma migrate deploy
exec node server.js

Les migrations sont donc appliquées automatiquement à chaque déploiement, avant le démarrage de l'application.

Volumes

Volume	Contenu
postgres_data	Données PostgreSQL persistantes (prod)

En dev, deux volumes anonymes excluent node_modules et .next du bind-mount (performance sur macOS/Windows).

Variables d'environnement

En dev, DATABASE_URL est construite automatiquement depuis POSTGRES_USER, POSTGRES_PASSWORD et POSTGRES_DB. En production, toutes les variables sont injectées par Coolify.

Voir Variables d'environnement pour la référence complète.

Commandes utiles

# Voir les logs en temps réel
docker compose logs -f app

# Accéder au shell du container
docker compose exec app sh

# Appliquer les migrations manuellement (dev)
docker compose exec app npx prisma migrate deploy

# Redémarrer l'app sans rebuild
docker compose restart app

# Rebuild forcé après changement de dépendances (dev)
docker compose up --build

Voir aussi

• Coolify
• CI/CD
• Variables d'environnement