Docker PrestaShop VPS : déployer en production sans stress

Après 193 projets PrestaShop livrés, j'ai constaté que la majorité des échecs en production ne viennent pas du code, mais de l'infrastructure. Déployer Docker PrestaShop sur un VPS semble simple en théorie — un docker compose up -d et c'est parti. En pratique, c'est là que les ennuis commencent : volumes perdus, certificats SSL expirés en pleine nuit, conteneurs qui tournent en root sans que personne ne s'en rende compte. Docker est utilisé par plus de 20 millions de développeurs dans le monde selon le Docker State of Application Development Report 2024, mais combien l'utilisent correctement en production e-commerce ?

Cet article est le guide terrain que j'aurais voulu avoir lors de ma première mise en production. Du choix du VPS jusqu'au site live stable, en passant par le docker-compose.yml commenté, la sécurisation HTTPS et le monitoring des conteneurs — vous aurez tout ce qu'il faut pour franchir le pas sereinement. Si vous cherchez l'architecture complète headless dans laquelle s'inscrit ce déploiement, consultez mon retour d'expérience sur le Hub Pro headless Nuxt + Docker.

Les 5 erreurs fatales du déploiement Docker PrestaShop en production

Cet article fait partie de notre dossier performance.

Problématique	Cause principale	Impact métier
Perte de données après un docker compose down	Volumes anonymes au lieu de volumes nommés pour MariaDB	Perte totale du catalogue produits et des commandes clients
Conteneurs exécutés en root	Image par défaut sans directive USER ni remapping	Faille de sécurité critique — un attaquant peut s'échapper du conteneur
Absence de healthcheck sur les services	Pas de directive healthcheck dans le Compose	PrestaShop démarre avant que MariaDB soit prête — erreurs 500 intermittentes
Image PHP non patchée en production	Tag latest figé ou image jamais reconstruite	Vulnérabilités connues exploitables (CVE), risque de compromission du serveur
Exposition directe du port 80/443 sans reverse proxy	Mapping de ports direct sur le conteneur PrestaShop	Pas de terminaison TLS propre, pas de rate limiting, TTFB dégradé

Stack de production Docker PrestaShop : le docker-compose.yml commenté

Voici la stack que j'utilise en production sur mes déploiements VPS. Elle comprend cinq services : PrestaShop (PHP-FPM), MariaDB, Redis pour le cache de sessions, Nginx en reverse proxy et Certbot pour le renouvellement automatique des certificats Let's Encrypt. L'ensemble tourne sur un VPS OVH (Hetzner ou Scaleway fonctionnent tout aussi bien) avec 4 Go de RAM minimum.

Le principe fondamental : séparer le réseau interne du réseau exposé. Seul Nginx est accessible depuis l'extérieur. MariaDB, Redis et PHP-FPM communiquent uniquement sur un réseau Docker interne, invisible depuis Internet.

1. Provisionner le VPS — Choisissez un VPS avec Ubuntu 22.04+ LTS, installez Docker Engine et Docker Compose v2 via le script officiel Docker. Créez un utilisateur dédié non-root et ajoutez-le au groupe docker.
2. Structurer le projet — Créez un répertoire /opt/prestashop-prod/ avec votre docker-compose.yml, un fichier .env (permissions 600) contenant les secrets (mots de passe DB, clé admin), et les dossiers de configuration Nginx.
3. Configurer les volumes nommés — Déclarez explicitement vos volumes dans la section volumes: du Compose : db_data pour MariaDB, ps_data pour les fichiers PrestaShop (images produits, modules). Ne jamais utiliser de volumes anonymes en production.
4. Déclarer les healthchecks — Ajoutez un healthcheck sur MariaDB (mysqladmin ping) et configurez depends_on avec condition: service_healthy sur le service PrestaShop. Cela évite les démarrages prématurés.
5. Configurer le reverse proxy Nginx — Le conteneur Nginx écoute sur les ports 80 et 443, termine le TLS avec les certificats Let's Encrypt, et proxy les requêtes vers PHP-FPM sur le réseau interne.
6. Activer le renouvellement Certbot — Un conteneur Certbot partage le volume des certificats avec Nginx. Attention aux rate limits Let's Encrypt : en phase de test, utilisez le flag --staging pour éviter de vous bloquer (5 certificats identiques par semaine maximum).
7. Définir la politique de redémarrage — Utilisez restart: unless-stopped sur tous les services. Contrairement à always, cette politique respecte un arrêt manuel volontaire tout en assurant le redémarrage après un crash ou un reboot serveur.

Un point critique souvent négligé : le fichier .env ne doit jamais être commité dans Git. Ajoutez-le à votre .gitignore et transmettez-le manuellement sur le serveur via scp ou un gestionnaire de secrets. Les variables à externaliser au minimum : MYSQL_ROOT_PASSWORD, MYSQL_PASSWORD, PS_DOMAIN, ADMIN_MAIL et ADMIN_PASSWD.

• Redis comme cache de sessions — Configurez le module PrestaShop pour stocker les sessions dans Redis plutôt que sur le filesystem. Gain mesuré : réduction du TTFB de 40 à 60% sur les pages authentifiées.
• Bind mounts pour la configuration Nginx — Les fichiers nginx.conf et les vhosts sont montés en bind mount (lecture seule avec :ro) pour faciliter les modifications sans reconstruire l'image.
• Logs centralisés — Configurez le driver de logs Docker en json-file avec rotation (max-size: 10m, max-file: 3) pour éviter que les logs saturent le disque du VPS.

