Déployer une application Docker Compose sur un VPS : réseau privé, HTTPS et sauvegardes

Lancer docker compose up -d sans erreur ne suffit pas à mettre une application en production. Sur un VPS, vous restez responsable du système, du pare-feu, du domaine, des certificats, des mises à jour, des données et de la remise en service après incident. Ce guide suppose que votre dépôt contient déjà un Dockerfile et une application qui se lie à 0.0.0.0:8080 dans le conteneur et sait lire les variables de base de données présentées plus bas. Vérifiez l’adresse d’écoute de votre framework : s’il écoute uniquement sur 127.0.0.1 ou localhost, Caddy ne pourra pas le joindre depuis un autre conteneur. Il s’agit d’un modèle à adapter, pas d’un déploiement en un clic ni d’une garantie de compatibilité avec toutes les applications.

Pour un site purement statique, sans processus qui doit tourner en permanence, examinez d’abord Hostbrid Projects. Le VPS est adapté si vous avez besoin de contrôler le système et pouvez en assurer l’administration. Hostbrid fournit les serveurs virtuels ; vous gérez Docker et les logiciels installés. Vérifiez les tailles et la disponibilité sur la page VPS avant de choisir.

Avant de commander, consultez le guide pour mesurer RAM, CPU et disque d’une application Docker ; cette page se concentre sur le déploiement de la pile et la protection de ses services.

Pour déployer n8n, consultez le guide n8n sur VPS, qui présente l’installation rapide et Docker Compose.

Définir ce qui est public et ce qui reste privé

Le navigateur doit atteindre un proxy inverse, jamais le port de la base de données. Ici, Caddy reçoit le trafic web et le transmet à l’application ; PostgreSQL ne publie aucun port sur l’hôte. Sur un réseau partagé, Compose résout le nom db, ce qui permet à l’application de joindre db:5432 sans ouvrir PostgreSQL à Internet. La documentation des réseaux Docker décrit cette communication entre services ; le guide Docker explique aussi l’usage de Compose en production.

Placez compose.yaml à côté du Dockerfile de votre application et créez le Caddyfile montré ensuite. Remplacez les variables de app par celles réellement prises en charge par votre code. Le conteneur doit lire DB_HOST, DB_NAME, DB_USER et DB_PASSWORD. Ajouter ces variables dans Compose ne suffit pas si l’application n’a pas été écrite pour se connecter à PostgreSQL.

services:
  app:
    build: .
    restart: unless-stopped
    environment:
      PORT: "8080"
      DB_HOST: db
      DB_PORT: "5432"
      DB_NAME: ${DB_NAME:?set DB_NAME in .env}
      DB_USER: ${DB_USER:?set DB_USER in .env}
      DB_PASSWORD: ${DB_PASSWORD:?set DB_PASSWORD in .env}
    expose: ["8080"]
    networks: [edge, data]
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${DB_NAME:?set DB_NAME in .env}
      POSTGRES_USER: ${DB_USER:?set DB_USER in .env}
      POSTGRES_PASSWORD: ${DB_PASSWORD:?set DB_PASSWORD in .env}
    volumes: [postgres_data:/var/lib/postgresql/data]
    networks: [data]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
      interval: 10s
      timeout: 5s
      retries: 5

  caddy:
    image: caddy:2
    restart: unless-stopped
    environment:
      SITE_DOMAIN: ${SITE_DOMAIN:?set SITE_DOMAIN in .env}
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks: [edge]
    depends_on: [app]

networks:
  edge: {}
  data:
    internal: true

volumes:
  postgres_data: {}
  caddy_data: {}
  caddy_config: {}

{$SITE_DOMAIN} {
    encode zstd gzip
    reverse_proxy app:8080
}

Seuls Caddy et l’application partagent edge, tandis que l’application et PostgreSQL partagent data, un réseau interne. Cela évite de donner à la base un port public ou un accès direct depuis le proxy. expose indique le port de l’application dans la pile, mais ne publie rien sur l’hôte. Caddy est le seul service qui ouvre 80 et 443. Le volume nommé de PostgreSQL garde ses données quand le conteneur est remplacé. Docker décrit les volumes comme un stockage distinct du cycle de vie des conteneurs ; un volume sur le même VPS ne constitue toutefois pas une sauvegarde.

Préparer le serveur, le nom de domaine et le pare-feu

