WordOps 3.22 : j’ai testé le gestionnaire LEMP WordPress automatisé

J’avais toujours repoussé WordOps. Quand on gère déjà nginx à la main, l’idée d’un outil qui réécrit tes configs et prend le contrôle des stacks PHP + MySQL + Redis a quelque chose d’inconfortable. Et puis un collègue m’a dit que ça lui avait économisé deux heures sur la mise en prod d’un nouveau site client. J’ai monté un VPS de test Debian 12 chez OVH et j’ai regardé.

Ce qu’est WordOps

WordOps est un outil CLI qui automatise le déploiement de stacks LEMP (Linux + Nginx + MariaDB + PHP-FPM) optimisées pour WordPress. Version actuelle : 3.22.0. Il gère la création de sites, les certificats Let’s Encrypt, le cache (FastCGI, Redis), et les versions PHP.

C’est le successeur de EasyEngine v3, réécrit en Python.

Installation

wget -qO wo wops.cc && sudo bash wo

[warning]C’est un curl | bash déguisé. L’URL wops.cc pointe vers un script qui installe nginx, MariaDB, PHP-FPM et WordOps lui-même. Sur un serveur de prod, je ne fais pas ça. Sur un VPS de test dédié à cet essai, j’ai accepté le compromis.[/warning]

L’installation prend environ 5 minutes. À la fin, WordOps a installé nginx 1.26, MariaDB 10.11, PHP-FPM 8.3, Redis, et exposé un backend d’administration sur le port 22222.

Créer un site WordPress en 30 secondes

# Site WordPress avec cache FastCGI nginx + SSL Let's Encrypt + PHP 8.3
wo site create example.com --wpfc --php83 --letsencrypt

# Résultat : site WordPress installé, nginx configuré, base de données créée,
# SSL obtenu et renouvelé automatiquement

C’est là que WordOps impressionne vraiment. Ce qui prend 15 minutes à la main (nginx vhost, PHP-FPM pool, base MySQL, wp-cli install, certbot) se fait en 30 secondes. La config nginx générée est propre — FastCGI cache correctement configuré, headers de sécurité présents, Gzip activé.

# Passer au cache Redis (plus fin que FastCGI, cache par utilisateur)
wo site update example.com --wpredis

# Vérifier les infos du site
wo site info example.com

Les commandes qui servent vraiment

wo stack status          # État de tous les services (nginx, php, mysql, redis)
wo stack restart nginx   # Redémarrer un service spécifique
wo log show --nginx      # Logs d'erreur nginx en temps réel
wo clean --fastcgi       # Vider le cache FastCGI
wo info                  # Versions et chemins de tous les composants

# Changer la version PHP d'un site (sans downtime)
wo site update example.com --php84

# Lister les sites
wo site list

Ce qui m’a posé problème

Le backend d’administration (port 22222) est exposé avec une authentification basique. Le mot de passe par défaut est lisible dans les logs d’installation. Premier réflexe : changer ça.

# Sécuriser le port 22222
wo site update 22222 --letsencrypt --hsts

Le deuxième problème : WordOps prend la main sur nginx globalement. Si tu avais une config nginx existante sur le serveur, elle va être écrasée ou entrer en conflit. WordOps n’est pas fait pour coexister avec un nginx géré à la main — c’est un choix binaire.

Sur mon VPS de test, c’était acceptable. Sur you.arewel.com qui a une config nginx construite progressivement sur 18 mois, je ne toucherais pas.

Performances mesurées

Sur un VPS OVH VPS Starter (2 vCPU, 2 Go RAM, SSD), avec WordPress + cache FastCGI configuré via wo site create --wpfc :

• TTFB sur une page en cache : ~18 ms
• TTFB sur une page hors cache (PHP) : ~320 ms

Sans WordOps, sur une config nginx + PHP-FPM manuelle équivalente sur le même tier de VPS : ~15 ms en cache, ~290 ms hors cache. La différence est dans le bruit.

Verdict

WordOps fait ce qu’il promet. L’installation de sites est rapide, les configs générées sont correctes, la gestion des certificats est transparente. Pour quelqu’un qui déploie régulièrement de nouveaux sites WordPress, le gain de temps est réel.

Ce que je n’aime pas : perdre le contrôle granulaire sur nginx. Les configs générées par WordOps sont bonnes mais pas toujours ce que je ferais à la main. Et quand WordOps fait une mise à jour de stack, il peut modifier des fichiers que tu as touchés.

Je n’ai pas migré you.arewel.com sur WordOps. Le gain ne justifie pas le risque de migration sur un site en production avec une config existante. Pour un nouveau VPS sans historique ? Je l’utiliserais sans hésiter.

Article hors série