Installer Cloudron sur un VPS Ubuntu

Installer Cloudron sur un VPS : la version courte

Pour installer Cloudron sur un VPS, vous avez besoin d’un serveur Ubuntu vierge, d’au moins 2 GB de RAM et d’un domaine dont vous pouvez modifier les enregistrements DNS. L’installation elle-même se résume à trois commandes et à un redémarrage. Presque tous les problèmes surviennent avant cette étape (mauvaise image de base, mauvais type de virtualisation) ou après (DNS, messagerie, sauvegardes).

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

Cloudron installe, met à jour et sauvegarde les applications auto-hébergées. Il délivre également leurs certificats TLS (transport layer security). Chaque application s’exécute dans Docker, nginx est placé devant l’ensemble des applications et chaque application reçoit son propre sous-domaine de votre domaine. C’est pour cette dernière raison que la configuration DNS doit être effectuée en premier.

Pourquoi Cloudron est strict concernant le système d’exploitation de base

Le script d’installation vérifie le serveur avant d’installer quoi que ce soit. Si une vérification échoue, vous devez commander un nouveau serveur. Lisez ces exigences avant de choisir une image.

• Ubuntu uniquement, et seulement trois releases. Dans tous les autres cas, le script s’arrête avec Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky et Alpine ne sont pas pris en charge. Ubuntu 24.04 nécessite Cloudron 8 ou une version ultérieure, et le script le vérifie pour vous.
• Processeur Intel ou AMD 64 bits uniquement : Error: Cloudron only supports amd64/x86_64. Un VPS ARM ne peut pas l’exécuter.
• Virtualisation matérielle complète uniquement. Sur un VPS basé sur des conteneurs, le script s’arrête avec Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization, car il détecte le conteneur avec systemd-detect-virt --container. KVM convient. OpenVZ et LXC ne conviennent pas.
• Le système de fichiers racine doit être ext4 ou xfs. Dans tous les autres cas, vous obtenez Error: Cloudron requires '/' to be ext4 or xfs. C’est ainsi que les images btrfs et zfs échouent.
• Au moins 941 MB de RAM et 20 GB sur /, mesurés avec free -m et la taille du système de fichiers racine.
• Un serveur réellement vierge. Si nginx, docker ou node est déjà installé, le script refuse de continuer avec Error: Some packages like nginx/docker/nodejs are already installed..

Cette dernière vérification est souvent contestée. Voici pourquoi elle existe. Cloudron installe des versions figées de Docker, nginx, Node.js et MySQL, écrit la configuration nginx de chaque application hébergée et gère lui-même les règles du pare-feu iptables. Un Docker que vous avez installé hier n’est pas la bonne version, et vos fichiers de site nginx existants sont remplacés. Cloudron gère l’ensemble de la machine. Utilisez donc un VPS dédié.

Une autre vérification est facile à manquer. Sur un processeur ancien sans AVX (advanced vector extensions), le script affiche CPU has no AVX support. MongoDB will be disabled, et toutes les applications qui nécessitent MongoDB deviennent impossibles à installer. Vérifiez le processeur avant de vous engager avec grep -m1 -o avx /proc/cpuinfo. Cette commande affiche avx sur un hôte compatible et rien sur un ancien hôte.

De quelle quantité de RAM Cloudron a-t-il besoin ?

Le script refuse de s’exécuter avec moins de 941 MB, avec Error: Cloudron requires atleast 1GB physical memory, et la documentation demande 2 GB de RAM et 20 GB de disque. Ces deux valeurs constituent le minimum pour la plateforme seule, pas pour la plateforme et vos applications. Avant même d’installer une application, Cloudron exécute déjà Docker, nginx, son propre service box, les conteneurs de bases de données qu’il met à la disposition des applications (MySQL, PostgreSQL, MongoDB), Redis et la pile de messagerie. Exécutez docker ps sur une installation neuve et comptez-les.

Les limites de mémoire des applications s’ajoutent à cette base. Chaque package d’application est livré avec une limite par défaut faible, que vous pouvez augmenter avec le curseur de la vue Resources de l’application. Lorsqu’une application dépasse sa limite, elle redémarre et vous envoie une notification OOM (out of memory). Un serveur qui redémarre constamment une application présente donc généralement un problème de limite plutôt qu’un bug.

