Exigences d'Uptime Kuma : quelle taille de serveur, et où l'exécuter

Les exigences d'Uptime Kuma sont modestes, et l'endroit où il tourne compte plus que sa taille. Un moniteur qui tombe en même temps que vos sites ne peut pas vous signaler leur panne : commencez donc par l'emplacement, puis dimensionnez le serveur et configurez-le dans l'ordre.

Où l'exécuter

Sandstorm Media, une agence de développement logiciel, s'est heurtée à ce problème lors de son passage d'UptimeRobot à Uptime Kuma. Elle ne voulait pas que le moniteur soit à proximité de ses propres serveurs : elle a donc acheté un serveur cloud dans un autre pays.

Installez Uptime Kuma sur un serveur qui n'héberge aucun des sites, applications ou bases de données qu'il surveille. Si le serveur d'un site manque de mémoire, si un déploiement échoue ou si une base de données ne répond plus, le moniteur ne tombera pas avec eux, et vous recevrez quand même l'alerte.

L'un des mainteneurs d'Uptime Kuma place la barre plus haut : should not co-locate your uptime status page on the same infrastructure, datacenter or credit card. Si vos sites tournent déjà sur des serveurs VPS de DreamHost, un second serveur pour Uptime Kuma partagera leur centre de données, car le centre d'aide de DreamHost indique que chaque VPS est hébergé dans son centre de données US East à Ashburn, en Virginie. Il figurera aussi sur la même facture. Si vos sites sont hébergés chez une autre entreprise, il sera totalement en dehors de leur infrastructure. Dans les deux cas, vous ajouterez une vérification externe lors des étapes de configuration ci-dessous, et c'est elle qui vous préviendra si le centre de données ou Uptime Kuma lui-même cesse de répondre.

Quelle taille de serveur prévoir

Uptime Kuma ne publie pas de configuration minimale. Son README demande Node.js 20.4 ou plus récent pour les installations sans Docker, sans rien préciser de plus, et un utilisateur n'a trouvé aucun chiffre de RAM ni de CPU dans la documentation : nous l'avons donc mesuré. Les 21 et 22 octobre 2026, nous avons exécuté Uptime Kuma 2.5.6 dans Docker à partir du fichier compose.yaml du projet, avec sa base de données SQLite par défaut, sur notre machine de test dotée de 2 vCPU et de 4 Go (arm64), et non sur un serveur DreamHost. C'est la même configuration que Stack 4.

Sans aucun moniteur, il utilisait environ 200 Mio de mémoire. Nous avons ensuite ajouté 200 moniteurs de sites web avec les paramètres par défaut, soit une vérification toutes les 60 secondes sans nouvelle tentative, et les 200 ont été ajoutés sans erreur. Après 15 minutes de vérifications, le conteneur utilisait 237 Mio et 0,45 % du CPU, et 3 408 Mo sur les 3 904 Mo de la machine restaient libres. Nos vérifications interrogeaient une minuscule page de test sur la même machine : de vrais sites avec HTTPS et redirections demandent donc un peu plus. Le test n'a été effectué qu'une fois, pendant 15 minutes, et ne dit donc rien de plusieurs mois d'historique.

Un utilisateur de GitHub a mesuré environ 126 Mio pour 200 vérifications sur la version 1, sur un serveur de même taille, et un autre utilisateur du même fil faisait tourner environ 250 moniteurs sur une bêta de la version 2 avec moins de 400 Mio en moyenne.

C'est le disque qu'il faut surveiller : chaque vérification enregistre un résultat, si bien que la base de données grossit selon le nombre de moniteurs, la fréquence des vérifications et la durée de conservation de l'historique. Sur le serveur de DreamHost, vous pouvez conserver un an d'historique ou le garder indéfiniment. L'utilisateur qui a estimé 9 Go a présenté ce chiffre comme an order of magnitude, car il reposait sur un échantillon de 11 minutes. Notre dossier de données est passé de 1,4 Mo à vide à 5 Mo après l'ajout de 200 moniteurs et 15 minutes de vérifications, un échantillon trop court pour en extrapoler plusieurs mois. Stack 4 dispose de 75 Go de disque : vérifiez donc df -h tous les un ou deux mois au début. Si l'espace devient insuffisant, vous pouvez passer à une offre Stack supérieure, et votre environnement vous suit.

Comment accéder au tableau de bord

Le guide sur le proxy inverse d'Uptime Kuma recommande de placer devant lui un serveur web classique avec HTTPS, et cite Caddy comme un serveur qui obtient et renouvelle les certificats tout seul. Le serveur Uptime Kuma de DreamHost est conçu ainsi : vous accédez au tableau de bord via Caddy, avec un vrai HTTPS sur l'adresse IP du serveur.

Les pages de statut et les badges sont destinés à être publics : ils restent donc accessibles sans connexion.

Installation, étape par étape

Vous exécuterez les commandes ci-dessous en tant que root, ou en les précédant de sudo si vous vous connectez avec un autre utilisateur.

