J’ai besoin de Postgres et Redis pour le dev local. Plus mon API Rust avec hot reload et un frontend Vite

Tout mettre dans Docker Compose? Même avec des volumes montés, le hot reload est lent. Les file watchers détectent mal les changements. Le HMR de Vite pète la moitié du temps. Les permissions de fichiers cassent tout sur Linux

Tout lancer en process natifs? Là je gère les versions Postgres et les configs Redis à la main

Je mixe les deux. BDD dans des conteneurs. Code en process. Un outil pour tout orchestrer

Ce que fait process-compose

C’est un orchestrateur pour process et conteneurs. Pas l’un ou l’autre. Les deux

Tu définis ce qui tourne, les dépendances, les health checks. Ça démarre tout dans l’ordre, surveille, redémarre en cas d’échec, logs unifiés

version: "0.5"

processes:
  postgres:
    command: podman run --rm -p 5432:5432 -e POSTGRES_PASSWORD=dev postgres:15
    readiness_probe:
      exec:
        command: pg_isready -h localhost
      initial_delay_seconds: 3

  redis:
    command: podman run --rm -p 6379:6379 redis:7

  api:
    command: cargo watch -x run
    depends_on:
      postgres:
        condition: process_healthy
      redis:
        condition: process_healthy

  frontend:
    command: npm run dev
    depends_on:
      api:
        condition: process_healthy

Les BDD tournent dans Podman avec les images officielles, zéro config. Ton code tourne en natif avec le hot reload qui marche

Une seule commande process-compose, tout démarre dans le bon ordre

Pourquoi des conteneurs pour les BDD

Postgres, Redis, Elasticsearch, ils ont tous des images officielles versionnées, testées, prêtes à l’emploi

Tu veux Postgres 15? podman run postgres:15. C’est fait. Pas de galère avec le package manager. Pas de conflits de version. Pas de configs qui traînent

Besoin de Postgres 14 pour un autre projet? Port différent, conteneur différent. Ils se marchent pas dessus

Les conteneurs isolent les BDD. Tes changements de code touchent pas à ça. L’état persiste dans des volumes. Séparation propre

Pourquoi des process pour ton code

Que ce soit Rust avec cargo watch, TypeScript avec Vite ou Go avec air, ils ont tous le hot reload intégré

Tu les wraps dans des conteneurs? Le hot reload casse. Les file watchers voient pas les changements. Les rebuilds sont lents

Tu les lances en process. Les changements de fichiers déclenchent la recompilation instantanée. Le HMR marche. Les debuggers s’attachent facilement

Ton code c’est ce qui change constamment. Garde ça rapide

Config réelle pour une stack web

version: "0.5"

environment:
  - DATABASE_URL=postgresql://postgres:dev@localhost:5432/myapp
  - REDIS_URL=redis://localhost:6379

processes:
  db:
    command: podman run --rm -p 5432:5432 -v postgres-data:/var/lib/postgresql/data -e POSTGRES_PASSWORD=dev postgres:15
    availability:
      restart: on_failure
    readiness_probe:
      exec:
        command: pg_isready -h localhost
      initial_delay_seconds: 2
      period_seconds: 1

  redis:
    command: podman run --rm -p 6379:6379 redis:7
    availability:
      restart: on_failure
    readiness_probe:
      exec:
        command: redis-cli -h localhost ping
      initial_delay_seconds: 1

  migrate:
    command: sqlx migrate run
    depends_on:
      db:
        condition: process_healthy
    availability:
      restart: no

  api:
    command: cargo watch -x 'run --bin api'
    depends_on:
      db:
        condition: process_healthy
      migrate:
        condition: process_completed
      redis:
        condition: process_healthy
    readiness_probe:
      http_get:
        host: localhost
        port: 8080
        path: /health
      period_seconds: 2

  frontend:
    command: npm run dev
    depends_on:
      api:
        condition: process_healthy
    working_dir: ./frontend

Postgres et Redis tournent dans des conteneurs, la migration de BDD s’exécute une fois, l’API Rust utilise cargo watch pour le hot reload, et le frontend Vite attend que l’API soit healthy avant de démarrer

Tu changes ton code Rust et cargo watch recompile en 500ms, sans rebuild d’image ni restart de conteneur

La TUI montre tout

Tu lances process-compose et t’as une interface terminal qui affiche:

• Tous les process, conteneurs comme natifs
• Le statut: running, healthy, failed
• Les logs en temps réel
• Les dépendances visualisées
• Restart avec la touche r

Tu vois les logs du conteneur Postgres mélangés avec la sortie de compilation Rust et les messages HMR de Vite, tout au même endroit

Tu tapes 1 pour voir les logs du process 1. l pour voir tous les logs. q pour quitter. Tout s’arrête proprement

Health checks qui marchent vraiment