Voici le dimensionnement que je recommande. Il s’agit de recommandations pour un serveur que vous n’aurez pas à reconstruire le mois prochain. Ce ne sont pas des résultats de benchmark mesurés.

[
  {
    "label": "2 apps (free tier)",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 60
  },
  {
    "label": "5 apps",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 120
  },
  {
    "label": "10 apps",
    "vcpu": 6,
    "ram_gb": 16,
    "disk_gb": 240
  }
]

Deux applications fonctionnent confortablement avec 4 GB de RAM et 60 GB de disque. Une dizaine d’applications nécessitent environ 16 GB de RAM et 240 GB de disque, car la base de la plateforme ne diminue jamais et chaque application ajoute une image Docker, une base de données et ses propres données. Le disque se remplit plus vite qu’on ne le pense : les images, les données des applications et les sauvegardes locales partagent un même volume tant que vous ne déplacez pas les sauvegardes hors du serveur.

Cloudron fournit à chaque application un swap illimité. La limite de mémoire que vous définissez s’applique donc uniquement à la RAM. Sur une image VPS sans fichier swap, swapon --show n’affiche absolument rien, et la pression mémoire provoque directement des redémarrages OOM au lieu de ralentir l’application. Ajouter 2 GB de swap constitue une précaution peu coûteuse, mais cela ne remplace pas la mémoire réelle. L’écart entre les offres VPS est faible comparé aux heures que vous passerez à ajuster les limites. Consultez donc ce que coûte réellement un VPS et choisissez l’offre de capacité supérieure.

DNS : l’enregistrement wildcard qui permet aux sous-domaines des applications de fonctionner

Cloudron place le tableau de bord sur my.example.com et chaque application sur son propre sous-domaine. Le DNS est donc un prérequis, pas une étape ultérieure. Faites pointer ces enregistrements vers l’adresse IP publique du serveur avant d’ouvrir le tableau de bord pour la première fois :

• my.example.com comme enregistrement A. Il s’agit du tableau de bord.
• *.example.com comme enregistrement A. C’est lui qui permet aux sous-domaines des applications de fonctionner. Ainsi, wiki.example.com et git.example.com seront résolus dès que vous installerez ces applications.
• example.com comme enregistrement A, uniquement si vous voulez héberger une application sur le domaine nu.

Un enregistrement wildcard a une priorité inférieure à celle d’un enregistrement explicite. Un enregistrement www.example.com existant qui pointe ailleurs continue donc de fonctionner.

Pendant l’installation, vous choisissez la manière dont Cloudron gérera le DNS :

• Un fournisseur avec API. Cloudron stocke un token pour Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap et une vingtaine d’autres fournisseurs, puis crée lui-même tous les enregistrements, y compris ceux du mail.
• Wildcard. Vous ajoutez manuellement l’enregistrement * et Cloudron ne crée aucun enregistrement.
• Manuel. Cloudron vous affiche chaque enregistrement et attend que vous l’ajoutiez avant chaque installation d’application.

Un enregistrement DNS wildcard n’est pas un certificat wildcard. Le fournisseur de certificats par défaut est Let's Encrypt Prod - Wildcard. Il valide la propriété du domaine via le DNS et ne fonctionne donc qu’avec un fournisseur doté d’une API. Avec les backends Wildcard ou Manuel, vous utilisez à la place un certificat par application, validé via HTTP. Le port entrant 80 doit alors rester ouvert en permanence. Si votre registrar ou votre hébergeur DNS figure dans la liste des fournisseurs avec API, utilisez-le : les enregistrements de mail et les certificats ne seront plus à votre charge.

Vérifiez ces éléments avant de continuer. dig +short my.example.com et dig +short anything.example.com doivent tous deux afficher l’adresse IP de votre serveur. Si la requête wildcard n’affiche rien, les applications échoueront plus tard alors que le tableau de bord fonctionnera correctement.

Si le domaine est placé derrière Cloudflare, configurez les enregistrements en mode DNS uniquement. Le proxy ne relaie que HTTP et HTTPS. Les ports du mail ne fonctionneront donc pas, et chaque application verra une adresse Cloudflare au lieu de celle du visiteur.

Exécutez le script d’installation

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

Exécutez-le en tant que root ou avec sudo, car il affiche sinon This script should be run as root. dès le début. L’installation prend plusieurs minutes et reste silencieuse pendant son exécution, car la sortie d’apt et les téléchargements Docker sont écrits dans un fichier journal. Suivez ce fichier depuis une seconde session SSH :

