Docker sur VPS LWS : guide complet pour installer, configurer et déployer ses applications

docker run -d \
  --name mon-nginx \
  -p 8080:80 \
  nginx:latest

Vérifiez qu’il fonctionne :

docker ps

Ouvrez ensuite votre navigateur à l’adresse :

http://IP_VPS:8080

Vous devriez voir la page par défaut de Nginx. Cela signifie que le conteneur tourne correctement et que le port est bien accessible depuis l’extérieur. Pour arrêter puis supprimer ce test :

docker stop mon-nginx
docker rm mon-nginx

Cette première manipulation montre l’intérêt de Docker : aucun paquet Nginx n’a été installé directement sur Ubuntu, mais le service a tout de même fonctionné en quelques secondes. Chaque application peut ainsi rester isolée, facile à supprimer et simple à relancer.

En production, ce type de test permet aussi de vérifier rapidement le pare-feu, les règles réseau du VPS et la publication des ports. Si la page n’apparaît pas, contrôlez d’abord le port exposé, l’adresse IP utilisée et les éventuelles restrictions côté serveur.

Docker Compose : déployer WordPress + MySQL

Les commandes docker run sont utiles pour tester un service isolé, mais elles deviennent vite difficiles à maintenir dès qu’une application dépend de plusieurs conteneurs. WordPress, par exemple, a besoin d’un serveur web PHP, d’une base de données MySQL, de volumes persistants et d’un réseau interne. Docker Compose permet de décrire tout cela dans un seul fichier YAML, lisible, réutilisable et facile à versionner.

Étape 1 — Créer le dossier du projet

Créez d’abord un dossier dédié au projet :

mkdir -p /opt/wordpress-docker
cd /opt/wordpress-docker

Étape 2 — Créer le fichier compose.yaml

Créez ensuite le fichier de configuration :

nano compose.yaml

Ajoutez le contenu suivant :

services:
  db:
    image: mysql:8.0
    container_name: wordpress_db
    restart: always
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: mot_de_passe_fort_ici
      MYSQL_ROOT_PASSWORD: mot_de_passe_root_fort_ici
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:latest
    container_name: wordpress_app
    restart: always
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wp_user
      WORDPRESS_DB_PASSWORD: mot_de_passe_fort_ici
    volumes:
      - wp_data:/var/www/html

volumes:
  db_data:
  wp_data:

Dans ce fichier, deux services sont déclarés. Le service db utilise l’image MySQL 8.0 et initialise une base appelée wordpress avec un utilisateur dédié. Le volume db_data conserve les données de la base, même si le conteneur est recréé.

Le service wordpress utilise l’image officielle WordPress, se connecte à MySQL grâce au nom de service db, expose le site sur le port 8080 du VPS et stocke ses fichiers dans le volume wp_data.

Étape 3 — Lancer le stack

Lancez maintenant le stack :

docker compose up -d

Au premier lancement, Docker télécharge les images nécessaires, crée automatiquement le réseau du projet, initialise les volumes et démarre les conteneurs. L’option -d exécute les services en arrière-plan, ce qui vous permet de récupérer la main dans le terminal.

Étape 4 — Vérifier que tout tourne

Vérifiez l’état du déploiement :

docker compose ps

Les services db et wordpress doivent apparaître comme actifs. Si un service ne démarre pas, consultez les logs :

docker compose logs wordpress
docker compose logs db

Vous pouvez également suivre les logs en temps réel :

docker compose logs -f

Étape 5 — Tester dans le navigateur

Ouvrez ensuite votre navigateur à l’adresse suivante :

http://IP_VPS:8080

L’assistant d’installation WordPress doit s’afficher. Vous pourrez alors choisir la langue, créer l’utilisateur administrateur et finaliser la configuration du site.

Les commandes Compose les plus utiles sont :

Soyez prudent avec docker compose down -v : cette commande supprime aussi les volumes du projet. Dans le cas de WordPress, cela peut effacer la base MySQL et les fichiers du site. Pour un environnement de production, conservez toujours les volumes et effectuez une sauvegarde avant toute opération risquée.

Cet exemple illustre la force de Docker Compose : toute l’architecture applicative est décrite dans un fichier unique. Vous pouvez relire la configuration, la déplacer sur un autre VPS, la sauvegarder dans un dépôt privé ou l’adapter pour ajouter un cache Redis, un reverse proxy ou un service de sauvegarde.

Dans un contexte réel, remplacez toujours les mots de passe d’exemple par des valeurs longues et uniques. Évitez aussi de publier ce fichier dans un dépôt public, car il contient des secrets. Une amélioration courante consiste à placer les mots de passe dans un fichier .env, puis à les appeler dans le fichier Compose avec la syntaxe ${VARIABLE}. Cette méthode facilite la maintenance et limite les risques d’exposition accidentelle.

