Cloudron, CasaOS et Coolify sur un VPS

Ce que vous construisez

Vous choisissez un outil autant que vous en installez un. Trois panneaux promettent de transformer un VPS nu en un hôte d'applications que l'on pilote à la souris : Cloudron, CasaOS et Coolify. Ce guide place chacun sur la même machine Ubuntu 24.04 fraîche, installe une première application, puis regarde de près les parties dont personne ne fait de capture d'écran : le TLS, les sauvegardes, les mises à jour, le coût en mémoire et la difficulté à repartir. À la fin, vous saurez lequel vous convient, ou si la réponse honnête est « aucun des trois, utilisez simplement Docker Compose ».

Aucun n'est magique. Sous les trois se trouve le même Docker Engine que vous pourriez piloter à la main. Ce qu'un panneau vous vend, en argent, en RAM ou en dépendance, ce sont quatre corvées faites à votre place : l'installation d'applications en un clic, les certificats TLS automatiques, les sauvegardes planifiées et la gestion des utilisateurs. Si ces quatre points valent une vraie surcharge pour vous, un panneau mérite sa place. Si vous faites tourner un ou deux services et que vous aimez savoir exactement ce qui se trouve sur votre machine, lisez d'abord la section « Passez votre chemin » et épargnez-vous la peine.

Prérequis communs et les pièges honnêtes

Les trois supposent un VPS KVM, pas une virtualisation par conteneurs. Docker a besoin d'un vrai noyau, et Cloudron refuse catégoriquement OpenVZ et LXC. Vérifiez avec systemd-detect-virt : kvm ou qemu convient, openvz ou lxc non. Sur un forfait KVM, la commande affiche kvm, et sur du matériel physique elle affiche none ; l'un ou l'autre signifie que vous pouvez continuer.

Au-delà de cela, les chiffres divergent, et c'est la première chose qui oriente le choix.

• RAM. CasaOS tourne sans peine sur 1 Go ; il a grandi sur du matériel Raspberry Pi et reste léger. Coolify veut 2 Go et deux cœurs de processeur comme plancher, dont environ 600 Mo pour Coolify lui-même. Cloudron demande 2 Go au minimum et se sent vraiment mieux avec 4 Go, car il fait tourner un serveur de messagerie et une base de données avant même que vous n'installiez la moindre application.
• Un domaine et un DNS que vous contrôlez. Cloudron et Coolify veulent tous deux un vrai domaine avec un DNS fonctionnel. Cloudron veut idéalement un accès API à votre fournisseur DNS afin de créer lui-même les enregistrements et les certificats génériques (wildcard). CasaOS fonctionnera sur une simple adresse IP, mais alors vous n'avez aucun TLS.
• Ports. Les trois ont besoin des ports 80 et 443 ouverts pour HTTP et HTTPS. Coolify sert en plus son tableau de bord sur le 8000, et utilise le 6001 pour son canal temps réel et le 6002 pour le terminal dans le navigateur. Gardez le port 22 ouvert pour SSH sur chacun d'eux.

Faites pointer le DNS vers la machine avant de commencer. Un panneau qui ne peut pas résoudre son propre nom d'hôte ne peut pas demander de certificat, et vous passerez la première heure à déboguer cela au lieu du logiciel. Faites pointer un enregistrement A vers l'IP du serveur, et pour Coolify ajoutez un enregistrement générique (*.apps.example.com) afin que chaque application déployée obtienne son propre sous-domaine.

Cloudron : l'appliance soignée et affirmée

Ce que c'est. Cloudron est une plateforme commerciale qui transforme un serveur entier en une appliance gérée. Elle fait tourner son propre proxy inverse, sa base de données et sa pile de messagerie, ainsi qu'un App Store organisé d'applications empaquetées (Nextcloud, WordPress, Gitea, Mattermost et d'autres). Elle vise les personnes qui veulent leurs applications gérées, avec des mises à jour, des certificats et des sauvegardes automatiques, et qui sont prêtes à payer pour cela.

Installation. Il exige une machine propre et la prend entièrement en main. Lancez ceci sur un serveur Ubuntu 24.04 (Noble) frais, et rien d'autre :

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

Le script installe Docker, nginx, une base de données et la pile de messagerie, puis redémarre. Quand la machine revient, ouvrez https://<your-ip>, acceptez le certificat auto-signé temporaire, et terminez la configuration dans le navigateur : pointez-le vers votre domaine, choisissez votre fournisseur DNS, et il met en place son propre tableau de bord sur my.example.com.