tail -f /var/log/cloudron-setup.log

À la fin, le script affiche After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. suivi de l’adresse de votre serveur, puis demande The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. Répondez yes. L’option --skip-reboot permet de planifier le redémarrage si nécessaire, mais Cloudron ne sera pas utilisable avant le redémarrage complet du serveur.

Premier démarrage : domaine, backend DNS et compte d’administration

Ouvrez https://<server-ip> et acceptez l’avertissement du navigateur. Le certificat est auto-signé, car Cloudron ne connaît pas encore votre domaine et ne peut donc pas demander de certificat à une autorité de certification. Dans Chrome, cliquez sur Advanced, puis sur Proceed to <ip> (unsafe). Dans Firefox, cliquez sur Advanced, puis sur Accept the Risk and Continue.

Le premier écran vous demande votre domaine. Saisissez example.com ; le dashboard devient alors accessible à l’adresse my.example.com. Vous pouvez aussi utiliser un sous-domaine tel que cloudron.example.com ; le dashboard sera alors accessible à l’adresse my.cloudron.example.com. Sélectionnez le backend DNS, collez le jeton d’API si vous en avez un, puis créez le compte d’administration avec une adresse e-mail que vous consultez réellement : l’enregistrement auprès de Let’s Encrypt et toutes les alertes de la plateforme utilisent cette adresse.

Lorsque vous enregistrez la configuration, Cloudron demande les certificats et déplace le dashboard vers https://my.example.com. L’URL basée sur l’adresse IP cesse alors de fonctionner. Ajoutez la nouvelle URL à vos favoris.

Certificats : renouvellement et conditions d’arrêt

Le renouvellement des certificats est automatique et suit l’ACME Renewal Information (ARI), c’est-à-dire le calendrier publié par l’autorité de certification. En pratique, le renouvellement intervient environ un mois avant l’expiration. En cas d’échec, un e-mail est envoyé au compte administrateur. Une fois le certificat expiré, le système utilise le certificat auto-signé intégré. C’est ce mécanisme de repli qui explique l’avertissement affiché par le navigateur sur un site qui fonctionnait encore la veille.

Deux causes expliquent la plupart des problèmes. La validation HTTP nécessite que le port entrant 80 soit accessible. Fermer le port 80 parce que « tout est déjà en HTTPS » bloque donc le renouvellement de toutes les applications qui utilisent un backend Wildcard ou Manual DNS. La validation DNS nécessite un jeton API qui dispose toujours des droits d’écriture. La rotation de ce jeton ou la réduction de ses droits bloque le renouvellement sans message visible jusqu’à l’envoi de l’e-mail d’avertissement.

La vue Domains contient un bouton Renew All qui permet de lancer immédiatement une tentative. Elle propose également un provider Let's Encrypt Staging pour les tests. Les certificats Staging ne sont volontairement pas approuvés par les navigateurs. C’est précisément leur intérêt : vous pouvez effectuer autant de nouvelles tentatives que nécessaire sans consommer la rate limit de production.

Faut-il utiliser le serveur de messagerie intégré ?

Cloudron fournit une stack de messagerie complète avec des boîtes IMAP, la soumission SMTP, des filtres Sieve et la signature DKIM (DomainKeys Identified Mail). Vous l’activez pour chaque domaine dans la section Email du tableau de bord. La difficulté principale est de faire arriver les messages à destination, et Cloudron n’est responsable d’aucun de ces problèmes.

• Le port sortant 25 est bloqué par la plupart des fournisseurs de VPS pour limiter le spam. Certains le débloquent après l’ouverture d’un ticket auprès du support. Testez-le depuis le serveur avec nc -zv aspmx.l.google.com 25 (installez netcat-openbsd si la commande est absente). La commande succeeded indique l’état des ports ouverts. Un port bloqué reste en attente jusqu’à l’expiration du délai.
• L’enregistrement PTR (DNS inverse) est défini par votre fournisseur de VPS, et non par votre hébergeur DNS. Il doit correspondre au nom d’hôte de messagerie. Les messages envoyés depuis une adresse associée à un PTR générique arrivent dans les dossiers de spam.
• Les enregistrements SPF, DKIM et DMARC sont créés pour vous avec un backend DNS utilisant une API. Avec les backends Wildcard ou Manual, vous devez les ajouter manuellement. En l’absence d’enregistrement DKIM, aucun message signé ne peut être vérifié.

