Cloudron, CasaOS ou Coolify : quel panel VPS choisir ?

Ce que vous allez mettre en place

Vous choisissez autant un outil que vous n’en installez un. Trois panels promettent de transformer un VPS vierge en serveur d’applications pilotable en quelques clics : Cloudron, CasaOS et Coolify. Ce guide installe chacun d’eux sur la même machine Ubuntu 24.04 fraîchement préparée, déploie une première application, puis examine attentivement les aspects rarement montrés dans les captures d’écran : TLS, sauvegardes, mises à jour, consommation mémoire et difficulté à changer de solution. À la fin, vous saurez lequel vous convient, ou si la réponse honnête est : « aucun, utilisez simplement Docker Compose ».

Aucun de ces outils n’est magique. Les trois reposent sur le même Docker Engine que vous pourriez gérer manuellement. Ce qu’un panel vous vend, contre de l’argent, de la RAM ou une forme de dépendance, ce sont quatre tâches prises en charge : l’installation d’applications en un clic, les certificats TLS automatiques, les sauvegardes planifiées et la gestion des utilisateurs. Si ces quatre fonctions justifient réellement la surcharge pour vous, un panel peut être utile. Si vous exécutez un ou deux services et voulez savoir exactement ce qui se trouve sur votre serveur, lisez d’abord la section « N’utiliser aucun des trois » et évitez-vous cette complexité.

Prérequis communs et points à connaître

Les trois solutions supposent un VPS KVM, et non une virtualisation par conteneurs. Docker a besoin d’un vrai kernel, et Cloudron refuse catégoriquement OpenVZ et LXC. Vérifiez avec systemd-detect-virt : kvm ou qemu convient, tandis que openvz ou lxc ne convient pas. Sur une offre KVM, la commande affiche kvm ; sur une machine bare metal, elle affiche none. Dans les deux cas, vous pouvez continuer.

Pour le reste, les exigences diffèrent. C’est le premier critère qui oriente le choix.

• RAM. CasaOS fonctionne correctement avec 1GB ; il a été conçu à l’origine pour du matériel Raspberry Pi et reste léger. Coolify demande au minimum 2GB et deux cœurs CPU. Coolify lui-même en utilise environ 600 MB. Cloudron nécessite au minimum 2GB, mais fonctionne réellement mieux avec 4GB, car il exécute un serveur de messagerie et une base de données avant même que vous installiez une application.
• Un domaine et un DNS que vous contrôlez. Cloudron et Coolify ont tous deux besoin d’un vrai domaine avec un DNS fonctionnel. Cloudron préfère disposer d’un accès API à votre fournisseur DNS afin de créer lui-même les enregistrements et les certificats wildcard. CasaOS fonctionne avec une adresse IP seule, mais vous n’aurez alors aucun TLS.
• Ports. Les trois solutions nécessitent l’ouverture des ports 80 et 443 pour HTTP et HTTPS. Coolify expose également son dashboard sur le port 8000 et utilise les ports 6001 pour son canal realtime et 6002 pour le terminal dans le navigateur. Laissez le port 22 ouvert pour SSH sur chacune des solutions.

Configurez le DNS vers le serveur avant de commencer. Un panel qui ne peut pas résoudre son propre hostname ne peut pas demander de certificat. Vous passerez alors la première heure à diagnostiquer ce problème au lieu de configurer le logiciel. Pointez un enregistrement A vers l’adresse IP du serveur. Pour Coolify, ajoutez également un enregistrement wildcard (*.apps.example.com) afin que chaque application déployée dispose de son propre sous-domaine.

Cloudron : l’appliance prête à l’emploi et opinionated

Ce que c’est. Cloudron est une plateforme commerciale qui transforme un serveur complet en appliance administrée. Elle exécute son propre reverse proxy, sa base de données et sa stack mail, ainsi qu’un App Store sélectionné proposant des applications packagées (Nextcloud, WordPress, Gitea, Mattermost, etc.). Elle s’adresse aux personnes qui veulent que leurs applications soient administrées, avec des mises à jour automatiques, des certificats automatiques et des sauvegardes automatiques, et qui sont prêtes à payer pour cela.

Installation. Cloudron exige un serveur vierge et en prend entièrement le contrôle. Exécutez ceci sur un serveur Ubuntu 24.04 (Noble) neuf, sans 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 stack mail, puis redémarre le serveur. À son retour, ouvrez https://<your-ip>, acceptez le certificat autosigné temporaire, puis terminez la configuration dans le navigateur : indiquez votre domaine, choisissez votre fournisseur DNS et Cloudron provisionne son propre dashboard à l’adresse my.example.com.

