Docker Compose sur VPS : le guide complet pour déployer vos conteneurs

Déployer une stack Docker Compose VPS reste en 2026 l'une des méthodes les plus fiables pour orchestrer plusieurs conteneurs sur un seul serveur sans dépendre d'un cluster complet. Ce guide couvre l'installation, la configuration réseau, la sécurisation et l'automatisation d'un déploiement Compose sur un VPS Linux, avec des commandes réelles et des pratiques éprouvées sur le terrain.

Pourquoi Docker Compose VPS reste pertinent en 2026

Docker Compose permet de décrire une application multi-conteneurs dans un seul fichier YAML déclaratif. Sur un VPS, cette approche évite la complexité de Kubernetes tout en offrant reproductibilité, isolation et redémarrages automatiques. Pour la majorité des projets — API, reverse proxy, base de données, workers — un seul VPS bien dimensionné suffit largement.

Les cas d'usage typiques

• Héberger une API avec sa base PostgreSQL et un cache Redis.
• Déployer un reverse proxy (Nginx, Traefik, Caddy) devant plusieurs services.
• Faire tourner un environnement de staging isolé du poste local.
• Assembler une stack de monitoring (Prometheus, Grafana, exporters).

Choisir le bon VPS

La qualité du serveur conditionne directement les performances des conteneurs. Sur un VPS Linux OmegaCloud, vous disposez de stockage SSD SAS, d'un kernel récent compatible cgroups v2 et d'un accès root SSH indispensable à l'installation de Docker. Les critères à surveiller :

Critère	Impact sur Docker Compose
CPU dédié vs partagé	Stabilité des builds et des workloads sous charge
Stockage NVMe	Vitesse des I/O des volumes et des layers d'images
RAM disponible	Nombre de conteneurs simultanés sans swap agressif
Anti-DDoS inclus	Protection volumétrique côté infrastructure, transparente

La protection anti-DDoS volumétrique étant gérée au niveau kernel côté infrastructure OmegaCloud, vous n'avez pas à installer de solution tierce pour la couche réseau. Si vous préférez gérer vos services en conteneurs système, avec snapshots et supervision intégrés, la page VPS Proxmox décrit l'alternative LXC.

Installer Docker et Docker Compose sur le VPS

On part d'un VPS fraîchement provisionné sous Debian 12 ou Ubuntu 24.04. La première étape consiste à mettre à jour le système et à installer les dépendances de base.

Préparer le système

apt update && apt upgrade -y
apt install -y ca-certificates curl gnupg lsb-release

Installer Docker Engine

On utilise le dépôt officiel Docker plutôt que la version des dépôts distribution, souvent en retard. Le plugin docker-compose-plugin fournit la commande moderne docker compose (sans tiret).

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(lsb_release -cs) stable" > /etc/apt/sources.list.d/docker.list

apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Vérifier l'installation

systemctl enable --now docker
docker --version
docker compose version
docker run --rm hello-world

Si le conteneur hello-world s'exécute correctement, votre environnement Docker Compose VPS est fonctionnel. Activez le démarrage automatique du service pour survivre aux reboots.

Créer un utilisateur non-root pour Docker

Travailler en root est déconseillé. Créez un utilisateur dédié et ajoutez-le au groupe docker.

adduser deploy
usermod -aG docker deploy
usermod -aG sudo deploy

Attention : appartenir au groupe docker équivaut quasiment à un accès root sur la machine. Réservez cette appartenance aux utilisateurs de confiance uniquement.

Écrire et déployer une stack Docker Compose

Le cœur d'un déploiement Docker Compose VPS est le fichier compose.yaml. Depuis les versions récentes, la clé version: est obsolète et peut être omise.

Structure de projet recommandée

/opt/myapp/
├── compose.yaml
├── .env
├── nginx/
│   └── default.conf
└── data/

Exemple de stack complète

Voici une stack réaliste : un reverse proxy Nginx, une API Node et une base PostgreSQL, avec réseaux isolés et volumes persistants.

services:
  proxy:
    image: nginx:1.27-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - api
    restart: unless-stopped
    networks:
      - frontend

  api:
    image: node:22-alpine
    working_dir: /app
    command: node server.js
    environment:
      DATABASE_URL: postgres://app:${DB_PASSWORD}@db:5432/appdb
    volumes:
      - ./app:/app
    restart: unless-stopped
    networks:
      - frontend
      - backend

  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: appdb
    volumes:
      - dbdata:/var/lib/postgresql/data
    restart: unless-stopped
    networks:
      - backend

volumes:
  dbdata:

networks:
  frontend:
  backend:

Gérer les secrets avec .env

Ne codez jamais un mot de passe en dur dans le YAML. Utilisez un fichier .env exclu du versionnement Git.

DB_PASSWORD=change_me_with_a_strong_secret

chmod 600 .env
echo ".env" >> .gitignore

Lancer et gérer la stack

cd /opt/myapp

# Démarrer en arrière-plan
docker compose up -d

# Suivre les logs
docker compose logs -f api

