Héberger WordPress sur votre propre VPS

Pourquoi auto-héberger WordPress sur un VPS

Les gains d'un WordPress sur VPS

• Ressources CPU/RAM allouées à votre machine : moins de ralentissements dus aux voisins
• Contrôle total de PHP-FPM, du serveur web et des extensions
• Cache objet Redis et cache de pages pour des temps de réponse divisés
• Accès SSH/WP-CLI complet pour automatiser maintenance et déploiements
• Isolation par conteneur : plusieurs sites clients sur un seul VPS
• Sauvegardes et règles de sécurité définies par vous, sans surcoût par site

Prérequis réalistes

Déploiement pas à pas

1. 01

   Composer WordPress, MariaDB et Redis

   Dans docker-compose.yml, déclarez wordpress:php8.3-fpm ou wordpress:apache, un service mariadb:11 et redis:alpine. Persistez wp-content et la base dans des volumes nommés, sur un réseau Docker interne.

2. 02

   Renseigner la base et les secrets

   Passez WORDPRESS_DB_* et des mots de passe forts via variables d'environnement. Ajoutez les clés de sécurité (salts) générées depuis l'API officielle WordPress dans WORDPRESS_CONFIG_EXTRA.

3. 03

   Lancer et installer WordPress

   Démarrez avec docker compose up -d puis ouvrez votre domaine pour l'assistant d'installation. Mieux : automatisez via WP-CLI (wp core install) pour des déploiements reproductibles d'un site à l'autre.

4. 04

   Placer le reverse proxy et le SSL

   Configurez Nginx/Caddy en HTTPS devant WordPress. Ajustez client_max_body_size pour les uploads, activez la compression gzip/brotli et le cache des assets statiques (images, CSS, JS) avec des en-têtes Cache-Control longs.

5. 05

   Activer le cache objet Redis

   Installez un plugin de cache objet (ex. Redis Object Cache), pointez-le vers le service redis, et activez-le : les requêtes répétées à la base sont servies depuis la mémoire, allégeant fortement MariaDB.

6. 06

   Durcir et sauvegarder

   Désactivez l'édition de fichiers dans l'admin (DISALLOW_FILE_EDIT), limitez les tentatives de connexion, et planifiez une sauvegarde nocturne de wp-content + dump SQL vers un stockage objet distant.

7. 07

   Se connecter la première fois

   Ouvrez l'URL du site : WordPress lance son installation en 5 minutes — langue, titre du site, puis création de VOTRE identifiant administrateur avec le mot de passe et l'e-mail de votre choix. Terminez-la sans attendre, une installation inachevée est offerte au premier visiteur.

Alerte PHP du 21/10/2026 (PHP2Shell) : mettre à jour WordPress ne corrige pas PHP

Vérifier puis corriger en cinq gestes

1. 08

   Lire la version PHP réellement servie

   Le plus fiable est dans WordPress : Outils > Santé du site > Infos > Serveur affiche la version PHP qui exécute vos pages. Sur un VPS sans Docker, méfiez-vous de php -v : il interroge le binaire en ligne de commande, qui peut être une autre version que celle de PHP-FPM, laquelle sert vos visiteurs. Interrogez le service lui-même avec php-fpm -v (ou php-fpm8.3 -v sur Debian et Ubuntu).

2. 09

   Contrôler la version dans le conteneur

   Avec Docker, lancez docker compose exec wordpress php -v : l'image embarque un seul PHP, donc ce résultat vaut pour le FPM ou le mod_php du conteneur. Comparez-le aux versions corrigées ci-dessus, en gardant la même branche (8.3.x doit atteindre 8.3.36, pas 8.4.27).

3. 10

   Récupérer l'image à jour

   Exécutez docker compose pull && docker compose up -d. Le pull télécharge la dernière image publiée pour votre tag (par exemple wordpress:php8.3-fpm), et up -d recrée le conteneur dessus. Vos volumes nommés conservent wp-content et la base. Si php -v affiche encore une ancienne version, l'image corrigée n'est pas encore publiée pour ce tag : revenez-y plus tard, ou changez de branche PHP si votre site la supporte.

4. 11

   Redémarrer PHP-FPM

   Une mise à jour de paquet ou de fichiers ne change pas le code déjà chargé par les processus en cours. Sur un serveur classique, redémarrez le service avec systemctl restart php8.3-fpm (adaptez le numéro de version) ; avec Docker, la recréation du conteneur suffit, sinon docker compose restart wordpress. Un simple reload est moins sûr qu'un restart pour être certain que tous les workers sont renouvelés.

5. 12

   Chercher des traces d'exploitation

   Une mise à jour ferme la porte, elle ne dit pas si quelqu'un est déjà entré. Parcourez les journaux d'accès et d'erreur de Nginx ou d'Apache (docker compose logs --since 72h wordpress avec Docker) à la recherche de plantages de workers PHP-FPM, de messages « out of memory » répétés et de requêtes inhabituelles de gros volume. Dans wp-content, listez les fichiers .php modifiés récemment avec find wp-content -name '*.php' -mtime -7, surtout dans uploads, où aucun script ne devrait se trouver. Au moindre doute, restaurez depuis une sauvegarde saine et changez les mots de passe et les salts.

6. 13

   Automatiser le contrôle avec WP-CLI et cron

   Notez que wp --info renvoie la version du PHP en ligne de commande, pas celle de PHP-FPM : gardez-le pour les scripts, pas pour juger l'exposition web. Planifiez plutôt une tâche cron hebdomadaire qui exécute docker compose pull puis compare le résultat de docker compose exec wordpress php -v à la version attendue, et vous prévient par e-mail en cas d'écart. Ainsi, la prochaine alerte de sécurité PHP ne dépend plus de votre mémoire.

7. 14

   Vérifier de nouveau

   Rouvrez Santé du site et relancez php -v dans le conteneur : les deux doivent afficher une version corrigée. Notez la date de l'opération dans votre journal de maintenance, et recommencez à chaque nouvelle publication de sécurité PHP.