Héberger Uptime Kuma sur un VPS infogéré : surveillez vos services en continu

Ce que surveille Uptime Kuma

Uptime Kuma interroge vos services à intervalle régulier, jusqu'à toutes les 20 secondes, garde l'historique de leurs réponses et vous prévient dès que l'un d'eux ne répond plus. Il s'utilise depuis une interface web, disponible en plusieurs langues.

• Les sondes : HTTP et HTTPS, recherche d’un mot-clé dans la page, requête JSON, TCP, WebSocket, ping, enregistrement DNS, conteneurs Docker, et sonde « push » pour une tâche planifiée qui signale elle-même son passage.
• Les alertes : plus de 90 services de notification, dont Telegram, Discord, Slack et l’e-mail.
• Les pages d’état : plusieurs pages publiques, chacune sur son propre domaine si vous le souhaitez.
• Les certificats : les informations du certificat HTTPS de chaque service surveillé.
• Le compte : double authentification, et passage par un proxy pour les sondes qui en ont besoin.

Placez Uptime Kuma sur un autre serveur que les services qu'il surveille. Sur une machine distincte, il voit la panne de l'extérieur et envoie l'alerte pendant que vos services sont arrêtés.

Ce que permet la licence MIT

Uptime Kuma est publié sous licence MIT. Elle autorise à utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre le logiciel, à une condition : garder la mention de copyright et le texte de la licence dans toute copie.

Vous pouvez donc faire tourner Uptime Kuma en entreprise, y surveiller les services de vos clients et leur ouvrir des pages d'état, sans licence à acheter.

L'installation avec Docker Compose

La documentation d'Uptime Kuma commence par Docker Compose. Sur un serveur où Docker est installé, créez un dossier et récupérez le fichier officiel :

mkdir uptime-kuma
cd uptime-kuma
curl -o compose.yaml https://raw.githubusercontent.com/louislam/uptime-kuma/master/compose.yaml

Le fichier du projet publie le port 3001 sur toutes les adresses du serveur. Derrière un proxy inverse, limitez-le à l'adresse locale, comme le propose le README :

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

docker compose up -d

• Un port publié sur 127.0.0.1 : Docker publie par défaut sur toutes les adresses du serveur, avant les règles du pare-feu ufw. En local, Uptime Kuma s'atteint par le seul proxy inverse.
• Un dossier data sur un disque local : il garde la base kuma.db, les fichiers envoyés et les captures d'écran. Le projet écarte NFS et les autres systèmes de fichiers réseau, car SQLite a besoin de verrous de fichiers fiables.
• L'étiquette 2 suit la version 2 d'Uptime Kuma, et le passage à une version majeure suivante reste un choix de votre part.
• L'image 2-slim est plus légère, environ 185 Mo à télécharger contre 620 Mo : elle laisse de côté Chromium et le MariaDB intégré que porte l'image 2. L'image 2 est celle que le projet recommande, et une sonde « Browser Engine » demande alors un Chromium externe avec 2-slim.

Au premier lancement, ouvrez l'interface : un assistant vous fait choisir la base de données, puis créer le compte administrateur. Activez la double authentification dès la première connexion.

Le projet ne chiffre ni la mémoire ni le processeur : la taille dépend du nombre de services à surveiller et de la fréquence voulue. Sur un VPS infogéré, décrivez-nous votre usage et nous vous recommandons la taille qui convient.

HTTPS et WebSocket : le proxy inverse

Sur un réseau public, le projet demande HTTPS. Uptime Kuma repose sur WebSocket : le proxy inverse doit transmettre les en-têtes Upgrade et Connection. Il se sert à la racine d'un domaine ou d'un sous-domaine, et son wiki écarte les sous-dossiers comme example.com/uptimekuma.

Avec Caddy

Caddy obtient et renouvelle seul le certificat, et transmet WebSocket sans réglage de plus :

uptime.example.com {
    reverse_proxy 127.0.0.1:3001
}

Avec Nginx et Certbot

server {
    listen 80;
    server_name uptime.example.com;

    location / {
        proxy_pass         http://localhost:3001;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
        proxy_set_header   Host $host;
    }
}

Certbot pose ensuite le certificat Let’s Encrypt et la redirection vers HTTPS, puis renouvelle le certificat de lui-même :

sudo certbot --nginx -d uptime.example.com

Quand Uptime Kuma n'est joignable que par le proxy, ouvrez ses réglages, « Settings », « Reverse Proxy », « HTTP Headers », et passez « Trust Proxy » à « Yes » : les journaux affichent alors l'adresse réelle des visiteurs.

SQLite ou MariaDB

Depuis sa version 2, Uptime Kuma propose trois bases, au choix de l'assistant du premier lancement :

Pour fixer le choix d'avance, sans passer par l'assistant, les variables UPTIME_KUMA_DB_TYPE, UPTIME_KUMA_DB_HOSTNAME, UPTIME_KUMA_DB_PORT, UPTIME_KUMA_DB_NAME, UPTIME_KUMA_DB_USERNAME et UPTIME_KUMA_DB_PASSWORD s'ajoutent au service dans compose.yaml.

Les notifications, e-mail compris

Une sonde ne sert que si l'alerte vous parvient. Déclarez vos canaux dans « Settings », « Notifications », envoyez un message d'essai depuis chacun, et prévoyez-en deux, par exemple une messagerie et l'e-mail : si l'un tombe, l'autre prend le relais.

Pour l'e-mail, Uptime Kuma se connecte à un serveur SMTP. Sur un VPS Simafri, l'envoi passe par un relais authentifié, sur le port 587 : l'adresse d'un compte de messagerie que vous avez déjà, ou Simafri Suite.

Sauvegardes et mises à jour

Depuis la version 2, la sauvegarde du dossier data est la seule méthode que le projet prend en charge. Avec SQLite ou le MariaDB intégré, tout y tient. Une base SQLite copiée en pleine écriture peut se retrouver corrompue : arrêtez le conteneur le temps de la copie, en sachant que les sondes s'arrêtent avec lui.

docker compose stop
tar -czf uptime-kuma-$(date +%F).tar.gz data
docker compose start

Mettre à jour

Le wiki du projet donne deux commandes, depuis le dossier du compose.yaml. Le dossier data reste en place :

docker compose pull
docker compose up -d --force-recreate

Lisez les notes de version avant chaque mise à jour : certaines portent des correctifs de sécurité, comme la 2.5.9 du 31 octobre 2026. Une sauvegarde juste avant vous donne un retour arrière simple.

Le passage de la version 1 à la version 2 demande plus de soin : sauvegardez le dossier data, conteneur arrêté, et laissez la migration aller à son terme, car une migration interrompue impose de restaurer la sauvegarde. Le projet a relevé environ 7 minutes pour 20 sondes et 90 jours d'historique, et bien plus sur une machine modeste ou avec davantage de sondes.

Qui fait quoi sur un VPS infogéré

L'auto-hébergement demande de tenir le serveur en plus de l'application. Sur un VPS infogéré, nos équipes prennent le serveur en main et suivent votre instance de manière proactive ; Uptime Kuma reste votre logiciel, avec ses réglages et ses données.

Si vous préférez que nos équipes interviennent dans l'application elle-même, cette prestation se facture à l'heure ou au forfait, avec un chiffrage communiqué avant l'intervention.