Hosting Docker Compose. Twój compose, nasz serwer.

1. Docker comme type d’application, pas comme produit supplémentaire

De nombreux fournisseurs d’hébergement traitent Docker comme une fonctionnalité réservée aux forfaits VPS ou cloud les plus coûteux, car il exige davantage d’isolation et de contrôle qu’un hébergement mutualisé classique. Sur Saplo, Docker est simplement l’un des types d’applications du catalogue, aussi accessible que WordPress ou un site statique, sans seuil tarifaire distinct pour le simple fait d’exécuter des conteneurs.

En pratique, dans le catalogue Saplo, 152 applications sur 166 utilisent Docker en arrière-plan. Le moteur de conteneurs fonctionne donc sur chaque Box compatible Docker, que le client installe un modèle prêt à l’emploi depuis le catalogue ou qu’il construise sa propre image custom.

Pour ta propre image Docker, le type d’application custom permet d’indiquer ton propre Dockerfile ou ton fichier docker-compose, sans être limité aux recettes prêtes à l’emploi du catalogue. Tu disposes ainsi d’une liberté totale pour les projets non standard.

2. Docker Registry privé inclus

Le catalogue d’applications contient également Docker Registry: un registre d’images privé (image officielle registry:2), avec une interface simple permettant de parcourir dans le navigateur les dépôts, les tags et les couches. L’ensemble est protégé par une authentification basic avec un identifiant et un mot de passe générés aléatoirement à l’installation.

Pour une équipe qui construit ses propres images en CI/CD, cela permet de conserver des images privées sans compte Docker Hub et sans les plafonds de pull rate que les comptes gratuits des registres publics imposent lors des téléchargements fréquents d’images pendant les déploiements.

L’interface du registre sert de reverse proxy vers l’API du même registre, sous un seul domaine et sans CORS. Les commandes docker login, docker push et docker pull fonctionnent donc directement via le domaine de l’application, sans ports supplémentaires à configurer séparément.

3. Combien de RAM les applications Docker nécessitent-elles

Les applications Docker habituelles du catalogue Saplo indiquent un minimum de 1 à 2 Go de RAM (Baserow, Chatwoot, Flowise, n8n, Windmill, Typebot: 1 à 2 Go), car le conteneur de l’image officielle contient généralement davantage de dépendances qu’une installation PHP légère ou une simple application statique.

Box M (2 Go de RAM) permet d’héberger confortablement une application Docker typique. Box L (6 Go de RAM) permet d’en exécuter plusieurs en parallèle. C’est un minimum réaliste pour un ensemble plus important d’outils (CRM, chat et automatisation réunis), afin qu’ils ne se disputent pas la mémoire. Pour un ensemble encore plus grand d’applications Docker, Box XL est à envisager: ses 12 Go de RAM offrent une vraie réserve pour continuer à développer ta boîte à outils sans devoir vérifier souvent quelle application consomme le plus de mémoire sur une Box donnée.

Pour tes propres images Docker personnalisées (type custom), les exigences de RAM dépendent de ce que l’image fait réellement. Vérifie donc la consommation de mémoire en local avant de choisir une Box, comme pour tout autre déploiement de conteneurs.

4. Docker sur Saplo ou Docker sur un VPS vierge?

Pour faire tourner Docker sur un VPS, tu dois l'installer toi-même, configurer le pare-feu en fonction des ports des conteneurs et paramétrer manuellement le proxy inverse avec SSL pour chaque service lancé. Si tu ne connais pas l'administration de Linux, c'est une véritable barrière à l'entrée.

Sur Saplo, le conteneur LXC de la Box dispose déjà d’une prise en charge de Docker configurée (keyctl, nesting). Les commandes docker run et docker compose up fonctionnent donc dès ta connexion en SSH. Le reverse proxy et le SSL des applications accessibles publiquement se configurent dans le panneau dès que tu connectes un domaine.

À ressources comparables, l’écart de prix entre un VPS vierge et une Box avec Docker est généralement faible. En revanche, le temps nécessaire pour lancer le premier service est nettement plus court sur Saplo, car tu n’as pas à configurer le moteur de conteneurs à partir de zéro.

5. À qui cela s'adresse

