Comment auto-héberger Uptime Kuma en 2026 : alertes, TLS et données persistantes

La plupart des notes d’installation d’Uptime Kuma s’arrêtent au premier chargement de la page. C’est trop tôt : le volume de données peut être en lecture seule ou le DNS du container peut ne pas résoudre les hôtes surveillés. Un test de production utile est plus exigeant : créer des monitors HTTP et TCP, provoquer une panne contrôlée et recevoir l’alerte ainsi que la notification de rétablissement via le provider choisi.

Le rôle d’Uptime Kuma est simple : surveiller des services existants et envoyer des alertes vers plus de 90 destinations. Son périmètre opérationnel ne se limite pas au processus web ; la dépendance, l’état stocké et la route publique doivent donc tous être explicitement définis avant l’arrivée des vraies données.

Définir d’abord le succès d’Uptime Kuma

Un diagramme utile d’Uptime Kuma montre la route publique, le port privé 3001, la limite de l’état et chaque prérequis associé. Indiquez quelles flèches transportent des identifiants et lesquelles correspondent à un trafic utilisateur ordinaire. Le prérequis externe d’Uptime Kuma est un accès sortant à chaque endpoint surveillé et à chaque provider d’alertes. Testez le DNS sortant, le TLS et le comportement du provider sans publier un autre service entrant.

Validez le diagramme avec une action réelle : créez des monitors HTTP et TCP, provoquez une panne contrôlée et recevez l’alerte ainsi que la notification de rétablissement via le provider choisi. La pression provient probablement de l’intervalle entre les checks, du nombre de retries, du trafic de la status page et du nombre de probes sortantes effectuées à la même seconde ; surveillez ce chemin au lieu de considérer toutes les requêtes HTTP comme équivalentes.

Exploiter Uptime Kuma en fonction de son véritable goulot d’étranglement

La première métrique opérationnelle utile pour Uptime Kuma est sa capacité à créer des monitors HTTP et TCP, à provoquer une panne contrôlée et à recevoir l’alerte ainsi que la notification de rétablissement via le provider choisi. Associez-la à des signaux de saturation pour l’intervalle entre les checks, le nombre de retries, le trafic de la status page et le nombre de probes sortantes effectuées à la même seconde. Une probe limitée au processus ne doit pas appeler de dépendances coûteuses ni redémarrer le container parce qu’un service upstream est brièvement indisponible.

Traitez les upgrades comme des changements de données, car les migrations SQLite et les changements de notification provider peuvent transformer un simple pull d’image en upgrade d’une application stateful. Épinglez les versions, répétez la procédure sur un état restauré et conservez l’image précédente jusqu’à ce qu’un rollback reste possible. Lorsque le volume de données est en lecture seule ou que le DNS du container ne peut pas résoudre les hôtes surveillés, conservez les logs précédant le redémarrage ; ils contiennent généralement le message à l’origine de la panne.

Documenter un déploiement Uptime Kuma de référence

Pour Uptime Kuma, définissez une transaction de référence avant le lancement : créer des monitors HTTP et TCP, provoquer une panne contrôlée et recevoir l’alerte ainsi que la notification de rétablissement via le provider choisi. Placez ses prérequis, le résultat attendu et les étapes de nettoyage dans le version control, sans valeurs secrètes. Épinglez l’image utilisée pour établir cette référence.

Utilisez cette transaction pour valider un remplacement et une restauration indépendante. Le service restauré n’est acceptable que lorsque l’historique des monitors, les identifiants des notification providers et les fenêtres de maintenance réapparaissent, et qu’une alerte de test est toujours distribuée. Dans le même temps, observez l’intervalle entre les checks, le nombre de retries, le trafic de la status page et le nombre de probes sortantes effectuées à la même seconde, puis transformez la partie la plus lente ou la plus contrainte en alerte de niveau service.

Le contrôle doit également inclure un cas négatif : refusez temporairement l’accès au chemin de test utilisé pour l’accès sortant à chaque endpoint surveillé et à chaque provider d’alertes. Vérifiez qu’Uptime Kuma produit une erreur exploitable tout en préservant les données, rétablissez la condition valide et répétez la transaction de référence. Conserver les deux résultats évite qu’un endpoint de health superficiel devienne la seule preuve en production.

Paramètres du container à vérifier

Utilisez le container comme un runtime remplaçable, et non comme l’emplacement de référence des données.

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 127.0.0.1:3001:3001 \
  -v uptime-kuma-data:/app/data \
  -e UPTIME_KUMA_PORT=3001 \
  louislam/uptime-kuma:1

Autorisez et vérifiez le chemin sortant ou côté client requis pour accéder à chaque endpoint surveillé et à chaque provider d’alertes. Inspectez l’utilisateur du container, les chemins accessibles en écriture et le listener associé avant toute exposition. Exécutez l’action complète — créer des monitors HTTP et TCP, provoquer une panne contrôlée et recevoir l’alerte ainsi que la notification de rétablissement via le provider choisi — et enregistrez la référence exacte de l’image ayant produit ce résultat.