Ajouter une première application. Dans le tableau de bord, ouvrez l'App Store, cliquez (par exemple) sur Nextcloud, choisissez le sous-domaine files.example.com, et appuyez sur Installer. Cloudron crée l'enregistrement DNS, demande le certificat Let's Encrypt, met en place la base de données, câble l'authentification unique (SSO) et planifie une sauvegarde, le tout sans que vous touchiez à un fichier de configuration. C'est tout l'argument, et il tient.

TLS et sauvegardes. Le plus solide des trois. Chaque sous-domaine d'application reçoit un certificat Let's Encrypt automatique, renouvelé pour vous. Les sauvegardes sont planifiées et intégrées, vers un répertoire local, S3 ou un autre stockage distant, avec restauration par application et même clonage en un clic d'une application vers un nouveau sous-domaine.

Coût et licence, à lire avant de vous engager. Cloudron est un produit payant avec un palier gratuit plafonné : le plan gratuit autorise deux applications. Installez une troisième application et vous butez sur un mur payant ; un abonnement payant (Pro ou Max, facturé au mois ou à l'année, tous deux avec applications illimitées) débloque davantage. C'est le fait le plus important à retenir sur Cloudron. Il est soigné précisément parce que c'est une entreprise, et le palier gratuit tient plus de l'essai prolongé que d'un foyer pour une pile qui grandit.

Mode d'échec, la règle de la machine propre. Essayez d'installer Cloudron sur un serveur qui fait déjà tourner quelque chose et la configuration s'interrompt avant de rien changer :

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's installation.
Please start with a fresh Ubuntu install and run this script again.

La cause n'est pas un caprice gratuit. Cloudron épingle des versions précises de nginx, Docker et Node et les intègre en profondeur, il ne peut donc pas cohabiter avec vos propres copies. La solution est une image Ubuntu 24.04 fraîche et rien d'autre : pas de serveur web, pas de Docker, pas même un pare-feu que vous auriez configuré à la main. Si vous avez démarré la mauvaise image, la configuration refuse aussi tout ce qui n'est pas une version Ubuntu LTS prise en charge (22.04 ou 24.04) sur x86-64 ; ARM, LXC et OpenVZ ne sont pas pris en charge du tout.

Deuxième mode d'échec, les certificats génériques exigent une API DNS. Choisissez l'option DNS « Manual » pendant la configuration au lieu de donner à Cloudron un jeton API, et il ne peut pas créer d'enregistrements ni de certificat générique à votre place. Chaque nouvelle application vous oblige alors à ajouter un enregistrement DNS à la main avant que le certificat puisse être émis, et le tableau de bord attend cet enregistrement. Donnez à Cloudron un accès API à un fournisseur DNS pris en charge (Cloudflare, Route 53, DigitalOcean et d'autres) et tout le processus devient un seul clic.

CasaOS : le tableau de bord gratuit pour home lab

Ce que c'est. CasaOS, d'IceWhale, est un tableau de bord libre et gratuit qui se pose au-dessus de Docker et vous donne un écran d'accueil, une boutique d'applications et un gestionnaire de fichiers. Il est né du monde des serveurs domestiques, ses réflexes sont donc ceux du home lab : rapide à mettre en place, interface conviviale et peu de cérémonie. Il vise les bricoleurs qui veulent un visage plus agréable sur Docker sans payer personne.

Installation. Une seule ligne, et il n'exige pas une machine propre :

curl -fsSL https://get.casaos.io | sudo bash

L'installeur ajoute un ensemble de services systemd (casaos, casaos-gateway, casaos-app-management, et d'autres). Confirmez que la passerelle est bien démarrée avant d'ouvrir un navigateur :

systemctl status casaos-gateway

Quand elle tourne, le tableau de bord est à http://<your-ip> (HTTP simple, port 80). Créez un compte local et vous êtes dedans.

Ajouter une première application. Ouvrez l'App Store, choisissez une application, cliquez sur Installer. CasaOS écrit un projet Docker Compose en coulisses et expose l'application sur un port de l'hôte, par exemple http://<your-ip>:8080. Sa boutique propose la sélection habituelle des serveurs domestiques, ainsi un serveur multimédia Jellyfin sur un VPS ou une photothèque Immich auto-hébergée est à quelques clics. Vous pouvez aussi importer n'importe quel docker-compose.yaml de votre choix, ce qui est la vraie force : les applications sont des conteneurs ordinaires, pas un format propriétaire.

