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 véritable kernel, et Cloudron refuse catégoriquement OpenVZ et LXC. Vérifiez avec systemd-detect-virt : kvm ou qemu convient, mais openvz ou lxc ne convient pas. Sur une offre KVM, la commande affiche kvm, et sur un serveur bare metal elle affiche none ; dans les deux cas, vous pouvez continuer.

Pour le reste, les besoins 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, dont environ 600 MB sont utilisés par Coolify lui-même. Cloudron nécessite au minimum 2GB et 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 seule application.
• Un domaine et un DNS que vous contrôlez. Cloudron et Coolify nécessitent tous deux un véritable 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. Cloudron et Coolify nécessitent l’ouverture des ports 80 et 443 pour HTTP et HTTPS. CasaOS fournit son tableau de bord en HTTP simple et n’a donc besoin que du port 80. Coolify fournit en plus son tableau de bord sur le port 8000, utilise le port 6001 pour son canal temps réel et le port 6002 pour le terminal dans le navigateur. Laissez le port 22 ouvert pour SSH sur les trois solutions.

Faites pointer le DNS vers le serveur 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 à diagnostiquer ce problème au lieu de configurer le logiciel. Faites pointer un enregistrement A vers l’adresse IP du serveur et, pour Coolify, ajoutez un enregistrement wildcard (*.apps.example.com) afin que chaque application déployée reçoive son propre sous-domaine.

Cloudron : l’appliance clé en main et prescriptive

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 de messagerie, ainsi qu’un App Store organisé 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 acceptent de payer pour cela.

Installation. Elle 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 de messagerie, puis redémarre le serveur. À son retour, ouvrez https://<your-ip>, acceptez le certificat autosigné temporaire et terminez la configuration dans le navigateur : indiquez votre domaine, choisissez votre fournisseur DNS, puis Cloudron provisionne 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, 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 vous obliger à modifier un fichier de configuration. C’est toute sa proposition de valeur, et elle tient ses promesses.

TLS et sauvegardes. C’est la solution la plus complète 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 vers un répertoire local, S3 ou un autre stockage distant. Vous pouvez restaurer chaque application séparément et même cloner une application vers un nouveau sous-domaine en un clic.

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. Installez une troisième application et vous atteignez le paywall ; un abonnement payant (Pro ou Max, facturé au mois ou à l’année, tous deux avec un nombre illimité d’applications) débloque davantage de fonctionnalités. C’est le fait le plus important à retenir concernant Cloudron. La plateforme est soignée 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 adaptée à une stack qui s’agrandit.

Mode d’échec : la règle du serveur vierge. Si vous essayez d’installer Cloudron sur un serveur qui exécute déjà quelque chose, la configuration s’interrompt 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 its 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 étroitement. 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, ni même de pare-feu que vous auriez configuré manuellement. Si vous avez démarré avec la mauvaise image, la configuration refuse également tout système autre qu’un Ubuntu LTS pris en charge (22.04, 24.04 ou 26.04) sur x86-64 ; ARM, LXC et OpenVZ ne sont pas pris en charge. Depuis Cloudron 10 (septembre 2026), Ubuntu 26.04 est la version par défaut des nouvelles installations. C’est donc l’image à choisir si vous commencez aujourd’hui.

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 tableau de bord reste en attente de cet enregistrement. Donnez à Cloudron un accès API à un fournisseur DNS pris en charge (Cloudflare, Route 53, DigitalOcean, entre autres) et toute la procédure se réduit à 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é

Ce que c’est. Coolify est une plate-forme en tant que 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 empaquetée », mais « déployer ce dépôt Git » : connectez un dépôt et Coolify le compile, avec Nixpacks ou votre propre Dockerfile, puis le déploie à chaque push. La plate-forme 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 propre pile de conteneurs de Coolify. Vérifiez qu’ils sont opérationnels avant de continuer :

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

Vous devez voir coolify, coolify-db, coolify-redis, coolify-realtime et coolify-proxy indiquer tous Up. Le tableau de bord 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, et 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 un sous-domaine à chaque application déployée.

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

TLS et sauvegardes. Les certificats Let’s Encrypt sont gérés automatiquement pour chaque application par Traefik, qui est intégré à la plate-forme. Chaque sous-domaine déployé reçoit donc un certificat. Les sauvegardes privilégient 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 Coolify stockée 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 limite sur le nombre d’applications. Il existe également 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 facultative.

Incident : l’application est déployée, mais son domaine ne répond pas. Le tableau de bord fonctionne correctement sur http://<ip>:8000, le build réussit, mais l’URL de l’application renvoie une erreur de connexion ou une erreur 404 page not found de Traefik. Le problème vient probablement du proxy ou du DNS, et non de l’application. Deux causes sont fréquentes. Premièrement, les ports 80 ou 443 étaient déjà utilisés lorsque le proxy a tenté 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, le nom d’hôte ne résout pas vers le serveur. Soit l’application utilise un sous-domaine généré par wildcard, mais l’enregistrement DNS wildcard est absent, soit elle utilise un domaine personnalisé qui ne possède pas son propre enregistrement DNS pointant vers le serveur. Traefik ne reçoit alors jamais de requête pour ce nom d’hôte. Si toute la carte du serveur dans Coolify affiche « Server is not reachable », il s’agit d’un autre problème : Coolify ne peut pas communiquer avec le socket Docker du serveur, généralement parce que le daemon Docker est arrêté ou qu’une clé SSH est défectueuse. Consultez les journaux pour connaître la cause réelle avant de poser un diagnostic :

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 si le proxy fonctionne mal, plutôt que de le laisser ouvert à Internet. Ce port sert le tableau de bord en HTTP non chiffré, et la documentation de Coolify indique que les ports 8000, 6001 et 6002 peuvent être fermés une fois que le tableau de bord est accessible 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 avez besoin des quatre fonctions qu’un panel automatise pour plusieurs applications : les installations en un clic, le TLS automatique, les sauvegardes planifiées et la 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 les ressources RAM qu’ils consomment.

Quel panel convient le mieux à un débutant ?

Pour un lab à domicile qui n’est pas exposé à Internet, CasaOS est le plus simple pour commencer : une commande et une interface conviviale, sans abonnement. Vous devez toutefois placer un reverse proxy avec terminaison TLS devant lui avant d’exposer quoi que ce soit, car il utilise du HTTP en clair. Si vous voulez que le TLS et les sauvegardes soient gérés automatiquement et que vous êtes prêt à payer, Cloudron offre l’accompagnement le plus complet, dans la limite de deux applications avec l’offre gratuite.

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 est 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, pas d’un logiciel libre. Prévoyez donc son coût si votre stack doit évoluer.

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

Cloudron : non. Il requiert une installation 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 souples, car ils installent leur propre stack Docker et peuvent en principe partager un serveur. CasaOS veut toutefois utiliser le port 80 pour son dashboard, tandis que le proxy de Coolify veut utiliser les ports 80 et 443. Chacun entre donc en conflit avec un serveur web ou un proxy qui utilise déjà ces ports. Sur un serveur 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 la 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 faites-la pointer vers les mêmes dépôts sur la destination. Avec Cloudron, restaurez les données depuis ses sauvegardes dans des applications fraîchement installées sur la nouvelle plateforme, car le packaging Cloudron ne se migre pas : seules les données sont transférables. Dans tous les cas, testez la restauration sur un serveur temporaire avant de supprimer l’ancien.