Pour la plupart des utilisateurs, la configuration la plus fiable consiste à recevoir les messages sur Cloudron et à les envoyer via un relay tel que SendGrid, Postmark, Mailgun ou Amazon SES, configuré dans la vue Email. Le relay doit autoriser l’envoi avec n’importe quelle adresse de votre domaine. Sinon, les notifications d’applications provenant de différents expéditeurs sont rejetées. Si la messagerie est la raison principale pour laquelle vous achetez ce serveur, utilisez un serveur de messagerie dédié tel que Mailcow sur une machine distincte, avec sa propre réputation IP.

Si vous n’utilisez pas du tout Cloudron Email, bloquez les ports 25, 465, 587, 993 et 4190 dans le pare-feu de votre fournisseur. Faites-le à cet endroit, et non sur le serveur, car Cloudron écrit lui-même les règles iptables et s’attend à les gérer. C’est l’inverse d’un VPS classique, où vous gérez vous-même les règles ufw.

Configurez la cible de sauvegarde avant d’en avoir besoin

Par défaut, les sauvegardes sont stockées sur le système de fichiers local, dans /var/backups, sur le même disque que le reste. La documentation est claire : « Stocker les sauvegardes sur le même disque physique que le serveur de la plateforme est dangereux. » Une panne de disque entraîne la perte des applications et des sauvegardes.

Ouvrez Backups, puis Backup Sites, et configurez dès le premier jour une autre cible. Un stockage d’objets compatible S3 est généralement le meilleur choix (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces ou un bucket MinIO sur un second serveur). SSHFS, NFS, CIFS et les cibles utilisant directement le système de fichiers sont également pris en charge.

Trois paramètres déterminent l’utilité de cette sauvegarde :

• Format. tgz crée une archive compressée par application et la téléverse à nouveau en entier à chaque exécution. rsync ne téléverse que les fichiers modifiés. Cette option coûte beaucoup moins cher pour un Nextcloud volumineux, mais génère beaucoup plus de requêtes vers l’API de stockage.
• Chiffrement. Chiffrement AES-256 facultatif couvrant le contenu des fichiers et leurs noms. Cloudron ne conserve pas de copie du mot de passe. Si vous le perdez, personne ne pourra déchiffrer les sauvegardes, vous compris. Stockez-le dans un gestionnaire de mots de passe auto-hébergé avant de cliquer sur Save.
• Rétention. Elle est définie par des quantités, par exemple 7 sauvegardes quotidiennes et 4 hebdomadaires. Une longue rétention sur un stockage d’objets augmente votre facture chaque mois. Choisissez donc un nombre que vous acceptez de continuer à payer.

Testez ensuite une restauration. Installez une petite application, restaurez-la depuis le dashboard et vérifiez qu’elle revient avec ses données. Une sauvegarde qui n’a jamais été restaurée est une simple hypothèse.

Limites de l’offre gratuite

En août 2026, l’offre gratuite est limitée à deux applications installées. Elle inclut tout le reste : les mises à jour des applications, les sauvegardes par application, le firewall, le serveur de messagerie et le single sign-on. La troisième application est le seuil à partir duquel une licence devient nécessaire. Les offres payantes suppriment la limite du nombre d’applications. L’offre la plus complète ajoute les groupes et les rôles d’utilisateurs, un serveur d’annuaire et plusieurs sites de sauvegarde. Les prix changent. Consultez donc la page des tarifs de Cloudron plutôt qu’un chiffre indiqué dans un tutoriel.

Une licence couvre une installation Cloudron. Deux petits serveurs coûtent donc deux fois plus cher qu’un seul serveur plus puissant. Cette tarification pousse la plupart des utilisateurs à choisir un VPS unique et plus puissant, contrairement aux recommandations habituelles qui consistent à répartir les services sur plusieurs machines. Dimensionnez le serveur en conséquence, car une séparation ultérieure impose de payer deux fois.

En cas de problème

Commencez par utiliser le contrôle intégré. Il vérifie successivement le DNS, les certificats, le disque, la mémoire et chaque service, puis indique quel test a échoué :

