Aller au contenu

Migration Serveur vers Dokploy - Retour d'Expérience en Auto-Hébergement

De l'hébergement mutualisé au VPS sous Dokploy : moins cher, plus puissant

Migration Serveur vers Dokploy - Retour d'Expérience en Auto-Hébergement

Pendant des années, une partie de notre parc sites clients vivait sur de l'hébergement mutualisé ou infogéré : simple à commander, limité dès qu'on empile PHP, MySQL, crons, FTP et plusieurs vhosts. Les pics de charge, les montées de version PHP imposées et les sauvegardes opaques finissent par coûter cher en temps et en tickets support. Nous avons basculé vers un VPS cloud géré via Dokploy : Docker Compose, déploiements reproductibles, HTTPS automatique, Redis et MariaDB mutualisés proprement entre projets. Ce retour d'expérience décrit pourquoi nous l'avons fait, comment nous l'avons exécuté, et ce que nous en retirons après plusieurs mois en production. Si vous envisagez la même trajectoire pour votre agence ou votre parc sites, notre page hébergement web et infogérance situe notre approche globale.

Pourquoi nous avons quitté l'hébergement mutualisé pour un VPS sous Dokploy

Le déclencheur n'était pas l'envie de jouer aux DevOps un dimanche : c'était l'addition. Mutualisé multi-sites, options backup payantes, IP partagée parfois brûlée, PHP bloqué sur une version incompatible avec un client, SSH bridé, impossibilité de lancer Redis proprement. Chaque nouveau site ajoutait une ligne sur la facture sans mutualiser réellement les ressources. Dokploy sur VPS inverse la logique : un serveur dimensionné une fois, des services Docker isolés par projet, des images reproductibles, des rollbacks possibles. Nous avons comparé Dokploy à Coolify et Vercel : Dokploy a gagné sur le ratio simplicité / surface UI pour une petite équipe. Le VPS est chez un fournisseur européen type Hetzner ou Netcup, facturé une fraction de ce que coûtait nos serveurs précédents. Objectif : diviser la facture hébergement mensuelle de 60%, tout en doublant la marge de manœuvre technique. Ce n'est pas gratuit en temps de migration initiale, mais l'amortissement est rapide quand on gère plus d'une vingtaine de sites PHP.

Dokploy en pratique : installation, configuration et premier déploiement

La mise en place suit un ordre que nous réutilisons. Reset et durcissement du VPS : Debian à jour, pare-feu, SSH par clé, utilisateurs isolés. Installation Dokploy en service multi-sites, puis brique par brique : Redis partagé pour le cache, MariaDB avec une instance logique par site en production, monitoring Uptime, sauvegardes globales planifiées. Chaque site devient un projet Dokploy : image Docker custom (Apache, PHP, configuration vhost, variables d'environnement), volume persistant, certificat SSL Let's Encrypt automatique. Le premier déploiement est toujours le plus long : template Dockerfile, pipeline git ou upload, variables d'env, test healthcheck. Les suivants vont plus vite car l'ossature est là. Nous documentons chaque credential dans un registre d'accès centralisé, jamais dans le dépôt git. Pour un site PHP classique, le pattern est proche de ce que nous décrivons dans notre article PHP et Core Web Vitals : Redis, Brotli, cache page, stack simple à maintenir. Dokploy ajoute la couche orchestration sans nous forcer vers Kubernetes.

Migration de nos projets clients : zéro downtime et rollback automatique

Migrer dix sites sans coupure visible demande de la discipline, pas de la magie. Pour chaque projet : création du service Dokploy, adaptation de l'image (PHP version, extensions, Apache), utilisateur unix dédié + accès FTP/SFTP + base MariaDB isolée. Export base et fichiers depuis l'ancien hébergeur, import sur le nouveau stack, recette sur URL temporaire. Bascule DNS avec TTL réduit la veille, vérification SSL, smoke tests (homepage, formulaire, back-office). L'ancien site reste en lecture seule quelques jours en filet. En cas de problème, rollback DNS vers l'ancien hébergement : nous l'avons testé une fois sur un site vitrine, retour en arrière en moins de trente minutes. Les projets WordPress, PrestaShop legacy et sites sur mesure PHP suivent le même schéma ; seules les versions PHP et les crons diffèrent. Nous ne citons pas nos clients ici, mais le volume migré dépasse la dizaine de sites vitrine et e-commerce, de l'agence web au restaurant, de la marque mode au site institutionnel. Cette phase est celle qui justifie un devis infra distinct de la simple commande VPS. Nos tarifs développement sur-mesure intègrent ce type d'accompagnement quand le client sort d'un mutualisé étouffant.

Coûts, performances et fiabilité : notre bilan après 6 mois

Après environ six mois, le bilan est net. Coût mensuel hébergement global divisé par trois, pour une capacité CPU et RAM supérieure. Performances : TTFB médian autour de 10 à 40 ms sur les sites cache Redis, contre plusieurs centaines / milliers de millisecondes sur l'ancien serveur saturé. Fiabilité : monitoring Uptime sur chaque vhost, alertes mail, redémarrage container supervisé. Les mises à jour se font site par site via rebuild image, pas de " maintenance plateforme " opaque un vendredi soir. La charge opérationnelle existe : patches OS, renouvellement certs (automatisé), surveillance disque, restauration backup testée trimestriellement. Mais elle est prévisible et internalisée, plus dépendante du support niveau 1 d'un hébergeur mutualisé ou infogéré. Nous avons eu deux incidents mineurs (disque logs saturé, container OOM sur un site mal dimensionné), résolus en moins d'une heure chacun grâce aux snapshots et à la séparation par projet. Ce n'est pas l'infailibilité cloud hyperscaler : c'est un bon compromis PME / agence qui veut reprendre la main.

Ce que nous conseillons si vous envisagez la même migration

Si vous hébergez plus de cinq sites PHP ou un e-commerce qui souffre, le VPS + Dokploy mérite une étude. Pré-requis : accepter d'apprendre les bases Docker, documenter vos accès, tester une restauration backup avant la bascule DNS. Commencez par un site peu critique pour valider votre image type, puis industrialisez. Ne migrez pas tout un vendredi : un site par semaine avec recette est plus sûr. Comparez Dokploy et Coolify sur votre confort UI ; les deux font le job pour une petite structure. Dimensionnez le VPS avec marge : Redis + MariaDB + N Apache consomment vite la RAM. Enfin, séparez clairement infra et développement fonctionnel dans vos devis clients : la migration serveur n'est pas " offerte " dans une refonte graphique. Nous appliquons d'ailleurs la même méthode pour des parcs sites comparables à celui que nous venons de migrer pour notre propre compte et pour des structures voisines qui suivront le même schéma. Besoin d'un avis sur votre stack actuelle ? Notre accompagnement digital couvre l'audit infra et la bascule encadrée.

Adrien FERREIRA
  • Docker
  • Dokploy
  • Infra

Cet article vous a donné des idées pour votre projet ?

Autres articles de blog qui pourraient vous intéresser