Ajout d’une première application. Dans le dashboard, ouvrez l’App Store, cliquez par exemple sur Nextcloud, choisissez le sous-domaine files.example.com, puis cliquez sur Install. Cloudron crée l’enregistrement DNS, demande le certificat Let's Encrypt, provisionne la base de données, configure le single sign-on et planifie une sauvegarde, sans que vous ayez à modifier un fichier de configuration. C’est toute la proposition de valeur, et elle tient ses promesses.

TLS et sauvegardes. C’est le plus solide des trois. Chaque sous-domaine d’application reçoit automatiquement un certificat Let's Encrypt, renouvelé pour vous. Les sauvegardes sont intégrées et planifiées. Elles ciblent un répertoire local, S3 ou un autre stockage distant. Vous pouvez restaurer chaque application séparément et même la cloner en un clic vers un nouveau sous-domaine.

Coût et licence : lisez ceci avant de vous engager. Cloudron est un produit payant avec une offre gratuite limitée : l’offre gratuite autorise deux applications. Si vous installez une troisième application, vous atteignez un paywall ; un abonnement payant (Pro ou Max, facturé au mois ou à l’année, les deux avec un nombre illimité d’applications) débloque davantage de fonctionnalités. C’est le fait le plus important à connaître sur Cloudron. La plateforme est aussi aboutie précisément parce qu’il s’agit d’une activité commerciale, et l’offre gratuite ressemble davantage à une période d’essai prolongée qu’à une solution destinée à héberger une stack qui s’agrandit.

Mode d’échec, règle du serveur vierge. Si vous essayez d’installer Cloudron sur un serveur qui exécute déjà quelque chose, l’installation s’arrête avant toute modification :

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 une exigence arbitraire. Cloudron impose des versions précises de nginx, Docker et Node et les intègre profondément. Il ne peut donc pas coexister avec vos propres installations. La solution consiste à utiliser une image Ubuntu 24.04 neuve, et rien d’autre : pas de serveur web, pas de Docker, pas même un pare-feu que vous auriez configuré manuellement. Si vous avez démarré la mauvaise image, l’installation refuse également tout système qui n’est pas un Ubuntu LTS pris en charge (22.04 ou 24.04) sur x86-64 ; ARM, LXC et OpenVZ ne sont pas pris en charge.

Deuxième mode d’échec, les certificats wildcard nécessitent l’API DNS. Si vous choisissez l’option DNS « Manual » pendant la configuration au lieu de fournir un jeton d’API à Cloudron, celui-ci ne peut pas créer les enregistrements ni demander un certificat wildcard pour vous. Pour chaque nouvelle application, vous devez alors ajouter manuellement un enregistrement DNS avant l’émission du certificat, et le dashboard reste en attente de cet enregistrement. Donnez à Cloudron un accès API à un fournisseur DNS pris en charge (Cloudflare, Route 53, DigitalOcean et d’autres) et toute la procédure se fait en un clic.

CasaOS : le tableau de bord gratuit pour home lab

Présentation. CasaOS, développé par IceWhale, est un tableau de bord libre et open source qui s’appuie sur Docker et fournit une page d’accueil, un app store et un gestionnaire de fichiers. Le projet vient du monde des serveurs domestiques et privilégie donc les usages de home lab : installation rapide, interface conviviale et configuration légère. Il s’adresse aux utilisateurs qui veulent une interface plus agréable pour Docker sans payer de service.

Installation. Une seule ligne suffit, et l’installation n’exige pas un système vierge :

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

L’installateur ajoute plusieurs services systemd (casaos, casaos-gateway, casaos-app-management, entre autres). Vérifiez que la gateway est bien démarrée avant d’ouvrir un navigateur :

systemctl status casaos-gateway

Une fois le service démarré, le tableau de bord est accessible à l’adresse http://<your-ip> (HTTP non chiffré, port 80). Créez un compte local pour commencer.

Ajouter une première application. Ouvrez l’App Store, choisissez une application, puis cliquez sur Install. En arrière-plan, CasaOS crée un projet Docker Compose et expose l’application sur un port de l’hôte, par exemple http://<your-ip>:8080. Son store propose les applications habituelles des serveurs domestiques. Vous pouvez donc installer en quelques clics un serveur multimédia Jellyfin sur un VPS ou une photothèque Immich auto-hébergée. Si vous n’avez pas encore choisi de serveur photo, l’article mémoire RAM minimale et applications mobiles qui distinguent PhotoPrism d’Immich mérite une lecture préalable. Sur une machine CasaOS dotée de 1GB de RAM, ce choix détermine si l’application peut fonctionner. Vous pouvez également importer n’importe quel docker-compose.yaml, ce qui constitue son principal avantage : les applications sont des conteneurs classiques, et non un format propriétaire.