# Vérifier l'état
docker compose ps

# Mettre à jour les images
docker compose pull && docker compose up -d

# Arrêter proprement
docker compose down

Politique de redémarrage

La directive restart: unless-stopped garantit que vos conteneurs redémarrent après un reboot du VPS, sauf s'ils ont été explicitement arrêtés. Combinée à systemctl enable docker, elle assure la résilience de la stack sans script maison.

Sécuriser et automatiser le déploiement

Un VPS exposé sur Internet doit être durci avant toute mise en production. La sécurité se joue à plusieurs niveaux : accès SSH, pare-feu, et hygiène des conteneurs.

Durcir l'accès SSH

Générez une paire de clés et désactivez l'authentification par mot de passe. C'est la mesure la plus rentable contre les attaques par force brute.

# Sur votre poste local
ssh-keygen -t ed25519 -C "deploy@myapp"
ssh-copy-id deploy@VOTRE_IP_VPS

Puis éditez /etc/ssh/sshd_config :

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

systemctl restart ssh

Configurer le pare-feu

Attention : Docker manipule directement les règles iptables et peut contourner UFW pour les ports publiés. Ouvrez uniquement les ports nécessaires et gardez à l'esprit ce comportement.

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Pour un contrôle plus fin en présence de Docker, nftables ou l'usage de 127.0.0.1:PORT dans les mappings de ports permettent de restreindre l'exposition. Publiez la base de données uniquement en interne, sans jamais mapper le port 5432 sur l'hôte.

Ajouter fail2ban

apt install -y fail2ban
systemctl enable --now fail2ban
fail2ban-client status sshd

Bonnes pratiques conteneurs

• Épinglez les tags d'images (postgres:17-alpine plutôt que latest).
• Utilisez des images Alpine ou distroless pour réduire la surface d'attaque.
• Ne lancez pas les processus conteneurisés en root quand c'est évitable.
• Limitez les ressources avec deploy.resources.limits pour éviter qu'un conteneur ne sature le VPS.
• Activez le 2FA sur le panel de gestion pour protéger l'accès à l'infrastructure.

La couche anti-DDoS volumétrique étant assurée en amont côté OmegaCloud, votre travail de sécurisation se concentre sur l'applicatif, SSH et les règles de pare-feu locales. Pour les recommandations de durcissement système, référez-vous au guide officiel Source.

Automatiser avec CI/CD

Le déploiement manuel devient vite fastidieux. Avec les Integrations & API OmegaCloud, vous branchez GitHub Actions ou GitLab CI pour déployer automatiquement à chaque push. Le principe : le pipeline se connecte en SSH, met à jour le code, puis relance la stack.

# Exemple d'étape GitHub Actions (extrait)
- name: Deploy to VPS
  run: |
    ssh deploy@${{ secrets.VPS_HOST }} '
      cd /opt/myapp &&
      git pull &&
      docker compose pull &&
      docker compose up -d --remove-orphans
    '

Depuis le panel OmegaCloud, vous pouvez surveiller en temps réel la charge CPU/RAM/SSD pendant les déploiements, prendre un snapshot avant une mise à jour risquée, et rollback en cas de problème via la console KVM.

Snapshots avant mise à jour

Avant toute montée de version majeure d'une base de données, déclenchez un snapshot depuis le panel. En cas d'échec de migration, la restauration vous ramène à l'état sain en quelques minutes, sans reconstruire la stack.

Consultez régulièrement la documentation Docker et le Blog OmegaCloud pour suivre l'évolution des bonnes pratiques d'orchestration mono-serveur.

Conclusion

Déployer avec Docker Compose sur un VPS offre un équilibre solide entre simplicité et contrôle. En combinant un serveur SSD SAS performant, un durcissement SSH rigoureux, un pare-feu adapté et un pipeline CI/CD, vous obtenez une infrastructure reproductible et maintenable. La clé reste la discipline : versionner sa configuration, épingler ses images et sauvegarder avant chaque changement critique.

FAQ

Faut-il ouvrir manuellement les ports pour Docker Compose sur un VPS ?

Les ports déclarés dans la section ports: du fichier Compose sont publiés par Docker via iptables, souvent en contournant UFW. Ouvrez uniquement 80 et 443 pour un reverse proxy, et gardez les services internes (base de données) non mappés sur l'hôte ou liés à 127.0.0.1 pour ne pas les exposer.

Docker Compose survit-il à un redémarrage du VPS ?

Oui, à condition d'activer le service Docker au boot avec systemctl enable docker et d'utiliser restart: unless-stopped sur vos services. Les conteneurs redémarreront automatiquement après un reboot, sauf ceux que vous avez arrêtés manuellement.

Comment mettre à jour une stack sans interruption prolongée ?

Récupérez d'abord les nouvelles images avec docker compose pull, puis appliquez avec docker compose up -d --remove-orphans. Docker recrée uniquement les conteneurs dont l'image a changé. Prenez un snapshot depuis le panel avant les mises à jour de base de données pour permettre un rollback rapide.