TLS et sauvegardes, le point faible. C'est ici que le « gratuit » montre ses limites. CasaOS sert tout en HTTP simple par défaut, y compris son propre tableau de bord. Il n'y a pas de Let's Encrypt intégré, ni de sauvegarde planifiée intégrée. Vos données vivent dans des volumes Docker sous /DATA, et les sauvegarder est votre travail (un restic ou un tar planifié par cron).

Mode d'échec, pas de TLS, et c'est silencieux. Rien n'échoue. Vous installez une application, ouvrez http://<your-ip>:8080, et cela fonctionne, sur une connexion non chiffrée que votre navigateur marque « Non sécurisé ». Les mots de passe et les cookies de session traversent le réseau en clair. Pire, CasaOS a connu de vraies vulnérabilités d'exécution de code à distance dans son tableau de bord (CVE-2023-37265 et CVE-2023-37266, un contournement d'authentification qui s'enchaînait jusqu'à une compromission complète de l'hôte), donc exposer ce port HTTP directement à Internet est un risque réel, pas une chicane de style. La solution est de ne jamais exposer CasaOS directement. Placez devant un proxy inverse qui termine le TLS, comme nginx avec un certificat Let's Encrypt de Certbot, Caddy ou un Cloudflare Tunnel, et redirigez vers CasaOS sur le réseau local seulement. Notez que CasaOS occupe déjà le port 80, donc votre proxy et CasaOS se disputeront ce port à moins de déplacer d'abord CasaOS vers un autre port.

Coût. Réellement gratuit, pour toujours, sans plafond d'applications. Vous payez en exploitation : le TLS, les sauvegardes et le durcissement vous appartiennent.

Coolify : le PaaS auto-hébergé

Ce que c'est. Coolify est une plateforme en tant que service (PaaS) auto-hébergée et open source, dans l'esprit de Heroku ou Vercel sur votre propre machine. Son unité native n'est pas « installer cette application empaquetée » mais « déployer ce dépôt Git » : connectez un dépôt, et Coolify le construit (via Nixpacks ou votre propre Dockerfile) et l'expédie, en le redéployant à chaque poussée. Il propose aussi des bases de données et des services en un clic. Il vise les développeurs qui déploient leur propre code et veulent un déploiement à la poussée sans louer un PaaS.

Installation.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Le script installe Docker et lance la propre pile de conteneurs de Coolify. Vérifiez qu'ils sont sains avant d'aller plus loin :

docker ps --format 'table {{.Names}}\t{{.Status}}'

Vous devriez voir coolify, coolify-db, coolify-redis, coolify-realtime et coolify-proxy afficher tous Up. Le tableau de bord est à http://<your-ip>:8000. Créez votre compte administrateur immédiatement, car la page d'inscription reste ouverte jusqu'à la création du premier compte, et quiconque l'atteint en premier contrôle le serveur. Ensuite, définissez le domaine de votre instance et faites pointer un enregistrement DNS générique (*.example.com, ou *.apps.example.com) vers la machine afin que Coolify puisse attribuer à chaque application déployée son propre sous-domaine.

Ajouter une première application. Connectez une source Git (GitHub, GitLab ou une simple URL de dépôt), choisissez une branche, définissez le domaine et déployez. Le proxy Traefik intégré de Coolify route le sous-domaine et demande le certificat. Pour du logiciel prêt à l'emploi, le catalogue de Services déploie des choses en quelques clics : la même pile d'automatisation de flux n8n que vous câbleriez sinon à la main est une seule entrée, tout comme Uptime Kuma pour la surveillance d'une page de statut.

TLS et sauvegardes. Let's Encrypt automatique par application via le Traefik fourni, donc chaque sous-domaine déployé obtient un certificat. Les sauvegardes sont d'abord orientées base de données : vous pouvez planifier des dumps Postgres et MySQL vers un stockage compatible S3. La sauvegarde de l'instance entière (la configuration de Coolify elle-même, qui vit sous /data/coolify) est plus manuelle, exportez-la et stockez-la vous-même.

Coût et licence. L'édition auto-hébergée est entièrement open source et gratuite, sans plafond d'applications. Il existe un Coolify Cloud optionnel (payant) qui héberge le plan de contrôle pour vous pendant que vos applications tournent toujours sur vos propres serveurs, pratique mais pas obligatoire.