Vous pouvez également adapter le port publié. Si le port 8080 est déjà utilisé par une autre application, choisissez par exemple 8081:80. Le premier nombre correspond au port du VPS, le second au port interne du conteneur. Dans la suite de l’article, le reverse proxy permettra de masquer ce port technique derrière un vrai nom de domaine HTTPS, plus propre pour les visiteurs et pour l’administration quotidienne.

Sécuriser l’accès : reverse proxy avec Nginx Proxy Manager

Un service Docker exposé sur un port comme 8080 fonctionne pour les tests, mais ce n’est pas idéal en production. Un visiteur ne doit pas retenir une adresse du type http://IP_VPS:8080. Il doit accéder à votre application depuis un vrai nom de domaine, avec HTTPS activé. C’est le rôle d’un reverse proxy : recevoir les requêtes sur les ports 80 et 443, puis les transmettre au bon conteneur.

Nginx Proxy Manager simplifie fortement cette étape. Il fournit une interface web pour créer des hôtes proxy, associer des sous-domaines à vos applications Docker et générer des certificats Let’s Encrypt sans écrire manuellement toute la configuration Nginx.

Créez d’abord un dossier dédié :

mkdir -p /opt/nginx-proxy-manager
cd /opt/nginx-proxy-manager

Créez ensuite le fichier compose.yaml :

nano compose.yaml

Ajoutez la configuration suivante :

services:
  npm:
    image: jc21/nginx-proxy-manager:latest
    container_name: nginx_proxy_manager
    restart: always
    ports:
      - "80:80"
      - "81:81"
      - "443:443"
    volumes:
      - npm_data:/data
      - npm_letsencrypt:/etc/letsencrypt

volumes:
  npm_data:
  npm_letsencrypt:

Lancez le service :

docker compose up -d

L’interface d’administration est ensuite disponible depuis :

http://IP_VPS:81

Lors de la première connexion, changez immédiatement les identifiants par défaut. L’interface d’administration ne doit jamais rester protégée par un mot de passe connu publiquement.

Pour publier votre WordPress, créez un nouvel hôte proxy dans Nginx Proxy Manager. Indiquez par exemple wordpress.mondomaine.fr comme nom de domaine, puis redirigez vers l’adresse IP du VPS et le port 8080. Dans l’onglet SSL, demandez un certificat Let’s Encrypt, activez Force SSL et, si disponible, HTTP/2.

Avant cette étape, le sous-domaine doit pointer vers l’adresse IP du VPS dans la zone DNS du nom de domaine. Sans enregistrement DNS correct, Let’s Encrypt ne pourra pas valider le certificat.

En production, l’idéal est de ne laisser ouverts publiquement que les ports nécessaires : 80, 443 et éventuellement 22 pour SSH. Les ports applicatifs comme 8080 doivent servir uniquement d’intermédiaire technique derrière le reverse proxy.

Cette organisation facilite aussi l’ajout de nouvelles applications. Pour chaque service, vous créez simplement un sous-domaine, un proxy host et un certificat. Vous évitez ainsi de multiplier les ports visibles, tout en gardant une administration claire et centralisée de vos déploiements Docker sur le VPS LWS au quotidien plus facilement.

Exemples d’applications self-hostées avec Docker

Une fois Docker installé, votre VPS LWS peut héberger de nombreux services self-hosted. Le principe reste presque toujours identique : un dossier par application, un fichier compose.yaml, des volumes persistants pour les données, puis un reverse proxy pour exposer le service avec un nom de domaine et HTTPS.

Voici quelques applications populaires à envisager :

Ces valeurs de mémoire sont indicatives. Elles varient selon le trafic, les extensions installées, la taille des bases de données et le nombre d’utilisateurs connectés. Pour un petit service interne, un VPS modeste suffit souvent. Pour un site public, un cloud personnel ou plusieurs applications simultanées, prévoyez davantage de RAM, de CPU et d’espace disque.

Docker est particulièrement intéressant pour le self-hosting, car il permet de remplacer plusieurs abonnements SaaS par des services hébergés sur votre propre serveur. Vous gardez la maîtrise des données, vous choisissez les versions installées et vous pouvez sauvegarder l’ensemble de votre infrastructure.

Dans tous les cas, commencez par une application simple, validez les sauvegardes, puis ajoutez progressivement de nouveaux services. Cette méthode limite les erreurs et rend l’administration du VPS plus lisible.

Gérer et maintenir ses conteneurs