processes:
  api:
    command: cargo watch -x run
    readiness_probe:
      http_get:
        host: localhost
        port: 8080
        path: /health
      initial_delay_seconds: 5
      period_seconds: 3
      timeout_seconds: 2

Tu peux faire des health checks pour les process natifs: HTTP, exec, TCP. Exactement comme les probes Kubernetes, mais en local

Le frontend démarre pas tant que l’API est pas healthy. Pas juste “démarré”, vraiment en train de servir des requêtes

Les conteneurs ont aussi des health checks:

processes:
  db:
    command: podman run --rm postgres:15
    readiness_probe:
      exec:
        command: pg_isready -h localhost

Les dépendances attendent la vraie santé. Pas de race conditions

Combine avec Devbox

Devbox pour tes outils de dev. process-compose pour les lancer

{
  "packages": [
    "podman",
    "postgresql",
    "redis",
    "rustup",
    "nodejs",
    "process-compose"
  ],
  "shell": {
    "init_hook": [
      "rustup default stable"
    ]
  }
}

devbox shell te donne Podman, les outils clients Postgres, Node, Rust et process-compose. Mêmes versions partout

Tu ajoutes .envrc:

use devbox
export DATABASE_URL=postgresql://postgres:dev@localhost:5432/myapp
export REDIS_URL=redis://localhost:6379

direnv allow charge tout. process-compose démarre ta stack

Devbox gère tes outils, Podman gère les BDD, et process-compose orchestre le tout. Chacun son rôle

Quand utiliser des conteneurs pour le code

Tu build pour la prod. T’as besoin de l’environnement d’exécution exact

Tu testes le Dockerfile réel. Tu vérifies que ça marche avant de déployer

Multi-stage builds où la conteneurisation fait partie du processus de build

Mais le dev quotidien avec hot reload? Les process gagnent

Si t’es obsédé par les conteneurs

T’aimes vraiment Docker Compose et lancer une commande podman run te semble contre nature? Tu peux utiliser Docker Compose DANS process-compose

version: "0.5"

processes:
  infra:
    command: docker compose -f infra.yml up
    working_dir: ./infra
    shutdown:
      command: docker compose -f infra.yml down

  api:
    command: cargo watch -x run
    depends_on:
      infra:
        condition: process_healthy

  frontend:
    command: npm run dev
    depends_on:
      api:
        condition: process_healthy

Ton infra.yml contient tous tes services conteneurisés (Postgres, Redis, etc.), et process-compose le lance comme un seul process. Ça te permet de garder ton Docker Compose pour l’infra et d’avoir ton code en process natifs

Le meilleur? Quand tu quits process-compose, il exécute automatiquement docker compose down. Tout se nettoie proprement

Plusieurs environnements, même config

Le dev utilise des conteneurs pour les BDD:

processes:
  db:
    command: podman run --rm postgres:15

La CI utilise du vrai Postgres:

processes:
  db:
    command: postgres -D /ci/postgres

Même fichier process-compose.yaml, environnement différent. Tu overrides avec process-compose -f base.yaml -f ci.yaml

Démarrer

Installe process-compose:

# Arch
yay -S process-compose

# Avec Devbox
devbox add process-compose

# Manuel
wget https://github.com/F1bonacc1/process-compose/releases/latest/download/process-compose_linux_amd64.tar.gz
tar xf process-compose_linux_amd64.tar.gz
sudo mv process-compose /usr/local/bin/

Crée process-compose.yaml:

version: "0.5"

processes:
  db:
    command: podman run --rm -p 5432:5432 -e POSTGRES_PASSWORD=dev postgres:15

  app:
    command: cargo watch -x run
    depends_on:
      db:
        condition: process_started

Lance:

process-compose

Le conteneur Postgres démarre, l’app Rust attend qu’il soit prêt puis se lance avec le hot reload activé, et tous les logs apparaissent dans la TUI

Tu changes le code et cargo watch recompile automatiquement, sans rebuild de conteneur

Comparaison réelle

Avec Docker Compose pour tout:

• Les BDD marchent bien dans des conteneurs
• Le code c’est la galère: rebuilds lents, hot reload cassé, problèmes de permissions sur les volumes
• Pour voir les logs: docker compose logs -f service
• Pour restart: docker compose restart
• Tu changes le code: faut rebuild l’image

Avec process-compose en mixant:

• Les BDD dans des conteneurs avec les images officielles
• Ton code tourne en process natif, le hot reload marche nickel
• Les logs dans une TUI unifiée
• Pour restart: tu tapes r
• Tu changes le code: le hot reload se déclenche tout seul

Sur un projet Rust + TypeScript, je suis passé à ce setup. Les changements de code qui prenaient 8 secondes de rebuild Docker prennent maintenant 500ms avec le hot reload. Le HMR de Vite s’est remis à marcher. Le debugging est devenu bien plus simple

Les BDD restent dans des conteneurs, isolées et reproductibles. Le code tourne en process, rapide et facile à debugger

Le meilleur des deux mondes