Pour un développeur qui souhaite déployer sa propre image Docker sans partir d’un VPS vierge, le type d’application custom sur Box M ou Box L fournit un environnement prêt à l’emploi, compatible Docker et doté d’un SSL automatique pour le domaine connecté.

Pour une équipe qui construit ses propres images en CI/CD, le Docker Registry privé du catalogue d’applications supprime la nécessité d’un compte sur un registre public ainsi que les limites de pull rate associées.

Pour tester plusieurs applications Docker du catalogue en parallèle (par exemple un CRM, un chat et une automatisation), Box L avec 6 Go de RAM offre assez d’espace pour en faire tourner plusieurs à la fois sans qu’elles se disputent la mémoire.

6. Premier déploiement de ta propre image Docker sur Saplo

Après avoir sélectionné le type d’application custom, connecte-toi en SSH (à partir de Box M) et prépare un docker-compose.yml ou un Dockerfile pour ton projet, comme sur n’importe quel autre environnement disposant de Docker.

Une fois le domaine connecté, configure le reverse proxy et le SSL du service public depuis le panneau Saplo en indiquant le port sur lequel ton conteneur est à l’écoute, sans devoir configurer manuellement nginx ni gérer le certificat côté client.

Configure les volumes de données de façon à ce que les données de l’application survivent au redémarrage du conteneur et soient couvertes par les sauvegardes de la Box, si ton plan inclut la sauvegarde.

Pour les applications multi-conteneurs (par exemple une base de données, une application et un worker dans un même docker-compose), vérifie que la somme de la RAM de tous les conteneurs respecte la limite de la Box choisie avant de lancer l’ensemble.

Le Docker Registry privé du catalogue d’applications te permet de stocker tes propres images, que tu télécharges ensuite sur la Box via docker pull sous le même domaine, sans avoir de compte sur un registre public.

7. CI/CD et construction automatisée des images Docker

Le flux CI/CD classique consiste à construire une image dans un système externe (GitHub Actions, GitLab CI), à la pousser vers le Docker Registry privé sur Saplo, puis à lancer docker pull et à redémarrer le conteneur sur la Box de production.

Tu peux automatiser la dernière étape (pull et redémarrage après la publication d’une nouvelle image) grâce à un simple script déclenché via SSH ou à un webhook qui déclenche un workflow dans n8n installé sur la même Box.

Le Docker Registry privé supprime les plafonds de pull rate imposés par les comptes gratuits des registres publics. Lors de déploiements fréquents (plusieurs fois par jour), cela peut devenir un vrai problème pour un compte sans formule payante chez un fournisseur externe.

Pour les équipes qui travaillent dans plusieurs environnements (staging, production), tu peux conserver des tags d’images distincts dans le même registre privé. Cela facilite le suivi de la version de l’application qui s’exécute dans chaque environnement.

8. Bonnes pratiques pour tes images Docker personnalisées en production

Épingler une version précise de l'image de base (par exemple node:20.11-alpine, plutôt que node:latest) évite qu'une mise à jour publiée par le mainteneur modifie soudainement le comportement de ton application après une nouvelle reconstruction du conteneur, souvent sans avertissement clair.

Une construction en plusieurs étapes (multi-stage build) permet de garder l'image de production finale compacte, sans outils de compilation ni dépendances de développement. Cela accélère le transfert de l'image vers le registre et du registre vers le serveur de production, tout en réduisant la surface d'attaque du conteneur.

Les variables d’environnement et les secrets (mots de passe, clés API) ne doivent jamais être directement intégrées à l’image Docker comme des valeurs inscrites dans le Dockerfile, mais être transmises au lancement du conteneur. En effet, une image construite avec un secret intégré peut se retrouver dans un registre et être récupérée par quiconque y a accès.

Un Healthcheck configuré dans l'image ou dans docker-compose permet de détecter automatiquement que le conteneur fonctionne, mais que l'application qu'il contient ne répond plus, par exemple parce qu'un processus est bloqué. Sans Healthcheck, le problème pourrait passer inaperçu, car le conteneur continuerait officiellement à fonctionner.

