Deux méthodes principales pour installer Uptime Kuma en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer) : via Coolify (le plus rapide) ou Docker direct (plus de contrôle). Voici les deux tutoriels.
Voir notre guide Uptime Kuma complet.
Méthode 1 — Coolify
- Coolify → Projects → « + New Resource » → One-Click Service
- Rechercher « Uptime Kuma » → cliquer
- Domain :
https://status.exemple.sn - Storage : ajouter Persistent Volume sur
/app/data(10 Go suffisent) - Deploy
5 minutes plus tard, ouvrir l’URL et créer le compte admin (premier utilisateur enregistré devient admin).
Méthode 2 — Docker manuel
# docker-compose.yml
version: "3"
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: always
ports:
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
docker compose up -d
Reverse proxy Caddy
# /etc/caddy/Caddyfile
status.exemple.sn {
reverse_proxy 127.0.0.1:3001
@ws {
header Connection *Upgrade*
header Upgrade websocket
}
reverse_proxy @ws 127.0.0.1:3001
}
Important : Uptime Kuma utilise WebSocket pour le live update du dashboard, donc le reverse proxy doit gérer l’upgrade WebSocket.
Sécurité
- Activer 2FA dans Settings → Security
- Désactiver « Allow registration » (Settings → General) après création du premier admin
- Backup régulier du dossier
data/(contient kuma.db SQLite) - Cloud Firewall : limiter accès au panel par IP si possible
Backup
#!/bin/bash
# Cron quotidien
DATE=$(date +%Y%m%d)
docker stop uptime-kuma
tar czf /tmp/kuma-$DATE.tar.gz ./data/
docker start uptime-kuma
aws s3 cp /tmp/kuma-$DATE.tar.gz s3://backups/uptime-kuma/
rm /tmp/kuma-$DATE.tar.gz
Mises à jour
# Coolify : auto via Application → Update
# Docker :
docker compose pull
docker compose down
docker compose up -d
Sur un angle proche
Démarrer en production sur un VPS
Pour passer du local à un serveur réellement accessible en ligne, Hostinger propose des plans VPS abordables avec sauvegarde automatique.
Lien d affiliation. Si vous achetez via ce lien, le blog reçoit une petite commission sans surcoût pour vous.
Pourquoi Uptime Kuma est l’outil de monitoring open source le plus pertinent en 2026
Quand un site WooCommerce de Dakar tombe à 14 h en pleine ruée Tabaski ou un dashboard Metabase d’Abidjan plante en pleine clôture comptable, vous voulez l’apprendre en moins d’une minute, pas par un client mécontent sur WhatsApp. Uptime Kuma est un monitoring open source écrit en Node.js et Vue, avec une interface aussi propre que les SaaS payants à 30 USD par mois (19 670 FCFA). La version 2.x publiée en 2025 ajoute le support natif des sondes gRPC, des notifications Microsoft Teams Adaptive Cards et un mode multi-utilisateurs avec rôles. Elle reste totalement gratuite et auto-hébergée — aucune fuite de données vers un tiers américain.
Avant de commencer, vous devez disposer d’un VPS Linux avec Docker installé, un nom de domaine pointé vers le serveur (par exemple monitoring.exemple.sn) et un compte sur Coolify si vous suivez la voie GUI. Pour la voie Docker pure, un Hetzner CX22 à 4,51 EUR (2 960 FCFA) ou un Scaleway Stardust à 1,80 EUR (1 180 FCFA) suffit largement — Uptime Kuma consomme moins de 200 Mo de RAM en croisière.
Étape 1 — Choisir entre Coolify et Docker Compose direct
Coolify est une plateforme PaaS open source qui gère Nginx, Let’s Encrypt, les déploiements Git et les sauvegardes automatiquement. C’est idéal si vous gérez plusieurs services et voulez une UI pour ajouter Uptime Kuma en deux clics. Docker Compose direct est plus simple si vous n’avez qu’un VPS et que vous gérez Nginx vous-même. Cette série couvre les deux approches ; choisissez celle qui correspond à votre stack actuelle.
Étape 2 — Voie A : déployer via Coolify (méthode recommandée pour débutants)
Si Coolify est déjà installé sur votre VPS, l’installation prend moins de 3 minutes. Connectez-vous au tableau de bord Coolify, cliquez sur + Add Resource puis Service, et tapez « uptime-kuma » dans la barre de recherche. Coolify propose un template officiel maintenu par la communauté.
Configurez les paramètres suivants :
- Server : votre VPS de production
- Destination : le réseau Docker Coolify par défaut
- Domain :
https://monitoring.exemple.sn(Coolify gère le certificat Let’s Encrypt automatiquement) - Persistent Storage : laissez le volume
/app/datacoché — c’est là que Kuma stocke sa base SQLite
Cliquez Deploy. Coolify pull l’image louislam/uptime-kuma:1, crée le réseau, lance le conteneur et provisionne le certificat. La progression s’affiche en temps réel dans l’onglet Logs. Au bout de 60 à 90 secondes, vous voyez Listening on 3001 et le bouton Open devient cliquable.
Étape 3 — Voie B : déploiement Docker Compose pur
Si vous préférez la maîtrise totale, créez un dossier /srv/uptime-kuma et le fichier suivant :
mkdir -p /srv/uptime-kuma && cd /srv/uptime-kuma
cat > compose.yaml <<'EOF'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
ports:
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
EOF
docker compose up -d
Le port 3001 est volontairement exposé uniquement sur l’interface localhost (127.0.0.1) — jamais directement sur Internet. Vérifiez que le conteneur tourne avec docker compose ps ; vous devez voir uptime-kuma Up 10 seconds.
Étape 4 — Reverse proxy Nginx avec WebSocket
Uptime Kuma utilise Socket.IO pour pousser les statuts en temps réel au navigateur. Sans la configuration WebSocket adéquate, l’interface reste figée. Voici la configuration Nginx complète :
server {
listen 443 ssl http2;
server_name monitoring.exemple.sn;
ssl_certificate /etc/letsencrypt/live/monitoring.exemple.sn/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/monitoring.exemple.sn/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 86400s;
}
}
Le proxy_read_timeout 86400s empêche Nginx de couper la connexion WebSocket toutes les minutes. Testez avec nginx -t, puis rechargez avec systemctl reload nginx. Visitez https://monitoring.exemple.sn ; vous devez tomber sur l’écran de création du compte administrateur Uptime Kuma.
Étape 5 — Créer le compte admin et les premières sondes
L’écran initial demande un nom d’utilisateur et un mot de passe d’au moins 6 caractères. Choisissez un mot de passe long (16+ caractères avec un gestionnaire) car Uptime Kuma n’a pas de mécanisme natif de 2FA pour ce compte par défaut.
Cliquez + Add New Monitor. Pour surveiller un site WordPress, sélectionnez :
- Monitor Type : HTTP(s) – Keyword
- URL :
https://exemple.sn/ - Keyword : un mot présent dans le footer du site (ex : « Mentions légales ») — détecte les pages blanches WordPress qui renvoient un 200 mais sans contenu
- Heartbeat Interval : 60 secondes (suffisant et économe en bande passante)
- Retries : 2 — évite les fausses alertes sur micro-coupures réseau Sonatel
Étape 6 — Notifications WhatsApp, Telegram et email
Une alerte qui n’arrive pas est inutile. Uptime Kuma propose 90+ canaux. Les trois plus pertinents en Afrique de l’Ouest francophone :
Telegram est le plus simple et fiable. Créez un bot via @BotFather, copiez le token, ajoutez le bot à un groupe « Alertes infra » avec votre équipe DevOps, récupérez le chat_id via https://api.telegram.org/bot<TOKEN>/getUpdates. Dans Uptime Kuma : Settings → Notifications → Setup Notification → Telegram, collez le token et le chat_id, cliquez Test. Vous devez recevoir le message « Test message » dans le groupe en moins de 3 secondes.
Webhook générique permet de pousser vers un workflow n8n qui relaie ensuite vers WhatsApp Business Cloud API (Graph API v25.0). Format JSON envoyé :
{
"monitor": {"name": "Site WooCommerce"},
"heartbeat": {"status": 0, "msg": "timeout", "time": "2026-05-05 14:32:11"}
}
Le statut 0 = DOWN, 1 = UP, 2 = PENDING. Votre n8n filtre sur status=0, formate un message court et le pousse vers le numéro WhatsApp d’astreinte.
SMTP reste utile pour des alertes archivées. Si vous utilisez Brevo (ex Sendinblue), 300 emails par jour gratuits suffisent largement. Mettez smtp-relay.brevo.com port 587, votre clé SMTP, et un destinataire dédié comme infra@exemple.sn.
Étape 7 — Page de statut publique et SLA
Pour rassurer vos clients, créez une page de statut publique. Status Pages → New Status Page, donnez-lui un slug comme public. La page sera accessible à https://monitoring.exemple.sn/status/public. Sélectionnez les sondes à exposer (cachez les sondes internes type bases de données), ajoutez un titre, un logo, et activez l’affichage des incidents passés sur 30 jours.
Pour mesurer un SLA contractuel à 99,5 % (engagement standard pour une PME), Uptime Kuma calcule automatiquement le pourcentage de disponibilité affiché dans l’onglet Statistics. Sur 30 jours, 99,5 % autorise 3 h 36 min d’indisponibilité — réaliste avec une stack mutualisée. Pour 99,9 %, la marge tombe à 43 min : prévoir HA (haute disponibilité) avec un load balancer.
Étape 8 — Sauvegarder la base SQLite
Toute la configuration Uptime Kuma (sondes, notifications, comptes) tient dans data/kuma.db. Sauvegardez ce fichier chaque nuit avec votre Restic existant ou un simple cron :
0 3 * * * docker exec uptime-kuma sqlite3 /app/data/kuma.db ".backup /app/data/kuma.backup.db" && cp /srv/uptime-kuma/data/kuma.backup.db /backup/kuma-$(date +%F).db
La commande .backup de SQLite produit un fichier cohérent même si Kuma écrit dedans. Conservez 14 jours de backup ; en cas de corruption, restaurez avec cp kuma-2026-04-30.db data/kuma.db && docker compose restart.
Lectures complémentaires
Cette base couvre la supervision standard d’une PME ouest-africaine. À lire ensuite, intégrez Uptime Kuma à votre stack Docker Compose en production et combinez avec un backup Restic des volumes pour ne jamais perdre l’historique. Si vous gérez plus de 50 sondes ou plusieurs régions, regardez Beszel (plus léger) ou Gatus (déclaratif YAML), tous deux open source et complémentaires.
Mode multi-utilisateurs et rôles (Kuma 2.x)
Si plusieurs développeurs ou administrateurs systèmes interviennent, créez un compte par personne pour tracer les modifications. Allez dans Settings → Multiple Users (option visible à partir de la 2.0). Chaque utilisateur reçoit un rôle parmi Admin, Editor (peut créer/modifier les sondes mais pas les comptes) ou Viewer (lecture seule, parfait pour un commercial à qui vous montrez le tableau de bord). Le journal d’audit (Settings → Audit Log) garde 90 jours d’historique : qui a modifié quelle sonde, quand, depuis quelle IP. Indispensable en cas de mauvaise manipulation.
Surveillance avancée : ports TCP, certificats SSL, jobs cron
Au-delà de HTTP, Uptime Kuma sait surveiller des choses utiles à toute PME. Trois exemples qui sauvent régulièrement :
Sonde TCP Port sur le port 5432 de votre PostgreSQL : détecte un crash silencieux du conteneur avant que les utilisateurs ne s’en rendent compte. Configurez le hostname (l’IP privée du conteneur), le port et un intervalle de 60 secondes. Évitez d’exposer Postgres à Internet — surveillez via le réseau Docker interne.
Sonde HTTP avec Certificate Expiry : Kuma alerte 14 jours avant expiration d’un certificat Let’s Encrypt. Si votre acme-challenge est cassé (DNS mal configuré, port 80 fermé), vous l’apprenez à temps. Activez l’option Certificate Expiry Notification dans la sonde HTTPS.
Sonde Push : pour surveiller un cron qui doit s’exécuter toutes les nuits (sauvegarde Restic, génération PDF, sync ERP), créez une sonde de type Push, copiez l’URL fournie (https://monitoring.exemple.sn/api/push/abc123) et appelez-la à la fin de votre script avec curl -fsS &> /dev/null. Si Kuma ne reçoit rien dans la fenêtre attendue, alerte instantanée.
# Dans /etc/systemd/system/restic-backup.service
ExecStartPost=/usr/bin/curl -fsS https://monitoring.exemple.sn/api/push/abc123?status=up &> /dev/null
Cette technique remplace avantageusement les services payants type Healthchecks.io ou Cronitor pour des PME ouest-africaines qui veulent rester maîtres de leurs données.
Maintenance et mises à jour
Uptime Kuma publie environ une mise à jour mineure par mois. Mettez à jour avec :
cd /srv/uptime-kuma
docker compose pull
docker compose up -d
Le redémarrage prend 5 secondes ; les sondes reprennent immédiatement et l’historique est préservé via le volume ./data. Avant chaque mise à jour majeure (1.x → 2.x), copiez data/kuma.db dans data/kuma.db.before-upgrade — la migration est généralement sans douleur mais une copie locale rassure.
Coûts et bilan
Pour une agence digitale d’Abidjan ou Dakar qui supervise 30 sites WordPress clients, le coût total est : VPS Hetzner CX22 4,51 EUR (2 960 FCFA), domaine .sn ou .ci 12 USD par an (environ 650 FCFA par mois), Telegram et email gratuits. Total mensuel : moins de 4 000 FCFA. Comparé à Pingdom Standard à 15 USD par mois (9 840 FCFA) ou UptimeRobot Pro à 7 USD (4 590 FCFA) avec moins de sondes, l’auto-hébergement est imbattable dès le premier client.
Limites connues et bonnes pratiques opérationnelles
Uptime Kuma reste un outil mono-instance avec une base SQLite — il n’est pas conçu pour superviser 5 000 sondes ou tourner en cluster haute disponibilité. À partir de 200 sondes, surveillez la consommation CPU et la latence de la base. Au-delà de 500 sondes ou si plusieurs sites stratégiques tombent en cas de crash de l’instance Kuma elle-même, déployez deux instances dans deux régions différentes (Hetzner Allemagne et Scaleway Paris par exemple) qui se surveillent mutuellement via une sonde HTTP croisée. Ce double-monitoring coûte 5 EUR de plus par mois (3 280 FCFA) mais détecte le cas pathologique où votre superviseur lui-même est en panne.
Côté sécurité, ne jamais exposer le port 3001 directement sur Internet : passez toujours par Nginx ou Traefik avec HTTPS. Activez fail2ban sur le serveur pour bloquer les tentatives de brute-force sur la page de login Kuma — un filtre simple sur /var/log/nginx/access.log qui détecte les POST répétés vers /login suffit. Enfin, si vous gérez des données clients sensibles, mettez votre instance derrière un VPN WireGuard ou Tailscale pour qu’elle ne soit jamais publique du tout.