TLS et sauvegardes : le point faible. C’est ici que les limites du gratuit apparaissent. Par défaut, CasaOS sert tout en HTTP non chiffré, y compris son propre tableau de bord. Il n’intègre ni prise en charge de Let’s Encrypt ni sauvegarde planifiée. Vos données résident dans des volumes Docker sous /DATA, et leur sauvegarde vous incombe (un restic ou tar lancé par cron).

Mode de défaillance : absence de TLS, sans avertissement côté service. Rien ne signale d’erreur. Vous installez une application, ouvrez http://<your-ip>:8080, et elle fonctionne sur une connexion non chiffrée que le navigateur marque « Not Secure ». Les mots de passe et les cookies de session transitent en clair sur le réseau. Plus grave, le tableau de bord CasaOS a déjà présenté de véritables vulnérabilités d’exécution de code à distance (CVE-2023-37265 et CVE-2023-37266, un contournement de l’authentification permettant ensuite la compromission complète de l’hôte). Exposer directement ce port HTTP sur Internet constitue donc un risque réel, et non une simple question de présentation. La solution consiste à ne jamais exposer CasaOS directement. Placez devant lui un reverse proxy qui termine TLS, par exemple nginx avec un certificat Let’s Encrypt obtenu avec Certbot, Caddy ou un Cloudflare Tunnel, puis transférez les requêtes vers CasaOS uniquement sur le réseau local. CasaOS utilise déjà le port 80. Votre proxy et CasaOS entreront donc en conflit sur ce port, sauf si vous déplacez d’abord CasaOS vers un autre port.

Coût. Le logiciel est réellement gratuit, sans limite du nombre d’applications. En contrepartie, vous devez gérer vous-même TLS, les sauvegardes et le durcissement.

Coolify : le PaaS auto-hébergé

Présentation. Coolify est une plateforme-as-a-service open source et auto-hébergée, comparable à Heroku ou Vercel, mais installée sur votre propre serveur. Son unité de base n’est pas « installer cette application packagée », mais « déployer ce dépôt Git » : connectez un dépôt, et Coolify le construit via Nixpacks ou votre propre Dockerfile, puis le déploie à chaque push. La plateforme propose également des bases de données et des services installables en un clic. Elle s’adresse aux développeurs qui déploient leur propre code et veulent un déploiement déclenché par un push sans louer un PaaS.

Installation.

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

Le script installe Docker et démarre la stack de conteneurs utilisée par Coolify. Vérifiez qu’ils sont sains avant de continuer :

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

Vous devez voir coolify, coolify-db, coolify-redis, coolify-realtime et coolify-proxy, tous avec l’état Up. Le dashboard est accessible à l’adresse http://<your-ip>:8000. Créez immédiatement votre compte administrateur, car la page d’inscription reste ouverte jusqu’à la création du premier compte. La première personne qui y accède contrôle le serveur. Définissez ensuite le domaine de votre instance et faites pointer un enregistrement DNS wildcard (*.example.com ou *.apps.example.com) vers le serveur afin que Coolify puisse attribuer son propre sous-domaine à chaque application déployée.

Ajout d’une première application. Connectez une source Git (GitHub, GitLab ou l’URL d’un dépôt classique), sélectionnez une branche, définissez le domaine, puis déployez. Le proxy Traefik intégré à Coolify achemine le sous-domaine et demande le certificat. Pour les logiciels prêts à l’emploi, le catalogue Services permet de déployer des composants en quelques clics : la même stack n8n d’automatisation des workflows que vous pourriez sinon configurer manuellement est disponible dans le catalogue, tout comme Uptime Kuma pour la supervision d’une page d’état.

TLS et sauvegardes. Coolify utilise automatiquement Let’s Encrypt pour chaque application via Traefik. Chaque sous-domaine déployé reçoit donc un certificat. Les sauvegardes sont d’abord axées sur les bases de données : vous pouvez planifier des dumps Postgres et MySQL vers un stockage compatible S3. La sauvegarde de l’instance complète, c’est-à-dire de la configuration de Coolify stockée sous /data/coolify, est plus manuelle. Exportez-la et stockez-la donc vous-même.