sudo cloudron-support --troubleshoot

Utilisez ensuite les outils systemd habituels (gestionnaire du système et des services). systemctl status box affiche l’état du service Cloudron lui-même, journalctl -u box -n 100 affiche ses journaux récents et journalctl -u docker concerne le runtime de conteneurs sous-jacent. Tout problème survenu pendant l’installation est enregistré dans /var/log/cloudron-setup.log.

Un dashboard qui ne se charge pas indique généralement un problème de DNS ou de pare-feu du fournisseur, plutôt qu’un problème Cloudron. Exécutez dig +short my.example.com depuis votre ordinateur portable et vérifiez que les ports 80 et 443 sont ouverts dans le pare-feu réseau du fournisseur. Ce pare-feu est distinct des règles du serveur lui-même. Si vous recommencez l’installation, le script refuse une seconde exécution avec Error: Cloudron is already installed. To reinstall, start afresh. La solution propre consiste à reconstruire le serveur.

Quand Cloudron n’est pas adapté

Cloudron convient lorsque vous voulez déployer des applications plutôt que gérer l’infrastructure. Il convient mal lorsque vous voulez exécuter vos propres conteneurs comme vous l’entendez, car il prend en charge nginx, Docker et le firewall, puis écrase les modifications que vous y apportez. Si votre projet consiste à gérer un répertoire de fichiers Compose, Traefik devant vos propres stacks Docker Compose fournit le même TLS automatique et le même routage par sous-domaine, sans plateforme par-dessus. Si vous n’avez pas encore choisi, Cloudron, CasaOS et Coolify comparés les présente côte à côte, et la liste plus large des services à auto-héberger constitue un meilleur point de départ qu’un guide d’installation.

FAQ

De quelle quantité de RAM Cloudron a-t-il besoin sur un VPS ?

Le script d’installation refuse de s’exécuter avec moins de 941 MB et la documentation demande 2 GB, mais il s’agit du minimum pour la plateforme sans aucune application. Dès le premier démarrage, Cloudron exécute Docker, nginx, son propre service box, des conteneurs de bases de données et la pile de messagerie. Prévoyez 4 GB pour deux applications et 16 GB pour une dizaine d’applications. Ajoutez un fichier swap, car Cloudron autorise une quantité illimitée de swap pour les applications et un serveur qui n’en dispose pas transforme la pression mémoire en redémarrages.

Puis-je installer Cloudron sur Debian ou sur un serveur qui exécute déjà Docker ?

Aucune de ces configurations ne fonctionne. Le script vérifie la release et s’arrête avec Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky et Alpine sont donc exclus. Il s’arrête également lorsque nginx, docker ou node est déjà présent, car il installe des versions figées de chacun de ces composants et configure lui-même nginx ainsi que les règles iptables. Utilisez une image Ubuntu neuve sur un VPS KVM.

Pourquoi les sous-domaines de mes applications échouent-ils alors que le dashboard fonctionne ?

L’enregistrement DNS wildcard est absent. L’installation crée ou exige un enregistrement A pour my.example.com. Le dashboard se résout donc correctement, tandis que wiki.example.com renvoie NXDOMAIN et que le navigateur indique que le site est introuvable. Ajoutez un enregistrement A pour *.example.com qui pointe vers l’adresse IP du serveur, puis vérifiez avec dig +short wiki.example.com avant d’installer l’application.

Dois-je utiliser le serveur de messagerie Cloudron ?

Non. Vous pouvez désactiver la réception des e-mails et envoyer les messages via un relay externe tel que Postmark, Mailgun ou Amazon SES. C’est le choix le plus sûr si votre fournisseur bloque le port sortant 25 ou si l’adresse IP ne dispose d’aucune réputation mail. Si vous désactivez entièrement Cloudron Email, fermez les ports 25, 465, 587, 993 et 4190 dans le firewall du fournisseur, et non sur le serveur.

Que se passe-t-il lorsque j’atteins la limite de deux applications du forfait gratuit ?

Le dashboard bloque la troisième installation et demande une licence. Les applications déjà installées ne sont pas modifiées : elles continuent de se mettre à jour, de faire l’objet de sauvegardes et de conserver leurs certificats. L’ajout d’une licence supprime la limite sans rien réinstaller. Le forfait gratuit permet donc de tester correctement la plateforme sur un vrai domaine.