Docker a complètement changé la façon de monter un environnement WordPress. Avec un seul fichier YML et quelques commandes Docker Compose, tu peux lancer un WordPress complet avec MariaDB, Nginx, PHP-FPM, outils de debug et même WP-CLI, sans polluer ta machine. Un projet, un dossier, un stack de conteneurs, et ton site tourne comme sur un serveur pro. Le vrai bénéfice se voit dès qu’il faut multiplier les projets ou travailler en équipe : tout le monde utilise exactement la même stack, les mêmes versions, la même configuration, sans “ça marche chez moi mais pas chez toi”.
Dans ce contexte, une architecture WordPress basée sur conteneurs devient un standard de facto. On parle de séparation des rôles entre serveur web Nginx, PHP-FPM et base de données MariaDB, le tout orchestré par un fichier docker-compose.yml propre et lisible. Ce type de setup colle bien avec les exigences modernes de performance, de sécurité, de CI/CD et de refonte régulière des sites. Pour quelqu’un qui doit gérer plusieurs WordPress, ou préparer une migration depuis un mutualisé vers un VPS, c’est presque dommage de ne pas passer par là. L’objectif ici est de détailler une configuration concrète, expliquée pas à pas, avec des conseils issus du terrain plutôt qu’un simple copier-coller de documentation officielle.
En bref
- WordPress + Docker Compose permet de déployer un environnement complet en une commande, avec une architecture reproductible.
- Un fichier YML bien structuré orchestre WordPress, MariaDB, Nginx et les volumes de données persistantes.
- La séparation des services dans plusieurs conteneurs simplifie la maintenance, les mises à jour et les déploiements.
- Ce type de stack convient autant au développement local qu’au déploiement sur un serveur de production.
- Le succès du setup repose sur la gestion des volumes, des sauvegardes, des variables d’environnement et de la configuration Nginx.
WordPress et Docker Compose avec MariaDB et Nginx : poser les bases d’un environnement propre
Pour bien visualiser, imagine un projet WordPress pour une petite agence de photo, hébergé sur un VPS classique. L’équipe veut un workflow propre, sans installer PHP, MySQL et Nginx à la main sur la machine. La solution logique aujourd’hui reste un ensemble de conteneurs orchestrés avec Docker Compose. Le cœur du dispositif se trouve dans un fichier docker-compose.yml qui décrit tout : services, réseaux, volumes, variables, ports. Une fois ce fichier en place, un simple « docker compose up -d » lance toute l’infrastructure.
Ce choix a plusieurs conséquences immédiates. D’abord, ton environnement devient isolé : pas de conflit de versions de PHP entre deux projets, pas de librairies globales installées partout. Ensuite, tout est déclaratif : la stack est décrite noir sur blanc dans le YML, versionnée dans git avec ton code. Tu peux cloner le dépôt sur un autre poste et obtenir un WordPress identique en quelques secondes. Enfin, la portabilité est réelle : du laptop de dev à la préproduction, puis à la prod, tu gardes la même structure, simplement avec des variables d’environnement adaptées.
Pour ce type de projet, la combinaison WordPress + PHP-FPM, MariaDB comme base de données et Nginx en frontal constitue un socle solide. MariaDB reste un choix pragmatique : compatible MySQL, éprouvée, performante même sur de petites machines. Nginx, lui, prend le rôle de serveur web et de reverse proxy : il gère les connexions HTTP/HTTPS, sert les fichiers statiques et transmet les requêtes PHP vers le conteneur WordPress. Docker Compose relie tout ça en interne avec un réseau dédié, de façon invisible pour l’utilisateur final.
Ce type d’architecture devient très intéressant si tu prévois de faire évoluer ton site : ajout de cache Redis, monitoring, automatisation de sauvegardes… Tout peut se greffer sous forme de services supplémentaires. En parallèle, tout ce qui relève du métier WordPress (thèmes, astuces de pagination, maillage interne, SEO) reste dans le code du site, sans mélange avec la couche serveur. Cette séparation nette reste un vrai atout sur la durée.
Prérequis techniques et organisation du projet Docker WordPress
Avant de parler configuration avancée, il faut quand même vérifier les briques de base. Sur macOS et Windows, Docker Desktop fournit tout le nécessaire, y compris Docker Compose. Sous Linux, l’installation passe par le moteur Docker et le binaire compose. Dans tous les cas, un accès au terminal est indispensable, car l’essentiel se pilote en ligne de commande. Côté éditeur, un VS Code ou équivalent facilite la vie pour éditer le YML, les fichiers Nginx et le code WordPress.
Une bonne pratique consiste à structurer ton dossier de projet dès le départ. Par exemple : un répertoire racine avec docker-compose.yml, un dossier wordpress pour les fichiers du CMS (souvent monté en volume), un dossier db pour les données MariaDB, éventuellement des répertoires dédiés aux thèmes et plugins sur mesure. Autre pièce essentielle : le fichier .env qui stocke les mots de passe et variables sensibles, à ne pas committer dans le dépôt.
Pour clarifier les choix selon le système, un petit tableau résume l’essentiel.
| Système | Prérequis spécifiques | Outil recommandé |
|---|---|---|
| Windows | WSL 2 ou Git Bash pour un shell Unix | Docker Desktop |
| macOS | Eventuellement Homebrew pour gérer Docker | Docker Desktop |
| Linux | Docker Engine et binaire docker compose installés nativement | Installation directe via le gestionnaire de paquets |
Une fois ce socle en place, la vraie question devient : comment organiser les services dans le YML pour que tout reste compréhensible dans six mois ? C’est justement ce que la suite va détailler avec un exemple concret.
Exemple complet de fichier docker-compose YML pour WordPress, MariaDB et Nginx
Passons au concret avec un exemple de fichier docker-compose.yml typique pour WordPress. L’idée est de rester lisible tout en couvrant ce qu’un projet sérieux demande : séparation des rôles, volumes persistants, variables d’environnement claires. On retrouve au minimum trois services : db (MariaDB), wordpress (PHP-FPM + code), nginx (serveur web). Chaque service a sa propre image, ses variables, ses volumes.
Une version simplifiée pourrait ressembler à ceci, une fois reformulée avec tes propres valeurs : un service MariaDB avec la base « wordpress », un utilisateur dédié, un mot de passe stocké côté .env. Un service WordPress basé sur l’image « wordpress:php8.2-fpm », relié à la base via le hostname « db ». Et enfin un service Nginx qui mappe le port 80 du host vers le port 80 du conteneur, en montant le même volume que WordPress en lecture seule pour servir les fichiers.
La clé, c’est le bloc volumes partagé entre WordPress et Nginx. C’est lui qui porte les fichiers du site : plugins, thème, uploads, configuration. Si tu recrées le conteneur WordPress, ces fichiers restent en place. Même chose pour la base avec un volume db_data qui garde toutes les tables MariaDB entre deux redémarrages. Sans ça, tu perdrais ton site à chaque « docker compose down » un peu trop agressif.
À l’usage, un certain nombre de choix méritent d’être assumés. MariaDB plutôt que MySQL pour un WordPress moyen trafic ? Tout à fait défendable, notamment pour des raisons de licence et de performances. Nginx plutôt qu’Apache ? Pour un setup moderne, ce choix a du sens, surtout avec PHP-FPM. On pourrait évidemment faire l’inverse, mais tu verras beaucoup plus de stacks WordPress récentes s’orienter vers Nginx. Ce n’est pas une vérité absolue, mais un mouvement de fond.
Ce genre de fichier YML reste d’ailleurs proche de ce qu’on trouve dans des exemples publics comme certains dépôts GitHub d’exercices Docker pour WordPress. Là où tu fais la différence, c’est en ajoutant ce qui manque souvent : des commentaires, une section réseaux explicite, et surtout une stratégie de sauvegarde claire. Sans ça, même le plus beau docker-compose.yml se transforme en piège à long terme.
Variables d’environnement et secrets dans un stack WordPress Dockerisé
Dès que tu ajoutes des mots de passe de base, des clés WordPress ou des infos de connexion SMTP, le sujet des variables devient central. L’idée saine reste de sortir tout ce qui est sensible du docker-compose.yml pour le mettre dans un fichier .env. Dans le YML, tu n’exposes que des références du type « ${WORDPRESS_DB_PASSWORD} ». C’est plus propre, plus facile à gérer quand tu passes d’un environnement local à la production.
Les variables couvrent au minimum trois catégories : la configuration de MariaDB (nom de base, utilisateur, mot de passe), la connexion côté WordPress (hôte de la base, identifiants, nom de la base) et d’éventuelles options comme les URLs du site. Tu peux même pousser plus loin en externalisant les constantes de sécurité de WordPress (AUTH_KEY, SECURE_AUTH_KEY, etc.) pour éviter de les laisser dans un wp-config.php versionné.
En pratique, beaucoup de développeurs sous-estiment cet aspect et copient-collent des identifiants en dur dans le YML. À court terme, ça fonctionne. À moyen terme, dès que tu veux partager le projet avec un collègue, mixer des environnements ou publier un exemple, ça devient un problème. Pour un site professionnel, surtout avec des enjeux de maintenance WordPress, externaliser correctement les secrets n’est plus une option, c’est juste du bon sens opérationnel.
Une fois ce chantier réglé, tu peux enfin te concentrer sur la partie la plus visible pour le visiteur : comment Nginx va servir le WordPress et optimiser les temps de réponse.
Configuration Nginx pour WordPress dans Docker : reverse proxy, PHP-FPM et performance
Dans ce type de stack, Nginx joue un double rôle. D’abord celui de serveur web classique qui renvoie des pages HTML, des images, des assets. Ensuite celui de reverse proxy vers PHP-FPM, qui gère l’exécution du code WordPress. Le conteneur Nginx monte le volume contenant les fichiers du site et charge un fichier de configuration, souvent « nginx.conf » ou une conf spécifique par vhost.
Une configuration de base pour WordPress couvre quelques blocs incontournables. Le bloc server définit le port 80, le nom de domaine et le dossier racine (généralement /var/www/html). Un bloc location / gère les URLs, en laissant WordPress router les requêtes via index.php quand aucun fichier statique ne correspond. Un bloc location ~ .php$ envoie les requêtes PHP au conteneur WordPress, via fastcgi_pass vers « wordpress:9000 » ou similaire.
Au-delà du strict minimum, tu peux ajouter des directives utiles : mise en cache basique des assets statiques, compression gzip, restrictions d’accès à certains fichiers sensibles (wp-config.php, fichiers .ht*). Nginx est assez souple pour gérer tout ça sans se transformer en usine à gaz, tant que tu restes discipliné. Un mauvais pattern utilisé un peu partout consiste à copier une conf Apache en bloc et essayer de la “traduire” vers Nginx, ce qui crée souvent des problèmes bizarres.
Pour un projet qui vise la production, rajouter un proxy HTTPS avec Let’s Encrypt ou un reverse proxy type Traefik reste très pertinent. Mais même en restant sur un simple Nginx HTTP derrière Cloudflare ou un autre CDN, tu peux déjà obtenir des performances correctes. WordPress, bien configuré, avec des plugins raisonnables et un cache propre, n’a pas vocation à ramer sur un petit VPS récent.
Cette couche Nginx montre bien un point important : Docker simplifie la gestion de l’infrastructure, mais ne remplace pas la réflexion sur la configuration. Un nginx.conf mal écrit dans un conteneur reste un mauvais nginx.conf, même si tout tourne dans un joli stack containerisé. La logique reste celle d’un admin système classique, simplement appliquée à des services encapsulés.
Gestion des volumes, sauvegardes et migrations dans un environnement containerisé
La question des données revient tout le temps : où se trouvent les fichiers WordPress, où se trouve la base de données MariaDB, comment on sauvegarde et comment on restaure. Dans un setup Docker, la réponse passe par les volumes. Le volume qui contient /var/www/html stocke les fichiers du site : cœur WordPress, thèmes, plugins, uploads. Le volume attaché à /var/lib/mysql (ou /var/lib/mysql/ pour MariaDB) garde l’intégralité de la base.
Pour les sauvegardes, deux stratégies se combinent. D’abord, archiver régulièrement le volume WordPress (ou au minimum wp-content) avec une commande tar ou un outil de backup, puis envoyer l’archive vers un stockage externe. Ensuite, exporter la base MariaDB via un mysqldump exécuté dans le conteneur ou via un job cron sur l’hôte. Le flux classique ressemble à : « docker exec -t nom_du_conteneur_db mysqldump -u user -p motdepasse base > backup.sql », puis compression et externalisation.
Du coup, migrer un WordPress “classique” vers une stack Docker devient très concret. Il suffit de déposer les fichiers existants dans le volume WordPress, importer le dump SQL dans le conteneur MariaDB, adapter wp-config.php aux nouvelles variables d’environnement, puis vérifier les URLs. Ce n’est pas toujours trivial, mais ce n’est certainement pas plus compliqué qu’une migration entre deux serveurs classiques.
Un dernier point souvent oublié : les mises à jour. D’un côté, tu continues à mettre à jour WordPress, ses plugins et ses thèmes via l’interface d’admin, comme toujours. De l’autre, tu dois aussi mettre à jour les images Docker : nouvelles versions de PHP, MariaDB, Nginx. Là, un « docker compose pull » suivi d’un « docker compose up -d » avec test préalable sur un environnement de préprod reste la moins mauvaise option. L’envie de tout mettre à jour en direct en production sans test reste une mauvaise habitude, que ce soit avec ou sans conteneurs.
Workflow de développement : WP-CLI, VS Code et commandes Docker Compose utiles
Une fois le stack en place, le quotidien du développeur tourne autour de quelques commandes Docker Compose. Pour lancer les services en arrière-plan, « docker compose up -d ». Pour voir les logs, « docker compose logs -f ». Pour arrêter proprement et libérer les ressources, « docker compose down ». Ces trois commandes couvrent déjà une bonne partie des besoins. En cas de modification du docker-compose.yml, un nouveau « up -d » recrée les services nécessaires.
À côté de ça, l’intégration de WP-CLI change vraiment l’expérience. En exécutant « docker compose exec wordpress wp plugin list », tu obtiens immédiatement la liste des extensions installées dans ton site. Tu peux installer, activer, désactiver des plugins, gérer les utilisateurs, importer du contenu, tout ça depuis le terminal. C’est très pratique pour automatiser des tâches répétitives ou pour débugger un site quand l’admin WordPress ne répond plus correctement.
Pour rendre tout ça plus agréable, un éditeur comme VS Code couplé à l’extension Docker donne une vision claire de tes conteneurs, images, volumes. Tu peux voir les logs en un clic, ouvrir un shell dans un conteneur WordPress, parcourir les fichiers du volume sans quitter l’IDE. Pour un projet où tu construis un thème custom ou un plugin sur mesure, ce mix “code + infra” dans la même interface change vraiment le confort de travail.
Il reste un point un peu piégeux : la gestion des permissions de fichiers, surtout sous Linux. Si le conteneur WordPress tourne avec un utilisateur différent de celui de ton système, tu peux te retrouver avec des fichiers appartenant à « www-data » dans le volume, difficiles à modifier depuis ton éditeur. Pour contourner ça, beaucoup de développeurs utilisent la directive user dans le YML, avec quelque chose comme « user: « ${UID}:${GID} » ». Cela aligne les permissions dans le conteneur sur celles de ton utilisateur local.
Ce type de workflow montre bien que Docker n’est pas réservé aux DevOps. Pour un développeur WordPress qui code des thèmes, qui travaille son SEO WordPress ou son maillage interne, avoir un environnement reproductible et pilotable à la commande devient un vrai levier de productivité. On gagne du temps sur les installations bancales et on se concentre davantage sur le métier.
Liste de commandes et réflexes utiles avec Docker Compose
Pour résumer les gestes utiles dans un environnement WordPress containerisé, quelques commandes méritent de rester sous la main.
- docker compose up -d pour démarrer ou redémarrer l’ensemble des services en arrière-plan.
- docker compose logs -f nginx ou docker compose logs -f wordpress pour suivre les logs en temps réel par service.
- docker compose exec wordpress wp plugin update –all pour mettre à jour tous les plugins via WP-CLI.
- docker compose restart pour relancer les services sans toucher aux volumes.
- docker system prune pour nettoyer les images et volumes non utilisés et récupérer de l’espace disque.
Avec ces quelques commandes, le pilotage au quotidien d’un stack WordPress + MariaDB + Nginx devient presque routinier, ce qui est exactement le but recherché.
Déploiement, multi-sites et limites de l’approche Docker pour WordPress
Jusqu’ici, on a surtout parlé du cas d’un site unique. Mais dès qu’une agence commence à accumuler les projets, la question des multiples instances WordPress surgit. Deux approches reviennent souvent. La première consiste à créer un stack Docker distinct par site, chacun avec son docker-compose.yml, son réseau et son couple MariaDB/WordPress. L’isolation est maximale, le debug reste simple, mais le nombre de conteneurs augmente rapidement.
La seconde approche s’appuie sur un reverse proxy en frontal, Nginx ou Traefik, et plusieurs services WordPress derrière, chacun avec sa base. Le proxy gère les différents noms de domaine, le routage HTTP/HTTPS et parfois les certificats Let’s Encrypt. Cette stratégie permet de mutualiser certains éléments tout en gardant une isolation logique par projet. Pour un parc de sites moyen, c’est souvent plus agréable à vivre au quotidien, surtout si tu ajoutes un monitoring centralisé.
Dans les deux cas, Docker reste compatible avec un usage avancé de WordPress : multi-sites, intégration d’outils de cache, frontends découplés, etc. Pour les très gros sites à fort trafic, on ne parle plus d’un simple docker-compose sur un VPS, mais d’orchestrateurs comme Kubernetes, de bases MariaDB ou MySQL gérées séparément, de stockages externes pour les médias. Docker devient alors une brique parmi d’autres, pas la solution globale.
Il faut aussi rester lucide sur les limites. Sur un petit VPS, l’overhead de Docker peut se faire sentir, surtout si tu accumules des services auxiliaires (phpMyAdmin, Redis, outils de monitoring). La montée en compétence sur Docker et la compréhension de la stack réseau demandent un peu de temps. Et surtout, l’illusion “Docker sécurise tout” reste dangereuse : un WordPress mal maintenu, avec des plugins vulnérables, le reste même dans un conteneur.
Pour autant, rejeter entièrement Docker pour WordPress n’a plus beaucoup de sens en 2026. Même utilisé uniquement en développement local, un stack containerisé réduit déjà les différences entre les postes, facilite les revues de code et simplifie les POC. Tu peux fort bien développer sous Docker et déployer ensuite sur un serveur “classique” si ton contexte ne permet pas encore de conteneuriser la production.
Cas d’usage concrets et arbitrages techniques autour de WordPress Dockerisé
Pour rendre tout ça plus tangible, prenons trois cas typiques. Premier cas : un freelance qui gère cinq sites vitrine sous WordPress. Pour lui, un stack Docker par client reste un bon compromis. Chaque projet a son dossier, son docker-compose.yml, sa base MariaDB. Il peut démarrer seulement le site sur lequel il travaille, sans charger les autres. La sauvegarde se fait projet par projet, ce qui reste assez intuitif.
Deuxième cas : une petite agence qui héberge quinze sites sur un même serveur dédié. Là, un reverse proxy mutualisé devant plusieurs services WordPress prend plus de sens. L’agence peut partager une partie de la configuration Nginx, centraliser la gestion des certificats SSL, surveiller les logs depuis un point unique. En contrepartie, la complexité augmente, notamment pour le routage et les déploiements coordonnés.
Troisième cas : une refonte majeure d’un site existant. Docker devient alors un bac à sable très pratique. Tu peux charger une copie des fichiers et de la base, brancher le tout sur une nouvelle stack Nginx/PHP/MariaDB, tester une refonte WordPress complète, expérimenter des versions de PHP différentes, tout ça sans toucher à la prod. Une fois la nouvelle version prête, la bascule se fait en modifiant les DNS ou le reverse proxy.
Au final, Docker Compose pour WordPress agit un peu comme un jeu de construction modulaire. Tu peux démarrer très simple et complexifier au fur et à mesure : ajout d’un cache, d’un outil de monitoring, d’un conteneur de backup, etc. Ce qui compte, c’est de garder une vision claire de ce que fait chaque service et de documenter la stack pour ne pas transformer ton YML en puzzle obscur pour le “toi” de dans six mois.
Cette architecture WordPress avec Docker Compose convient-elle à la production ?
Oui, un stack WordPress avec Docker Compose, MariaDB et Nginx peut fonctionner en production, à condition de traiter les sujets classiques : sauvegardes régulières des volumes et de la base, configuration Nginx soignée, mises à jour testées en préproduction, monitoring et stratégie de sécurité (mots de passe, plugins, accès SSH). Le docker-compose.yml doit être versionné et documenté pour faciliter les évolutions.
Faut-il absolument utiliser MariaDB ou peut-on rester sur MySQL ?
Les deux fonctionnent avec WordPress. MariaDB est souvent choisie pour ses performances et sa compatibilité, mais si ton hébergeur ou ton infrastructure tourne déjà en MySQL, tu peux très bien utiliser l’image officielle MySQL dans le service db de ton YML. L’essentiel est de rester cohérent entre dev, préprod et prod.
Comment gérer plusieurs sites WordPress avec un seul fichier docker-compose
Tu peux définir plusieurs services WordPress et plusieurs bases dans le même docker-compose.yml, chacun avec ses volumes et ses variables. En frontal, un service Nginx ou Traefik joue le rôle de reverse proxy et route les domaines vers le bon conteneur. Cette approche mutualise une partie de la stack mais demande une organisation stricte des noms de services et des volumes.
Puis-je utiliser Docker Compose seulement pour le développement local
Oui, et c’est déjà un gros gain. Tu peux travailler sur un environnement WordPress complet en local avec Docker Compose, puis déployer sur un serveur non conteneurisé. Tant que tu gardes des versions proches (PHP, base) entre les deux, tu limites les surprises. Beaucoup d’équipes adoptent cette approche comme étape intermédiaire avant de conteneuriser aussi la production.
Docker rend-il mon site WordPress plus rapide
Docker en lui-même n’accélère pas un site. La performance dépend surtout de la configuration de Nginx, de PHP-FPM, de MariaDB, du cache et des plugins utilisés. Docker facilite en revanche le fait de tester et d’ajuster ces éléments, et de dupliquer un environnement performant sur plusieurs machines sans erreur humaine.