Un déploiement Docker ne s’arrête pas au lancement des conteneurs. Pour garder un VPS stable, il faut prévoir les mises à jour, les sauvegardes, la surveillance des ressources et le nettoyage régulier de l’espace disque. Cette maintenance évite les interruptions de service et limite les mauvaises surprises lors d’une évolution applicative.

Mettre à jour une application

Pour mettre à jour une application gérée avec Docker Compose, placez-vous dans le dossier du projet :

cd /opt/wordpress-docker

Téléchargez les nouvelles images disponibles :

docker compose pull

Recréez ensuite les conteneurs avec les images mises à jour :

docker compose up -d

Cette commande conserve les volumes déclarés, ce qui permet de mettre à jour l’application sans supprimer les données persistantes. Après une mise à jour, vérifiez toujours les logs et le bon fonctionnement du site.

Pour nettoyer les anciennes images inutilisées :

docker image prune -f

Sauvegarder les données (volumes)

Les sauvegardes sont indispensables. Pour sauvegarder une base MySQL WordPress, vous pouvez utiliser :

docker exec wordpress_db mysqldump -u wp_user -p wordpress > backup_$(date +%Y%m%d).sql

Pour sauvegarder un volume complet :

mkdir -p /backup

docker run --rm \
  -v wordpress-docker_wp_data:/source \
  -v /backup:/dest \
  alpine tar czf /dest/wp_data_$(date +%Y%m%d).tar.gz /source

Ces commandes peuvent ensuite être automatisées avec cron et un script Bash, afin de produire des sauvegardes régulières sans intervention manuelle.

Monitoring des ressources

Surveillez également les ressources utilisées par vos conteneurs :

docker stats

Cette commande affiche la consommation CPU, mémoire, réseau et disque en temps réel. Pour obtenir plus d’informations sur un conteneur précis :

docker inspect wordpress_app

Nettoyage de l’espace disque

Enfin, contrôlez l’espace utilisé par Docker :

docker system df

Et supprimez les ressources inutilisées avec prudence :

docker system prune -f

Avant tout nettoyage important, assurez-vous que vos volumes utiles existent toujours et que vos sauvegardes sont récentes.

Vérification du bon fonctionnement

Après chaque installation, mise à jour ou redémarrage du VPS, prenez quelques minutes pour vérifier que vos conteneurs fonctionnent correctement. Commencez par lister les services actifs :

docker ps

Les conteneurs attendus doivent apparaître avec un état Up. Si un service manque ou redémarre en boucle, consultez immédiatement les logs :

docker compose logs [service]

Vérifiez ensuite l’accès applicatif depuis un navigateur. Pour WordPress, testez d’abord l’adresse directe, par exemple http://IP_VPS:8080, puis le nom de domaine HTTPS si vous utilisez Nginx Proxy Manager. Une application peut être active côté Docker mais inaccessible à cause d’un port fermé, d’un DNS mal configuré ou d’un certificat SSL non généré.

Contrôlez aussi les volumes :

docker volume ls

Les volumes du projet doivent être présents, notamment ceux de la base de données et des fichiers applicatifs. Testez enfin la politique de redémarrage. Redémarrez le VPS, reconnectez-vous en SSH, puis relancez :

docker ps

Si restart: always ou restart: unless-stopped est configuré, les services doivent revenir automatiquement. Terminez par un contrôle de l’espace disque :

docker system df

Erreurs fréquentes à éviter lors du déploiement des applications avec Docker

Même avec une installation correcte, certaines erreurs reviennent souvent lors des premiers déploiements Docker. La plupart se résolvent rapidement si vous commencez par lire les logs et vérifier les ports utilisés.

Erreur	Cause probable	Résolution
docker: command not found	Docker n’est pas installé ou la session ne trouve pas la commande	Relancer l’installation depuis le dépôt officiel Docker, puis ouvrir une nouvelle session SSH
docker compose: unknown command	Le plugin Compose n’est pas disponible	Installer le plugin Compose de Docker, puis vérifier avec docker compose version
address already in use	Le port demandé est déjà utilisé par un autre service	Identifier le service avec ss -tlnp, puis changer le port ou arrêter le processus concerné
permission denied	L’utilisateur n’a pas les droits nécessaires	Utiliser un compte autorisé ou ajouter l’utilisateur au groupe Docker
Données perdues après arrêt du stack	Aucun volume persistant n’était déclaré	Déclarer des volumes nommés pour les bases de données et fichiers applicatifs
Conteneur qui redémarre en boucle	Variable incorrecte, erreur applicative ou dépendance indisponible	Lire docker compose logs [service], corriger la configuration, puis relancer
Limite Docker Hub atteinte	Trop de téléchargements sans authentification	Se connecter avec docker login