Mode d'échec, l'application se déploie mais son domaine ne charge pas. Le tableau de bord fonctionne bien sur http://<ip>:8000, la construction passe au vert, mais l'URL propre de l'application renvoie une erreur de connexion ou un 404 page not found de Traefik. Cela pointe vers le proxy ou vers le DNS, pas vers votre application. Deux causes courantes. D'abord, les ports 80 ou 443 étaient déjà pris quand le proxy a tenté de démarrer, donc son conteneur est mort avec une erreur Docker :

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

Ensuite, l'enregistrement DNS générique est manquant, donc Traefik ne reçoit jamais de requête pour ce nom d'hôte. Si à la place la carte du serveur entier dans Coolify affiche « Server is not reachable », c'est une autre panne : Coolify ne parvient pas du tout à parler au socket Docker du serveur, généralement un démon Docker arrêté ou une clé SSH cassée. Lisez la vraie raison dans les journaux avant de deviner :

docker logs coolify-proxy --tail 100

Corrigez-la depuis la page Proxy : appuyez sur Restart Proxy, ou réinitialisez la configuration du proxy par défaut et redémarrez-le, puis attendez environ deux minutes qu'il se stabilise. Gardez le port 8000 accessible depuis votre seule IP (ou rouvrez-le temporairement quand le proxy se comporte mal) plutôt que de le laisser ouvert au monde entier, car il sert le tableau de bord en HTTP simple, et la documentation même de Coolify indique que les ports 8000, 6001 et 6002 peuvent être fermés une fois que le tableau de bord est servi via son propre domaine.

Surcharge de ressources sur le même VPS

Mesurée au repos sur la même machine de 4 Go, avant de déployer la moindre charge réelle. Vérifiez la vôtre avec free -m et docker stats --no-stream plutôt que de vous fier à un seul chiffre, car le total bouge avec votre mélange d'applications.