Connexion et mise à jour

1. Un serveur qui n'héberge rien d'autre

   Commandez Stack 4 avec Uptime Kuma, l'offre que DreamHost recommande pour cet usage, et réservez ce serveur au seul moniteur.

2. Récupérez l'identifiant créé au premier démarrage

   Le mot de passe administrateur est généré au premier démarrage, avant que le tableau de bord soit accessible. Connectez-vous au serveur en SSH et affichez-le :

   bashCopier

   cat /root/.uptime_kuma_credentials

   Connectez-vous à l'adresse IP de votre serveur en HTTPS. Conservez le mot de passe dans un gestionnaire de mots de passe. Plus tard, vous pourrez placer chaque page de statut sur son propre domaine.

3. Mettez à jour avant d'ajouter quoi que ce soit

   Un nouveau serveur démarre sur la version que DreamHost a figée et testée, qui peut être en retard sur la dernière version d'Uptime Kuma. Le script de mise à jour ne fait aucune sauvegarde de lui-même : lancez donc d'abord la sauvegarde :

   bashCopier

   uptime-kuma-backup
   uptime-kuma-update

   L'outil de mise à jour reste sur la version 2 et ne passe pas à une version majeure sans votre intervention. Au 15 octobre 2026, la dernière version d'Uptime Kuma était la 2.5.6.

Configurez la connexion et les alertes

1. Activez la connexion à deux facteurs

   Allez dans Settings, puis Security, et cliquez sur 2FA Settings. Uptime Kuma affiche un QR code à scanner avec une application d'authentification, puis demande un code généré par l'application pour confirmer.

2. Indiquez à Uptime Kuma de faire confiance à Caddy

   Allez dans Settings, puis Reverse Proxy, puis HTTP Headers, et réglez Trust Proxy sur Yes si ce n'est pas déjà fait. Le guide sur le proxy inverse d'Uptime Kuma recommande ce réglage pour les serveurs accessibles uniquement via un serveur web placé devant eux. Vos journaux affichent alors l'adresse réelle de chaque visiteur.

3. Ajoutez une notification, puis vos moniteurs

   Un moniteur en panne n'apparaît que sur le tableau de bord tant que vous n'avez pas ajouté de service de notification dans Settings, puis Notifications. Connectez d'abord l'e-mail, Slack ou Telegram, puis créez vos moniteurs.

Surveillez le moniteur et gardez une copie

1. Faites surveiller Uptime Kuma par un service externe

   L'offre gratuite d'UptimeRobot couvre 50 moniteurs avec des vérifications toutes les 5 minutes, et l'un d'eux peut surveiller l'adresse de votre Uptime Kuma. Un commentateur de Hacker News utilise UptimeRobot précisément pour cela : I only use it to monitor the Uptime Kuma that monitors the rest of my homelab.

   Un heartbeat fonctionne aussi. L'offre gratuite de Healthchecks.io surveille 20 tâches, et sa documentation shell fournit une ligne curl pour l'appeler. Placez devant une vérification locale rapide pour que l'appel ne parte que si Uptime Kuma répond, et ajoutez la ligne à la crontab du serveur avec crontab -e :

   bashCopier

   */5 * * * * curl -fsS -m 5 -o /dev/null http://127.0.0.1:3001 && curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here

   Ce heartbeat prouve que le serveur, ses tâches planifiées et l'application fonctionnent. La vérification UptimeRobot confirme en plus que le tableau de bord répond en HTTPS depuis l'extérieur. Les offres payantes d'UptimeRobot sont présentées dans notre guide sur les tarifs d'UptimeRobot comparés à Pingdom et Better Stack.

2. Copiez chaque sauvegarde hors du serveur

   Le guide de migration vers la v2 d'Uptime Kuma présente une copie du répertoire de données comme la seule sauvegarde prise en charge, et uptime-kuma-backup en crée une sous forme d'archive locale, puis indique où il l'a enregistrée. Depuis votre ordinateur, téléchargez ce fichier :

   bashCopier

   scp YOUR-USER@YOUR-SERVER-IP:/path/printed/by/the/script.tar.gz .

   Si vous vous connectez avec un autre utilisateur que root, copiez l'archive dans votre dossier personnel avec sudo cp et attribuez-vous-en la propriété avec sudo chown avant de la télécharger.

   Le script enregistre son archive sur le même disque qu'Uptime Kuma. Cette copie vous permet de revenir en arrière après une mise à jour ratée, mais elle ne vous sera d'aucune aide si vous perdez le serveur : ne la laissez donc pas là.

3. Suivez les nouvelles versions

   Debian installe ses correctifs en arrière-plan. Le conteneur Uptime Kuma, lui, ne se met pas à jour tout seul : chaque nouvelle version attend donc que vous relanciez les deux commandes de mise à jour. Suivez les nouvelles versions d'Uptime Kuma depuis le menu Watch du dépôt sur GitHub, et installez la dernière version dès sa sortie.

FAQ sur l'hébergement d'Uptime Kuma