Choisissez une version Linux maintenue, installez les mises à jour et créez un compte d’administration non-root avec des clés SSH. Installez Docker Engine et le plugin Compose en suivant les instructions officielles adaptées à votre distribution. Gardez une seconde session SSH ouverte avant de durcir le pare-feu : une règle erronée peut vous couper l’accès. Lorsque c’est possible, limitez SSH aux adresses de confiance et n’autorisez le trafic web que si le site est destiné au public. Docker signale que les ports publiés peuvent interagir avec le pare-feu de l’hôte de façon inattendue. Vérifiez le comportement réel avec la version de Docker et le pare-feu utilisés ; ne supposez pas qu’une règle UFW filtre automatiquement tout port publié. Consultez les recommandations Docker sur la publication des ports.

Faites pointer l’enregistrement A vers l’adresse IPv4 du VPS. N’ajoutez un enregistrement AAAA que si IPv6 est réellement routé et configuré. Vérifiez le DNS depuis un autre réseau. Le HTTPS automatique de Caddy nécessite un nom public et des ports de validation joignables. Autorisez TCP 80 et 443 dans le pare-feu réseau du fournisseur et sur le système. N’exposez pas 5432 pour faciliter une connexion ponctuelle. Pour administrer la base à distance, préférez un réseau privé ou un tunnel authentifié, avec des règles d’accès limitées.

Créez un fichier .env privé qui contient SITE_DOMAIN, DB_NAME, DB_USER et un mot de passe long et aléatoire dans DB_PASSWORD. Restreignez les permissions, excluez ce fichier de Git et ajoutez-le au fichier .dockerignore : build: . envoie un contexte au constructeur. Ne copiez pas ces valeurs dans des tickets ou des captures d’écran. Le fichier .env est un mécanisme de configuration, pas un coffre de secrets : une personne ayant les droits root ou Docker peut inspecter les paramètres du conteneur. Changez les identifiants s’ils sont divulgués. Dans un conteneur, localhost désigne le conteneur lui-même ; l’application doit joindre la base sous le nom db.

Vérifier la configuration et le service

Dans le répertoire du projet, lancez ces commandes :

docker compose config -q
docker compose up -d --build
docker compose ps
docker compose logs --tail=100 app db caddy

config -q détecte les erreurs de syntaxe et les variables obligatoires manquantes, mais ne valide pas le fonctionnement du programme. Vérifiez que la base passe à l’état sain, que les journaux de l’application confirment sa connexion et que Caddy peut obtenir son certificat. Depuis une connexion extérieure, ouvrez le domaine en HTTPS et testez l’authentification, les formulaires, les transferts de fichiers et le parcours utilisateur essentiel. Vérifiez aussi que 80/443 sont joignables et que 5432 ne l’est pas. Un conteneur marqué « running » ne prouve ni le bon fonctionnement du site ni la possibilité de récupérer les données.

Mettre à jour sans perdre le moyen de revenir en arrière

Versionnez le code et les fichiers Compose dans un dépôt privé, sans .env ni données réelles. Avant chaque changement, notez la version ou le commit en service. Construisez ou récupérez la nouvelle image, vérifiez la configuration de production assemblée, puis appliquez la mise à jour. Le guide Docker sur Compose en production montre comment séparer la configuration de production et recréer un service ciblé. Pour une évolution risquée, répétez-la sur une copie restaurée des données. Revenir à l’ancien code ne défait pas toujours une migration de schéma ; traitez cette opération séparément.

Sauvegardez PostgreSQL avec une méthode qui comprend le moteur et copiez le résultat hors du VPS. Testez la restauration dans un environnement isolé. Selon votre application, ajoutez les fichiers envoyés par les utilisateurs, la configuration et les données Caddy. Une copie à chaud du volume PostgreSQL peut être incohérente : suivez la procédure de sauvegarde du moteur. Chiffrez les copies externes et fixez une durée de rétention. Avant de remplacer un conteneur, confirmez que les données durables se trouvent bien dans un volume ou un stockage conçu pour cela. Évitez docker compose down -v pour un simple nettoyage : -v peut supprimer les volumes nommés et leurs données.

Ce modèle n’inclut ni déploiement Docker géré ou automatique par Hostbrid, ni supervision, ni installation des correctifs, ni service de sauvegarde, ni garantie de disponibilité ou de capacité. Si vous souhaitez administrer votre serveur, comparez les offres VPS Hostbrid ; pour discuter du choix d’offre, vous pouvez contacter l’équipe. Le diagnostic d’un service Node avec Docker se concentre sur le port et la santé d’un seul processus ; il ne décrit pas le déploiement de cette pile multi-services.