Pour diagnostiquer un port occupé :

ss -tlnp

Pour consulter les logs d’un service :

docker compose logs wordpress

Pour vérifier tous les conteneurs, y compris ceux arrêtés :

docker ps -a

Dans la majorité des cas, le message d’erreur indique directement l’origine du problème.

Bonnes pratiques de sécurité

Docker simplifie le déploiement, mais il ne sécurise pas automatiquement votre VPS. Un conteneur reste un processus exécuté sur le serveur. Une image vulnérable, un mot de passe exposé ou un port ouvert inutilement peuvent créer un risque réel.

La première règle consiste à ne jamais exposer le daemon Docker sur Internet. Par défaut, Docker communique via un socket local. Conservez ce fonctionnement, sauf besoin avancé parfaitement maîtrisé. N’activez pas d’accès distant non protégé.

La deuxième règle concerne les secrets. Évitez d’inscrire les mots de passe directement dans compose.yaml, surtout si le fichier est sauvegardé dans Git. Utilisez plutôt un fichier .env non versionné :

MYSQL_DATABASE=wordpress
MYSQL_USER=wp_user
MYSQL_PASSWORD=mot_de_passe_fort_ici
MYSQL_ROOT_PASSWORD=mot_de_passe_root_fort_ici

Puis appelez les variables dans Compose :

environment:
  MYSQL_DATABASE: ${MYSQL_DATABASE}
  MYSQL_USER: ${MYSQL_USER}
  MYSQL_PASSWORD: ${MYSQL_PASSWORD}
  MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}

Ajoutez ensuite .env à votre fichier .gitignore.

La troisième règle est de limiter les ressources. Un conteneur mal configuré peut consommer trop de mémoire ou de CPU et ralentir tout le VPS. Vous pouvez définir des limites adaptées à vos services :

services:
  app:
    image: nginx:latest
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "0.50"

La quatrième règle est d’utiliser une politique de redémarrage :

restart: unless-stopped

ou :

restart: always

Cela permet aux services de revenir automatiquement après un redémarrage du VPS.

Maintenez aussi Docker, Ubuntu et vos images à jour. Avant une mise à jour importante, effectuez une sauvegarde et, si possible, un snapshot du VPS. Privilégiez les images officielles, les éditeurs vérifiés et les versions documentées. Évitez les images inconnues sans dépôt clair ni historique de maintenance.

Enfin, réduisez l’exposition réseau. En production, seuls les ports nécessaires doivent être ouverts : généralement 22 pour SSH, 80 pour HTTP et 443 pour HTTPS. Les ports applicatifs internes doivent idéalement passer par le reverse proxy, plutôt que d’être accessibles directement depuis Internet.

Trucs et astuces

---

Pour héberger vos applications Docker en France, le VPS KVM LWS offre une virtualisation KVM, Ubuntu préinstallé, un accès root complet, des sauvegardes automatiques et un support 7j/7. C’est une base adaptée pour déployer WordPress, n8n, Nextcloud, Uptime Kuma ou vos propres applications web conteneurisées.

Commander mon VPS KVM LWS.

Conclusion

Docker est une solution puissante pour déployer des applications sur un VPS LWS de manière propre, reproductible et évolutive. En isolant chaque service dans un conteneur, vous réduisez les conflits de dépendances, facilitez les mises à jour et gardez une organisation claire de votre serveur.⚡ Dans ce guide, vous avez installé Docker Engine sur Ubuntu, vérifié Docker Compose, lancé un premier conteneur Nginx, puis déployé un stack WordPress + MySQL avec volumes persistants. Vous avez aussi vu comment préparer une mise en production plus sérieuse avec Nginx Proxy Manager, surveiller les ressources, sauvegarder les données et éviter les erreurs fréquentes. 💥Docker ne remplace pas les bonnes pratiques d’administration : sécurité, sauvegardes, mises à jour et supervision restent indispensables.

Besoin d’un serveur VPS KVM performant et flexible ?

Découvrez nos offres VPS KVM haut de gamme : des ressources garanties et un contrôle total pour vos projets. Profitez d’un hébergement 100 % SSD, d’un accès root complet, le tout dans un datacenter en France. Démarrez dès maintenant à partir de 4,99 €/mois !

Je choisis mon VPS KVM

Mais sur un VPS KVM LWS, il offre une base solide pour héberger vos sites, outils internes, applications métiers et services self-hosted en 2026. Vous avez des questions, des ajouts ou des suggestions ? Ecrivez-nous dans la section Commentaires.