Il vaut mieux diriger les journaux du conteneur vers la sortie standard (stdout/stderr) que vers des fichiers internes au conteneur. Les fichiers disparaissent avec le conteneur lors de sa suppression, tandis que la sortie standard est plus facile à collecter et à consulter avec les outils habituels de Docker.

Revoir régulièrement les images et les tags encore utilisés dans ton registre privé permet de le garder ordonné et de libérer l'espace disque occupé par les anciennes versions devenues inutiles au fil des déploiements CI/CD.

9. L'écosystème Docker Hub et les images communautaires comme point de départ

Le grand nombre d’images Docker officielles et prêtes à l’emploi disponibles publiquement (bases de données, serveurs d’applications, outils utilitaires) permet de déployer la plupart des services courants sur Saplo sans écrire son propre Dockerfile à partir de zéro, en utilisant des images déjà éprouvées et activement maintenues.

Le catalogue d’applications Saplo contient des recettes prêtes à l’emploi fondées sur de nombreuses images officielles (par ex. prestashop/prestashop, n8nio/n8n, flowiseai/flowise). Le client n’a donc même pas besoin de savoir que l’application fonctionne sous Docker, car toute la configuration est déjà préparée à l’avance.

Pour tes besoins spécifiques (type d’application custom), l’accès à l’ensemble de l’écosystème Docker Hub et à d’autres registres publics d’images permet d’utiliser des images prêtes à l’emploi comme point de départ et de les adapter à tes exigences avec ton propre Dockerfile construit sur l’image de base.

Le Docker Registry privé du catalogue d'applications Saplo complète cet écosystème. Il permet de stocker tes propres images construites sans avoir à les publier publiquement sur Docker Hub, ce qui peut constituer une exigence de sécurité importante pour les projets commerciaux ou propriétaires.

Pour les équipes techniques qui suivent l'évolution de l'écosystème de conteneurs (nouveaux outils d'orchestration, nouvelles pratiques de construction d'images), l'accès SSH complet au conteneur LXC avec prise en charge de Docker sur Saplo n'impose aucune limitation par rapport aux possibilités offertes par un serveur Docker classique et auto-administré.

10. Tester les images Docker avant leur déploiement en production

Il est préférable de tester une nouvelle image Docker en local ou dans un conteneur temporaire sur le même Box avant de remplacer le conteneur de production existant. Une erreur dans la nouvelle image, par exemple une version de dépendance incompatible, peut sinon rendre le service indisponible jusqu'à l'annulation du déploiement.

Attribuer aux images du registre privé un tag de version, plutôt que le seul tag latest, permet de revenir facilement à la version précédente qui fonctionnait si la nouvelle s'avère problématique après son déploiement sur le conteneur de production.

Pour les applications multiconteneurs (docker-compose avec une base de données, une application et un worker), teste l'ensemble de la modification comme un tout, pas seulement le conteneur modifié. Les incompatibilités de versions entre conteneurs reliés sont en effet une cause fréquente de problèmes invisibles lorsqu'un élément est testé seul.

Un Healthcheck configuré dans l'image aide à détecter automatiquement que le nouveau conteneur ne fonctionne pas correctement après le déploiement. Associé à un simple script de rollback vers le tag précédent de l'image, il permet de revenir rapidement sur une modification problématique sans interruption prolongée du service. Même s'il ne constitue pas un système CI/CD complet, ce mécanisme simple de test et de rollback réduit considérablement le risque d'une indisponibilité prolongée due à un seul déploiement d'image mal testé.

11. Résumé: Docker, une fonctionnalité standard et non premium

Considérer Docker comme un élément d'infrastructure standard, disponible sur chaque Box, et non comme une fonctionnalité réservée aux plans les plus élevés et les plus coûteux reflète la généralisation de cette méthode de conditionnement des applications ces dernières années. Que tu choisisses une recette prête à l'emploi dans le catalogue ou que tu déploies ta propre image personnalisée via le type d'application custom, le moteur de conteneurs est déjà configuré et prêt à l'emploi dès le premier jour sur ton Box. Pour les équipes techniques habituées à Docker sur leurs propres machines de développement, passer à Saplo ne change donc pas leurs habitudes. Il suffit de transporter la même méthode de travail, déjà maîtrisée, vers un environnement de production avec prise en charge du domaine et du certificat SSL.