Restaurer Uptime Kuma sur un hôte vierge

Protégez l’état d’Uptime Kuma avant d’optimiser son container. L’ensemble requis comprend la base de données SQLite et les assets chargés dans /app/data. Montez /app/data avant le bootstrap, écrivez quelques données de test inoffensives et remplacez le container pour prouver que ce chemin est réellement persistant. Si plusieurs stores doivent rester cohérents, documentez l’ordre dans lequel les écritures sont suspendues et les sauvegardes effectuées.

Conservez des copies en dehors du serveur de déploiement et chiffrez les éléments contenant des identifiants ou du contenu privé. La récupération réussit lorsque l’historique des monitors, les identifiants des notification providers et les fenêtres de maintenance réapparaissent, et qu’une alerte de test est toujours distribuée. La distinction entre un mount persistant et une copie indépendante est expliquée dans stockage persistant et snapshots.

Attribuer à Uptime Kuma une adresse canonique

Publiez une seule origin HTTPS stable via le reverse proxy. Dirigez le hostname choisi vers le port 3001 du container, transmettez l’hôte d’origine et le scheme HTTPS, et évitez de publier une seconde origin directe.

Testez Uptime Kuma depuis un client externe vierge. Distinguez une panne d’ingress de la limite applicative connue — le volume de données est en lecture seule ou le DNS du container ne peut pas résoudre les hôtes surveillés. Une erreur de certificat, de DNS ou de 502 relève du routage ; une requête qui atteint Uptime Kuma puis échoue relève de l’état de l’application, de sa capacité ou de l’un de ses prérequis. Le guide TLS pour les domaines personnalisés couvre le premier groupe.

Décisions de sécurité propres à Uptime Kuma

Le risque de sécurité propre à l’application est d’exécuter le setup du premier utilisateur sur une instance exposée publiquement. La réponse opérationnelle consiste à terminer ce setup en privé, puis à protéger séparément les dashboards et l’administration des status pages. Terminez le bootstrap via une route restreinte et supprimez immédiatement l’accès temporaire au setup.

UPTIME_KUMA_PORT contrôle le comportement, pas la confidentialité ; validez son type et sa valeur, et stockez les véritables identifiants Uptime Kuma séparément. N’accordez au processus Uptime Kuma que ses mounts documentés et ses routes vers les dépendances ; évitez tout accès au root de l’hôte et au socket Docker. Journalisez les échecs d’authentification et les erreurs de configuration, mais masquez les tokens, les connection strings et le contenu utilisateur.

Un déploiement Dockup nécessite toujours un test d’acceptation Uptime Kuma

Le routage, les certificats, le remplacement du service et le stockage attaché sont de bonnes cibles d’automatisation. Dockup les gère pour Uptime Kuma et peut provisionner la base de données managée associée ou se connecter aux services présents sur le propre serveur du client.

Ce que Dockup ne doit pas inventer, c’est la politique de confiance d’Uptime Kuma. Après le déploiement, publiez une seule origin HTTPS stable via le reverse proxy, appliquez cette limite — terminez le setup du premier utilisateur en privé, puis protégez séparément les dashboards et l’administration des status pages — et vérifiez le résultat du scénario suivant : créer des monitors HTTP et TCP, provoquer une panne contrôlée et recevoir l’alerte ainsi que la notification de rétablissement via le provider choisi. Le résultat est une infrastructure en un clic accompagnée d’un test d’acceptation propre à l’application.

Foire aux questions

De quoi Uptime Kuma a-t-il besoin pour un déploiement en production ?

Faites passer le container Uptime Kuma sur le port 3001 via une seule origin HTTPS. Le prérequis externe de distribution est un accès sortant à chaque endpoint surveillé et à chaque provider d’alertes. Ne considérez pas Uptime Kuma comme prêt tant que vous ne pouvez pas créer des monitors HTTP et TCP, provoquer une panne contrôlée et recevoir l’alerte ainsi que la notification de rétablissement via le provider choisi.

Quelles données Uptime Kuma faut-il inclure dans une sauvegarde ?

Rendez /app/data persistant et incluez la base de données SQLite ainsi que les assets chargés dans /app/data au sein du même manifest de récupération. Une restauration Uptime Kuma propre n’est validée que lorsque l’historique des monitors, les identifiants des notification providers et les fenêtres de maintenance réapparaissent, et qu’une alerte de test est toujours distribuée.

Uptime Kuma nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origin publique d’Uptime Kuma et conservez le port 3001 sur la route interne. Appliquez correctement le paramètre Uptime Kuma : publiez une seule origin HTTPS stable via le reverse proxy. Pour Uptime Kuma, HTTPS protège les identifiants ou le contenu utilisateur en transit et garantit un comportement cohérent des clients dépendant de l’origin.

Comment tester une mise à niveau d’Uptime Kuma ?

Restaurez l’état actuel d’Uptime Kuma dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations SQLite et les changements de notification provider peuvent transformer un simple pull d’image en upgrade d’une application stateful. Conservez l’image Uptime Kuma précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.