Déployer vos applications avec CapRover sur un VPS

Déployer sur un VPS brut implique de configurer manuellement Nginx, les certificats TLS, Docker et les redémarrages à chaque release. CapRover supprime cette friction : il s'appuie sur Docker Swarm pour orchestrer vos conteneurs, génère les certificats Let's Encrypt, et propose un déploiement par git push ou par image Docker pré-construite. Son catalogue « One-Click Apps » couvre WordPress, PostgreSQL, Redis, MongoDB, Ghost et plus d'une centaine d'autres services, chacun dans son propre conteneur. Là où Heroku ou Render facturent au dyno ou à l'heure de calcul, CapRover tourne sur votre VPS au prix fixe mensuel de votre serveur — c'est l'option naturelle pour les développeurs et agences qui veulent la productivité d'un PaaS sans en subir la facture variable.

CapRover réserve de la RAM pour Docker Swarm et son moteur de build. Un VPS de 2 Go de RAM et 1 vCPU suffit pour des projets personnels et quelques petites applications ; montez à 4 Go de RAM et 2 vCPU dès que vous hébergez plusieurs apps avec leurs bases de données. Prévoyez 30 Go de SSD minimum, car chaque build Docker consomme de l'espace temporaire. Un nom de domaine wildcard est fortement recommandé — par exemple *.apps.votredomaine.com — afin que CapRover génère des sous-domaines à la volée pour chaque application. Les ports 80, 443 et 3000 (panneau d'administration) doivent être ouverts. Depuis la version 1.14, CapRover requiert Docker avec une API version 1.43 minimum ; la version 1.14.1 corrige un problème de compatibilité introduit par Docker v29 qui avait élevé ce minimum à 1.44. Vérifiez votre version avec docker version | grep API avant toute mise à jour.

CapRover expose un webhook de build par application, accessible dans l'onglet « Deployment » de chaque app. Ce webhook déclenche un déploiement complet à chaque appel HTTP POST. Pour l'intégrer à GitHub Actions, stockez trois secrets dans votre dépôt : CAPROVER_SERVER (l'URL de votre instance), APP_NAME (le nom de l'application CapRover) et APP_TOKEN (le token de déploiement affiché dans l'onglet Deployment). Une action officielle est disponible sur le GitHub Marketplace (caprover/deploy-from-github) : elle prend en charge la construction du tar de déploiement et l'envoi à CapRover en une seule étape. Exemple de job minimal : après un npm run build qui produit un dossier dist/, créez une archive contenant dist/ et votre captain-definition, puis invoquez l'action avec vos trois secrets. La combinaison webhook + GitHub Actions remplace avantageusement la CLI locale sur les équipes : un push sur main déclenche un déploiement automatique, aucune clé d'accès serveur ne circule entre les développeurs.

CapRover repose nativement sur Docker Swarm : ajouter de la capacité se fait depuis le panneau sans reconfigurer vos applications. Dans le menu « Cluster », saisissez l'IP du nouveau nœud, la clé SSH root associée et l'IP de votre nœud maître telle que visible depuis ce nouveau nœud. CapRover installe Docker sur la cible et l'intègre au Swarm. Une contrainte importante : le cluster nécessite un registre Docker privé configuré par défaut, car le nœud maître doit pouvoir pousser les images construites vers les nœuds workers. CapRover propose d'en déployer un automatiquement. Autre contrainte à connaître : les applications avec un Persistent Directory activé ne peuvent s'exécuter que sur un seul nœud (Docker Swarm ne partage pas les volumes de fichiers entre hôtes). Pour scaler une application avec état, optez pour une base de données externe ou un service de stockage objet.

CapRover propose une sauvegarde native depuis le panneau : « Settings → Export Backup ». L'archive produite contient la configuration de toutes vos applications, les variables d'environnement et les paramètres Nginx. Elle ne contient pas les données des volumes persistants. Pour sauvegarder une base de données PostgreSQL hébergée via One-Click, la méthode recommandée est pg_dump planifié par cron, avec archivage vers un stockage externe. Les volumes Docker sont accessibles sous /var/lib/docker/volumes/ ; une copie de ces dossiers, base stoppée, constitue une sauvegarde de bas niveau. Testez toujours la restauration sur un VPS de staging avant de compter sur une sauvegarde en production.

Voici les messages d'erreur réellement rencontrés dans les issues GitHub et les forums CapRover, avec leurs causes et correctifs.