Mon retour d'expérience personnel : sur mon propre Hub (alexandrecarette.fr), j'ai migré d'un hébergement mutualisé vers un VPS OVH avec Docker Compose. Le premier déploiement a cassé la prod à cause d'un volume MariaDB non persistant lors d'un docker compose down. J'ai perdu 2 heures de données de test. Depuis, je sépare systématiquement les volumes nommés des bind mounts, et j'ai ajouté une sauvegarde automatique avec docker exec + cron vers un bucket S3. Un simple docker exec mariadb mysqldump -u root -p$MYSQL_ROOT_PASSWORD prestashop | gzip > backup_$(date +%F).sql.gz dans un cron quotidien m'a évité bien des nuits blanches.

Checklist sécurité et performance pour la production

Selon Google (web.dev), un TTFB inférieur à 800 ms est requis pour valider le critère « Good » des Core Web Vitals. Sur un VPS correctement configuré avec Docker, Redis et Nginx, j'obtiens régulièrement un TTFB entre 180 et 350 ms sur PrestaShop — contre 900 ms à 1,4 s sur un mutualisé classique. La différence est directement mesurable dans Google Search Console.

PrestaShop représente environ 0,9 % des sites e-commerce mondiaux dans le top 1 million, soit plus de 300 000 boutiques actives selon BuiltWith. La plupart tournent encore sur du mutualisé. Ceux qui migrent vers un VPS Docker gagnent un avantage compétitif mesurable en performance et en SEO.

Dans un projet récent pour un client dans le secteur du mobilier haut de gamme, j'ai déployé cette stack exacte sur un Hetzner CX31. Le passage du mutualisé OVH au VPS Docker a réduit le Largest Contentful Paint de 3,8 s à 1,6 s, et le taux de rebond mobile a baissé de 12 points en 3 semaines. Les Core Web Vitals sont passés intégralement au vert.

Les solutions pour sécuriser et monitorer votre stack Docker PrestaShop

Solution	Complexité	Gain estimé
Volumes nommés pour MariaDB et les assets PrestaShop	Faible	Zéro risque de perte de données lors des opérations Docker
Reverse proxy Nginx avec terminaison TLS	Moyenne	TTFB réduit de 30 à 50%, headers de sécurité (HSTS, CSP) centralisés
Restriction de l'accès /admin par IP dans Nginx	Faible	Blocage de 99% des tentatives de brute force sur le back-office
Healthchecks + depends_on: condition	Faible	Élimination des erreurs 500 au démarrage, redémarrages propres
Monitoring avec docker stats et alertes cron	Moyenne	Détection proactive des fuites mémoire et de la saturation disque
Sauvegarde automatisée mysqldump + S3	Moyenne	RPO de 24h maximum, restauration en moins de 10 minutes

Pour le monitoring quotidien, trois commandes suffisent :

• docker stats --no-stream — Vue instantanée de la consommation CPU, RAM et réseau de chaque conteneur.
• docker system df — Espace disque utilisé par les images, conteneurs et volumes. Indispensable pour anticiper la saturation.
• docker logs --since 1h prestashop — Filtrer les logs récents pour identifier rapidement les erreurs PHP ou les timeouts.

N'oubliez pas de désactiver le mode debug PrestaShop en production (_PS_MODE_DEV_ à false) et d'activer les headers HSTS dans votre configuration Nginx (Strict-Transport-Security: max-age=31536000; includeSubDomains). Ces deux réglages prennent 30 secondes et changent radicalement la posture de sécurité de votre boutique.

"Use restart policies and limits on resources to prevent containers from consuming too many resources and ensure host machines remain stable. Configure logging drivers to aggregate logs efficiently and prevent sensitive data from being stored locally."

— Docker Documentation, Use Compose in production (2025)

Une fois votre VPS Docker opérationnel et stable, l'étape suivante logique est d'automatiser vos déploiements. J'ai documenté tout le pipeline dans mon article sur le CI/CD GitHub Actions pour PrestaShop headless — un git push sur main déclenche le build, les tests et le déploiement automatique sur le VPS.

Conclusion : votre boutique PrestaShop mérite une infrastructure solide

Déployer PrestaShop avec Docker sur un VPS n'est pas réservé aux DevOps seniors. Avec un docker-compose.yml bien structuré, des volumes nommés, un reverse proxy Nginx et des healthchecks, vous obtenez une infrastructure de production fiable, performante et reproductible. Les gains sont concrets : un TTFB divisé par trois ou quatre, des Core Web Vitals au vert, et la tranquillité d'esprit d'une stack que vous maîtrisez de bout en bout. La clé, c'est de ne jamais déployer en production sans avoir testé chaque brique séparément — et de toujours avoir une sauvegarde automatisée.

Vous préférez vous concentrer sur votre business ? Je prends en charge la configuration complète de votre stack Docker PrestaShop — du provisioning VPS à la mise en production sécurisée. Discutons de votre projet : contact@alexandrecarette.fr