• CasaOS est le plus léger. Le panneau est un petit ensemble de services Go ; comptez environ 150 à 300 Mo de surcharge en plus des conteneurs que vous faites tourner.
• Coolify fait tourner plusieurs conteneurs de support qui lui sont propres (l'application, un Postgres, un Redis, un service temps réel et Traefik), il se situe donc autour de 600 Mo à 1 Go au repos avant que vous ne déployiez quoi que ce soit.
• Cloudron est le plus lourd au repos, car il fait tourner son propre nginx, sa base de données, sa pile de messagerie et sa supervision, que vous les utilisiez ou non ; prévoyez 1 à 1,5 Go au repos. C'est pourquoi il demande 2 Go au minimum et respire mieux avec 4 Go.

Sur un petit VPS de 2 Go, CasaOS laisse le plus de place pour de vraies applications et Cloudron en laisse le moins. Si votre forfait est de 2 Go et que vous voulez Cloudron avec son serveur de messagerie qui tourne, prévoyez d'agrandir la machine.

Mises à jour, sauvegardes et dépendance comparées

Mises à jour. Cloudron met à jour la plateforme et chaque application pour vous, selon un calendrier qu'il a testé : le moindre effort et le plus d'accompagnement. Coolify se met à jour depuis son propre tableau de bord en un bouton. CasaOS met à jour le panneau via son script d'installation ou apt, mais les applications que vous avez installées, c'est à vous de les tirer (pull) et de les redémarrer.

Dépendance, la partie qui mord la deuxième année. CasaOS est le moins verrouillant : ses applications sont des projets Compose ordinaires, vous pouvez donc copier le docker-compose.yaml et les volumes sous /DATA vers n'importe quel autre hôte et continuer. Coolify est au milieu : vos déploiements sont vos propres Dockerfiles et dépôts, mais leur configuration vit dans la base de données de Coolify, donc changer d'hôte signifie recréer les projets de l'autre côté. Cloudron est le plus verrouillant : les applications sont empaquetées par Cloudron, et si vos données partent proprement grâce à ses excellentes sauvegardes, l'empaquetage, lui, ne part pas, vous redéployez donc sur la plateforme de destination. Données portables, plomberie non portable.

Lequel choisir

La version courte, puis la sortie de secours. Choisissez Cloudron si vous voulez le serveur le moins manuel des trois, ferez tourner plusieurs applications empaquetées, et paierez un abonnement annuel pour un TLS, des sauvegardes et des mises à jour gérés. Choisissez CasaOS s'il s'agit d'un home lab derrière votre propre réseau ou un proxy inverse, que vous voulez un visage convivial sur Docker, et que vous refusez de payer quoi que ce soit. Choisissez Coolify si vous déployez votre propre code depuis Git et voulez un déploiement à la poussée avec TLS automatique, sans le prix d'un PaaS hébergé. Si aucun des trois ne vous décrit, la section suivante est la réponse honnête.

Passez votre chemin si...

Soyez honnête sur votre échelle. Si vous ne faites tourner qu'une ou deux applications, ou si vous voulez comprendre et contrôler exactement ce qui se trouve sur votre machine, laissez tomber les panneaux. La surcharge et la dépendance n'en valent pas la peine pour une petite pile stable. Le chemin du fait-maison est un proxy inverse devant vos propres fichiers Compose : Traefik avec TLS automatique devant plusieurs applications Docker Compose vous donne l'équivalent du HTTPS en un clic sans aucun du poids d'un panneau, et vous sauvegardez avec une tâche restic planifiée par cron que vous comprenez vraiment.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

Pour une seule application phare, l'argument est encore plus clair : une installation de Nextcloud sur Docker avec TLS et sa propre routine de sauvegarde est un fichier Compose et un certificat. Dresser une appliance entière pour la faire tourner serait tout en coût et sans bénéfice. Si vous hésitez encore sur quoi faire tourner avant de décider comment, le guide de ce qui vaut la peine d'être auto-hébergé en 2026 est le meilleur point de départ.

FAQ

Ai-je vraiment besoin d'un panneau d'auto-hébergement ?

Seulement si vous accordez de la valeur aux quatre choses qu'un panneau automatise, sur plusieurs applications : installations en un clic, TLS automatique, sauvegardes planifiées et gestion des utilisateurs. Pour un ou deux services, un simple Docker Compose derrière Traefik fait le même travail de TLS avec bien moins de surcharge et aucune dépendance. Les panneaux rapportent quand vous faites tourner de nombreuses applications et que votre temps vaut plus que la RAM qu'ils coûtent.

Quel panneau est le meilleur pour un débutant ?

Pour un home lab où rien n'est exposé à l'Internet hostile, CasaOS est le départ le plus doux : une commande et une interface conviviale, sans facture à payer. Mais vous devez placer un proxy inverse qui termine le TLS devant avant d'exposer quoi que ce soit, car il livre du HTTP simple. Si vous voulez un TLS et des sauvegardes gérés pour vous et que vous êtes prêt à payer, Cloudron est le plus accompagnant, dans la limite de son palier gratuit de deux applications.

Cloudron est-il gratuit ?

En partie. Le palier gratuit autorise deux applications, ce qui suffit pour l'essayer ou pour une très petite installation. Au-delà, Cloudron est un abonnement payant, facturé au mois ou à l'année, avec applications illimitées sur les paliers payants. C'est un produit commercial avec un plan gratuit plafonné, pas un logiciel gratuit, alors prévoyez un budget si votre pile va grandir.

Puis-je faire tourner ces panneaux à côté de mes applications existantes ?

Cloudron : non. Il exige une machine Ubuntu propre et s'interrompt si nginx, Docker ou Node sont déjà installés, car il gère la machine entière. CasaOS et Coolify sont plus accommodants, puisqu'ils installent leur propre pile Docker et peuvent en principe partager une machine, mais tous deux veulent les ports 80 et 443, ils entrent donc en collision avec tout serveur web ou proxy que vous faites déjà tourner. Sur une machine qui héberge déjà des choses, un panneau est généralement le mauvais outil ; tournez-vous vers Traefik et Compose à la place.

Comment quitter un panneau plus tard ?

Planifiez votre sortie avant d'en avoir besoin. Depuis CasaOS, copiez le docker-compose.yaml de l'application et ses volumes /DATA vers le nouvel hôte et redémarrez-les. Depuis Coolify, exportez la configuration de chaque projet et pointez-la vers les mêmes dépôts sur la destination. Depuis Cloudron, restaurez les données depuis ses sauvegardes dans des applications fraîchement installées sur la nouvelle plateforme, car l'empaquetage Cloudron ne voyage pas, seules les données le font. Dans tous les cas, testez la restauration sur une machine jetable avant de démonter l'ancienne.