Coût et licence. L’édition auto-hébergée est entièrement open source et gratuite, sans limite sur le nombre d’applications. Il existe aussi une offre Coolify Cloud payante, qui héberge le control plane à votre place tandis que vos applications continuent de fonctionner sur vos propres serveurs. Cette offre est pratique, mais elle n’est pas obligatoire.

Problème courant : l’application est déployée, mais son domaine ne répond pas. Le dashboard fonctionne correctement sur http://<ip>:8000, le build aboutit, mais l’URL de l’application renvoie une erreur de connexion ou une erreur Traefik 404 page not found. Le problème vient alors du proxy ou du DNS, pas de l’application. Deux causes sont fréquentes. Premièrement, les ports 80 ou 443 étaient déjà utilisés lorsque le proxy a essayé de démarrer. Son conteneur s’est donc arrêté 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

Deuxièmement, l’enregistrement DNS wildcard est absent. Traefik ne reçoit alors jamais de requête pour ce hostname. Si la fiche du serveur entier dans Coolify affiche plutôt « Server is not reachable », le problème est différent : Coolify ne peut pas communiquer avec le socket Docker du serveur. Il s’agit généralement d’un daemon Docker arrêté ou d’une clé SSH invalide. Consultez les journaux pour connaître la cause réelle avant d’émettre une hypothèse :

docker logs coolify-proxy --tail 100

Corrigez le problème depuis la page Proxy : cliquez sur Restart Proxy, ou réinitialisez la configuration du proxy à ses valeurs par défaut et redémarrez-le. Attendez ensuite environ deux minutes qu’il se stabilise. Limitez l’accès au port 8000 à votre propre adresse IP, ou rouvrez-le temporairement lorsque le proxy rencontre un problème, plutôt que de le laisser accessible depuis Internet. Ce port sert le dashboard en HTTP simple. La documentation de Coolify indique également que les ports 8000, 6001 et 6002 peuvent être fermés une fois le dashboard servi via son propre domaine.

Surcharge de ressources sur le même VPS

Mesurée au repos sur le même serveur de 4GB, avant le déploiement de toute charge réelle. Vérifiez la vôtre avec free -m et docker stats --no-stream au lieu de vous fier à une seule valeur, car le total varie selon les applications utilisées.

• CasaOS est le plus léger. Le panneau repose sur un petit ensemble de services Go ; prévoyez environ 150 à 300 MB de surcharge, en plus des conteneurs que vous exécutez.
• Coolify exécute plusieurs conteneurs de support (l’application, un Postgres, un Redis, un service realtime et Traefik). Il utilise donc environ 600 MB à 1 GB au repos, avant tout déploiement.
• Cloudron est le plus lourd au repos, car il exécute son propre nginx, sa base de données, sa stack mail et sa supervision, que vous les utilisiez ou non. Prévoyez 1 à 1.5 GB au repos. C’est pourquoi il demande 2GB au minimum et fonctionne plus confortablement avec 4GB.

Sur un petit VPS de 2GB, CasaOS laisse le plus de ressources disponibles pour les applications réelles, tandis que Cloudron en laisse le moins. Si votre offre dispose de 2GB et que vous voulez utiliser Cloudron avec son mail server actif, prévoyez de faire évoluer le serveur.

Comparaison des mises à jour, des sauvegardes et de la dépendance à la plateforme

Mises à jour. Cloudron met à jour la plateforme et chaque application selon un calendrier qu’il a testé : c’est la solution qui demande le moins d’efforts et qui vous guide le plus. Coolify se met à jour depuis son propre tableau de bord en un clic. CasaOS met à jour le panneau via son script d’installation ou apt, mais vous devez récupérer et redémarrer vous-même les applications installées.

La dépendance à la plateforme, le problème qui apparaît la deuxième année. CasaOS est la solution la moins dépendante d’une plateforme : ses applications sont des projets Compose ordinaires. Vous pouvez donc copier le docker-compose.yaml et les volumes sous /DATA vers un autre hôte et continuer à les utiliser. Coolify se situe entre les deux : vos déploiements utilisent vos propres Dockerfiles et dépôts, mais leur configuration est stockée dans la base de données de Coolify. Pour changer d’hôte, vous devez donc recréer les projets sur le nouvel hôte. Cloudron est la solution la plus dépendante de sa plateforme : ses applications sont empaquetées pour Cloudron. Même si ses excellentes sauvegardes permettent d’exporter vos données proprement, ce n’est pas le cas de l’empaquetage. Vous devez donc redéployer les applications sur la plateforme cible. Les données sont portables, mais pas les composants d’infrastructure.

Lequel choisir

En bref, puis l’alternative. Choisissez Cloudron si vous voulez le serveur qui demande le moins d’intervention parmi les trois, si vous comptez exécuter plusieurs applications packagées et si vous acceptez de payer un abonnement annuel pour la gestion de TLS, les sauvegardes et les mises à jour. Choisissez CasaOS s’il s’agit d’un home lab derrière votre propre réseau ou un reverse proxy, si vous voulez une interface conviviale pour Docker et si vous refusez de payer quoi que ce soit. Choisissez Coolify si vous déployez votre propre code depuis Git et si vous voulez un déploiement après chaque push avec TLS automatique, sans le coût d’un PaaS hébergé. Si aucune de ces trois options ne vous correspond, la section suivante donne la réponse honnête.

Ignorer les trois si...

Soyez honnête sur votre échelle. Si vous n’exécutez qu’une ou deux applications, ou si vous voulez comprendre et contrôler exactement ce qui se trouve sur votre serveur, ignorez les panels. Leur surcharge et le verrouillage propriétaire ne se justifient pas pour une stack réduite et stable. L’approche DIY consiste à placer un reverse proxy devant vos propres fichiers Compose : Traefik avec TLS automatique devant plusieurs applications Docker Compose vous fournit l’équivalent d’un HTTPS en un clic, sans la lourdeur d’un panel, et vous effectuez les sauvegardes avec une tâche cron qui exécute restic et que vous comprenez réellement.

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 principale, l’argument est encore plus évident : une installation de Nextcloud sur Docker avec TLS et sa propre routine de sauvegarde tient dans un fichier Compose et un certificat. Déployer toute une appliance pour l’exécuter n’apporterait aucun bénéfice et ne ferait qu’ajouter des coûts. Si vous déterminez encore quoi exécuter avant de décider comment, le guide de ce qui mérite d’être auto-hébergé en 2026 constitue un meilleur point de départ.

FAQ

Ai-je vraiment besoin d’un panel d’auto-hébergement ?

Seulement si vous accordez de l’importance aux quatre tâches qu’un panel automatise pour 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 assure la même gestion du TLS, avec beaucoup moins de surcharge et sans verrouillage propriétaire. Les panels deviennent intéressants lorsque vous exécutez de nombreuses applications et que votre temps vaut plus que la RAM qu’ils consomment.

Quel panel convient le mieux à un débutant ?

Pour un home lab dont rien n’est exposé sur Internet hostile, CasaOS constitue le point de départ le plus simple : une commande et une interface conviviale, sans abonnement à payer. Vous devez toutefois placer un reverse proxy avec terminaison TLS devant lui avant d’exposer quoi que ce soit, car il fournit du HTTP en clair. Si vous voulez que le TLS et les sauvegardes soient gérés pour vous et que vous acceptez de payer, Cloudron offre l’accompagnement le plus complet, dans la limite de deux applications gratuites.

Cloudron est-il gratuit ?

En partie. L’offre gratuite autorise deux applications, ce qui suffit pour l’essayer ou pour une très petite installation. Au-delà, Cloudron fonctionne avec un abonnement payant, facturé au mois ou à l’année, avec un nombre illimité d’applications dans les offres payantes. Il s’agit d’un produit commercial avec une offre gratuite limitée, et non d’un logiciel libre. Prévoyez donc son coût si votre stack doit s’agrandir.

Puis-je exécuter ces panels à côté de mes applications existantes ?

Cloudron : non. Il nécessite une machine Ubuntu vierge et s’arrête si nginx, Docker ou Node sont déjà installés, car il gère l’ensemble de la machine. CasaOS et Coolify sont plus faciles à intégrer, puisqu’ils installent leur propre stack Docker et peuvent en principe partager une machine. Toutefois, tous deux utilisent les ports 80 et 443, ce qui crée un conflit avec tout serveur web ou proxy déjà en fonctionnement. Sur une machine qui héberge déjà des services, un panel est généralement le mauvais outil. Utilisez plutôt Traefik et Compose.

Comment abandonner un panel plus tard ?

Planifiez votre migration avant d’en avoir besoin. Avec CasaOS, copiez le docker-compose.yaml de l’application et ses volumes /DATA vers le nouvel hôte, puis redémarrez-les. Avec Coolify, exportez la configuration de chaque projet et pointez-le vers les mêmes dépôts sur la destination. Avec Cloudron, restaurez les données de ses sauvegardes dans des applications fraîchement installées sur la nouvelle plateforme, car le packaging Cloudron n’est pas transférable : seules les données le sont. Dans tous les cas, testez la restauration sur une machine temporaire avant de supprimer l’ancienne.