Votre application est déployée. Les utilisateurs s'inscrivent. Mais vous n'avez aucune idée si elle tombe à 3 h du matin, ou si le disque se remplit pendant que vous dormez.

Ce guide déploie deux outils de monitoring sur un seul VPS avec Docker Compose :

Uptime Kuma (84k+ étoiles GitHub) surveille la disponibilité externe : endpoints HTTP, ports TCP, enregistrements DNS, certificats SSL.
Beszel (~20k étoiles) surveille la santé interne du serveur : CPU, RAM, disque, réseau et statistiques Docker par conteneur.

Ensemble, ils consomment environ 150-180 Mo de RAM. Un stack Prometheus + Grafana + node_exporter pour le même travail nécessite 800+ Mo.

Prérequis : Un VPS sous Debian 12 ou Ubuntu 24.04 avec Docker et Docker Compose installés. Un reverse proxy (Caddy ou Nginx) gérant le TLS. Un nom de domaine avec le DNS pointant vers votre serveur. Ce guide utilise Caddy pour les exemples de reverse proxy. Docker en production sur un VPS : ce qui casse et comment corriger

Quelle est la différence entre Uptime Kuma et Beszel ?

Uptime Kuma surveille la disponibilité externe. Il vous indique si vos sites web, API et services sont accessibles depuis l'extérieur de votre serveur. Beszel surveille la santé interne du serveur : utilisation CPU, RAM, espace disque, bande passante réseau et statistiques Docker par conteneur. Un serveur web peut afficher un CPU faible et beaucoup de mémoire libre tout en étant complètement inaccessible à cause d'un pare-feu mal configuré ou d'un certificat TLS expiré. Vous avez besoin des deux outils.

Fonctionnalité	Uptime Kuma	Beszel
Ce qu'il surveille	HTTP, TCP, DNS, ping, expiration SSL, push/heartbeat	CPU, RAM, disque, réseau, température, conteneurs Docker
Architecture	Conteneur unique, interface web	Hub + agent (un agent par serveur surveillé)
Base de données	SQLite (par défaut) ou MariaDB	PocketBase (SQLite embarqué)
Canaux de notification	90+ (email, Telegram, Discord, Slack, webhooks, etc.)	Email (SMTP via PocketBase)
Pages de statut	Oui, publiques avec domaine personnalisé	Non
Utilisation RAM	~80-120 Mo	Hub : ~10-50 Mo, Agent : ~25 Mo
Étoiles GitHub	84k+	~20k

Aucun des deux outils ne remplace l'autre. Uptime Kuma détecte les pannes externes. Beszel détecte l'épuisement des ressources avant qu'il ne provoque des pannes externes.

Quelle quantité de RAM le stack de monitoring utilise-t-il ?

Uptime Kuma v2.x utilise environ 80-120 Mo de RAM selon le nombre de moniteurs. Le hub Beszel ajoute 10-50 Mo et chaque agent utilise environ 25 Mo. Le stack combiné fonctionne confortablement sur un VPS de 1 Go, utilisant environ 150-180 Mo au total. En comparaison, Prometheus + Grafana + node_exporter ensemble nécessitent 800+ Mo rien qu'au repos.

Stack	RAM au repos	Temps de mise en place	Idéal pour
Uptime Kuma + Beszel	~150-180 Mo	30 minutes	Petites et moyennes installations auto-hébergées
Prometheus + Grafana + node_exporter	~800 Mo+	2-4 heures	Infrastructure à grande échelle avec requêtes personnalisées
Netdata	~300-400 Mo	15 minutes	Métriques en temps réel, serveur unique

Comment installer Uptime Kuma avec Docker Compose ?

Uptime Kuma fonctionne comme un conteneur unique servant son interface web sur le port 3001. Le fichier Compose ci-dessous épingle la version majeure 2, lie au localhost uniquement, définit des limites de ressources et ajoute un health check.

Créez le répertoire du projet :

mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma

Créez le fichier Compose :

# /opt/uptime-kuma/compose.yaml
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data
    environment:
      - TZ=Europe/Berlin
    deploy:
      resources:
        limits:
          memory: 256m
          cpus: "0.5"
    healthcheck:
      test: ["CMD", "node", "/app/extra/healthcheck.js"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 15s

Le binding 127.0.0.1:3001:3001 garantit que le conteneur n'écoute que sur localhost. Sans le préfixe 127.0.0.1, Docker publie le port sur toutes les interfaces, contournant votre pare-feu. Docker contourne UFW : 4 solutions testées pour votre VPS

Démarrez le conteneur :

docker compose up -d

[+] Running 1/1
 ✔ Container uptime-kuma  Started

docker compose ps

NAME           IMAGE                      COMMAND                  SERVICE        CREATED          STATUS                    PORTS
uptime-kuma    louislam/uptime-kuma:2     "/usr/bin/dumb-init …"   uptime-kuma    10 seconds ago   Up 9 seconds (healthy)    127.0.0.1:3001->3001/tcp

Le statut (healthy) signifie que le health check intégré est passé. Si vous voyez (starting), attendez 15 secondes le temps que le start_period se termine.

Reverse proxy avec Caddy

Ajoutez une entrée à votre Caddyfile :

# /etc/caddy/Caddyfile (append)
status.example.com {
    reverse_proxy localhost:3001
}

Rechargez Caddy :

systemctl reload caddy

Caddy obtient automatiquement un certificat TLS auprès de Let's Encrypt. Ouvrez https://status.example.com dans votre navigateur. Uptime Kuma vous invite à créer un compte administrateur au premier accès.

Activez le 2FA immédiatement

Après avoir créé votre compte administrateur, allez dans Settings > Security > Two-Factor Authentication et activez-le. Le tableau de bord d'Uptime Kuma donne un accès en lecture à toute la topologie de votre infrastructure. Quiconque compromet le login voit chaque endpoint surveillé. Configurez le 2FA avant d'ajouter des moniteurs.

Comment configurer Beszel pour surveiller mon VPS ?

Beszel utilise une architecture hub-agent. Le hub est le tableau de bord web qui stocke les données et affiche les métriques. L'agent s'exécute sur chaque serveur que vous souhaitez surveiller et transmet les métriques au hub. Lorsque les deux tournent sur le même VPS, ils communiquent via un socket Unix au lieu du réseau.

Créez le répertoire du projet :

mkdir -p /opt/beszel && cd /opt/beszel

Créez le fichier Compose :

# /opt/beszel/compose.yaml
services:
  beszel-hub:
    image: henrygd/beszel:0.18
    container_name: beszel-hub
    restart: unless-stopped
    ports:
      - "127.0.0.1:8090:8090"
    environment:
      - APP_URL=https://beszel.example.com
    volumes:
      - ./beszel_data:/beszel_data
      - ./beszel_socket:/beszel_socket
    deploy:
      resources:
        limits:
          memory: 128m
          cpus: "0.25"

  beszel-agent:
    image: henrygd/beszel-agent:0.18
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./beszel_agent_data:/var/lib/beszel-agent
      - ./beszel_socket:/beszel_socket
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - LISTEN=/beszel_socket/beszel.sock
      - KEY=${BESZEL_KEY}
    deploy:
      resources:
        limits:
          memory: 64m
          cpus: "0.15"

À propos de cette configuration :

L'image du hub est épinglée à 0.18, qui inclut le correctif CVE-2026-27734 (v0.18.4). Épingler à une version mineure empêche les changements cassants inattendus tout en recevant les mises à jour de correctifs.
L'agent utilise network_mode: host pour pouvoir lire les statistiques des interfaces réseau de l'hôte. C'est nécessaire pour un monitoring précis de la bande passante.
L'agent et le hub partagent un volume beszel_socket pour la communication via socket Unix. Cela évite d'exposer le port 45876 sur le réseau quand les deux tournent sur le même serveur.
Le socket Docker est monté en lecture seule (:ro). Plus de détails dans la section sécurité ci-dessous.

Sécurité du socket Docker

Monter /var/run/docker.sock donne à l'agent l'accès à l'API Docker. Même avec :ro, c'est effectivement un accès équivalent à root car l'API Docker peut créer des conteneurs privilégiés, lire les variables d'environnement de n'importe quel conteneur et accéder aux volumes. Durcissement de la sécurité Docker : mode rootless, Seccomp et AppArmor sur un VPS

Beszel a besoin du socket pour collecter les statistiques CPU, mémoire et réseau par conteneur. Si vous n'avez pas besoin du monitoring des conteneurs, supprimez entièrement le montage du socket Docker.

CVE-2026-27734 (corrigé dans v0.18.4) a démontré ce risque : un utilisateur authentifié de Beszel pouvait traverser l'API Docker via des identifiants de conteneur non assainis, atteignant des endpoints arbitraires comme /version ou /containers/json. Le correctif assainit toutes les entrées utilisateur avant de construire les URLs de l'API Docker. Assurez-vous d'exécuter v0.18.4 ou plus récent. Le tag 0.18 dans le fichier Compose ci-dessus correspond à v0.18.4 (dernier correctif en date de mars 2026).

Générer la clé de l'agent

Démarrez d'abord le hub :

cd /opt/beszel
docker compose up -d beszel-hub

Ouvrez le hub à l'adresse https://beszel.example.com (après avoir configuré votre reverse proxy, section suivante). Créez un compte administrateur. Allez dans Add System dans le tableau de bord. Le hub affiche une clé publique. Copiez-la.

Créez un fichier .env pour l'agent :

# /opt/beszel/.env
BESZEL_KEY="ssh-ed25519 AAAA... (paste the key from the hub UI)"

chmod 600 /opt/beszel/.env

Démarrez maintenant l'agent :

docker compose up -d beszel-agent

De retour dans l'interface du hub, ajoutez le système en utilisant le chemin du socket /beszel_socket/beszel.sock. En quelques secondes, les métriques CPU, RAM, disque et conteneurs Docker apparaissent.

Reverse proxy pour Beszel

Ajoutez à votre Caddyfile :

# /etc/caddy/Caddyfile (append)
beszel.example.com {
    reverse_proxy localhost:8090
}

systemctl reload caddy

Comment configurer les notifications dans Uptime Kuma ?

Uptime Kuma supporte plus de 90 canaux de notification. Les trois plus courants pour l'auto-hébergement sont l'email (SMTP), Telegram et Discord.

Notifications email SMTP

Allez dans Settings > Notifications > Setup Notification. Sélectionnez Email (SMTP) comme type.

Champ	Valeur
Hostname	Votre serveur SMTP (ex. : `smtp.example.com`)
Port	`587` (STARTTLS) ou `465` (TLS implicite)
Security	STARTTLS ou TLS
Username	Votre nom d'utilisateur SMTP
Password	Votre mot de passe SMTP
From Email	`monitoring@example.com`
To Email	`vous@example.com`

Cliquez sur Test pour envoyer une notification de test avant d'enregistrer. Uptime Kuma envoie le test immédiatement. En cas d'échec, vérifiez vos identifiants SMTP et les règles de pare-feu (le port 587 sortant doit être ouvert).

Notifications bot Telegram

Envoyez un message à @BotFather sur Telegram et créez un nouveau bot avec /newbot.
Copiez le token du bot (format : 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11).
Démarrez une conversation avec votre bot et envoyez n'importe quel message.
Obtenez votre chat ID : ouvrez https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates dans votre navigateur. Le champ chat.id dans la réponse est votre chat ID.
Dans Uptime Kuma, ajoutez une notification Telegram. Collez le token du bot et le chat ID. Cliquez sur Test.

Notifications webhook Discord

Dans votre serveur Discord, allez dans Server Settings > Integrations > Webhooks > New Webhook.
Nommez-le (ex. : « Uptime Kuma »), choisissez un canal et copiez l'URL du webhook.
Dans Uptime Kuma, ajoutez une notification Discord et collez l'URL du webhook. Cliquez sur Test.

Définissez la notification par défaut pour qu'elle s'applique à tous les nouveaux moniteurs en cochant Default Enabled. Ainsi, chaque moniteur que vous créez hérite du canal de notification sans configuration manuelle.

Quels types de moniteurs Uptime Kuma configurer ?

Uptime Kuma supporte de nombreux types de moniteurs. Voici les quatre plus utiles pour un stack auto-hébergé :

HTTP(s) - Vérifie une URL, éventuellement cherche un mot-clé dans le corps de la réponse. À utiliser pour les applications web, les API et les tableaux de bord. Définissez le mot-clé sur une chaîne qui n'apparaît que lorsque l'application est saine (ex. : le nom de votre application dans le titre HTML).
TCP - Se connecte à un host:port. À utiliser pour les bases de données (PostgreSQL sur 5432), les serveurs mail (SMTP sur 587), ou tout service sans endpoint HTTP.
DNS - Résout un nom d'hôte et vérifie que le résultat correspond à une IP attendue. Détecte le détournement DNS ou les enregistrements mal configurés.
Push / Heartbeat - Uptime Kuma génère une URL. Votre tâche cron ou script de sauvegarde l'appelle en cas de succès. Si l'URL n'est pas appelée dans l'intervalle, Uptime Kuma déclenche une alerte. C'est le seul moyen de surveiller les scripts qui n'ont pas de port en écoute.

Exemple de moniteur push pour les tâches cron

Créez un moniteur Push dans Uptime Kuma. Définissez l'intervalle de heartbeat sur la fréquence de votre cron plus une période de grâce. Copiez l'URL push.

Ajoutez l'appel curl à la fin de votre script de sauvegarde :

#!/bin/bash
# /opt/scripts/backup.sh
pg_dump mydb | gzip > /backups/mydb-$(date +%F).sql.gz

# Signal success to Uptime Kuma
curl -fsS -o /dev/null "https://status.example.com/api/push/abc123?status=up&msg=backup-ok"

Si le script échoue avant d'atteindre la ligne curl, ou si cron ne s'exécute pas, Uptime Kuma marque le moniteur comme down après l'expiration de l'intervalle.

Comment configurer les alertes Beszel pour le CPU et le disque ?

Les alertes Beszel vous notifient lorsque les métriques du serveur dépassent un seuil. Cliquez sur l'icône de cloche à côté de n'importe quel système dans le tableau de bord pour configurer les alertes.

Seuils recommandés pour un petit VPS (2-4 vCPU, 4-8 Go de RAM) :

Métrique	Avertissement	Critique	Pourquoi
CPU	> 70 % pendant 5 min	> 90 % pendant 2 min	Un CPU élevé soutenu signifie des processus emballés ou une instance sous-dimensionnée
RAM	> 80 % pendant 5 min	> 90 % pendant 2 min	Linux commence à swapper lourdement au-dessus de 85 %, tuant les performances
Disque	> 80 %	> 90 %	Les images Docker, les logs et les bases de données grossissent silencieusement. À 100 % les services plantent
Bande passante	> 80 % de la limite du forfait	> 95 %	Prévient les frais de dépassement ou le throttling

Ces seuils sont intentionnellement plus bas que les valeurs par défaut en entreprise. Sur un petit VPS, vous avez moins de marge. Un pic de 70 % à 100 % CPU prend des secondes, pas des minutes.

Configurer SMTP pour les alertes Beszel

Beszel utilise PocketBase comme backend. Le SMTP se configure via le panneau d'administration PocketBase :

Allez à https://beszel.example.com/_/ (l'URL d'administration PocketBase, notez le underscore).
Connectez-vous avec les identifiants administrateur créés lors de l'installation.
Allez dans Settings > Mail settings.
Activez Use SMTP mail server.
Entrez votre hôte SMTP, port, nom d'utilisateur et mot de passe.
Définissez l'adresse d'expéditeur.
Cliquez sur Save et Send test email.

Comment créer une page de statut publique avec Uptime Kuma ?

Uptime Kuma peut servir des pages de statut publiques montrant la disponibilité de vos services. Elles sont utiles pour communiquer l'uptime à vos utilisateurs sans exposer votre tableau de bord de monitoring.

Allez dans Status Pages dans la barre latérale gauche.
Cliquez sur New Status Page. Choisissez un nom et un slug (ex. : status).
Ajoutez des groupes (ex. : « Services Web », « API », « Infrastructure »).
Glissez les moniteurs dans chaque groupe.
Publiez la page. Elle est accessible à https://status.example.com/status/<slug>.

Domaine personnalisé pour la page de statut

Si vous souhaitez que https://status.example.com serve directement la page de statut, définissez-la comme page par défaut dans les paramètres d'Uptime Kuma. Le chemin racine affiche alors la page publique tandis que le tableau de bord reste à /dashboard.

Les pages de statut ne nécessitent pas d'authentification. Ne mettez pas de moniteurs dans un groupe de page de statut si révéler l'existence de l'endpoint est un risque de sécurité.

Gestion des incidents

Quand un service tombe, Uptime Kuma l'affiche automatiquement comme dégradé sur la page de statut. Vous pouvez aussi créer des incidents manuels :

Allez dans Status Pages, sélectionnez votre page, cliquez sur Create Incident.
Écrivez un titre et une description (ex. : « Maintenance base de données, durée estimée 15 minutes »).
Définissez le style sur info, warning, danger ou primary.
Publiez. La bannière d'incident apparaît en haut de la page de statut publique.

Résolvez l'incident quand c'est terminé. Uptime Kuma conserve un historique des incidents passés pour que vos utilisateurs puissent voir votre bilan opérationnel.

Comment surveiller mon stack de monitoring depuis l'extérieur ?

Si votre VPS tombe, Uptime Kuma et Beszel tombent avec lui. Vous apprenez la panne en même temps que vos utilisateurs. La solution : un watchdog externe qui surveille votre instance Uptime Kuma depuis un autre emplacement.

Option 1 : UptimeRobot (offre gratuite)

Créez un compte gratuit sur UptimeRobot.
Ajoutez un nouveau moniteur : type HTTP(s), URL https://status.example.com/api/status-page/heartbeat/<slug>.
Définissez l'intervalle de vérification à 5 minutes.
Configurez les notifications par email ou Telegram.

L'endpoint /api/status-page/heartbeat/<slug> renvoie un payload JSON avec le statut. UptimeRobot le vérifie et vous alerte si votre instance Uptime Kuma devient inaccessible.

Option 2 : Healthchecks.io (offre gratuite)

Healthchecks.io fonctionne avec le modèle push. Créez un check, copiez l'URL de ping et ajoutez une tâche cron sur votre VPS :

# /etc/cron.d/monitoring-heartbeat
*/5 * * * * root curl -fsS --retry 3 -o /dev/null https://hc-ping.com/your-uuid-here

Si le ping cron cesse d'arriver (parce que votre serveur est down), Healthchecks.io vous envoie une alerte. Cela couvre le scénario où votre VPS entier devient inaccessible.

Option 3 : surveiller depuis un second VPS

Si vous exploitez plusieurs serveurs, installez Uptime Kuma sur un VPS différent et faites en sorte que chaque instance surveille l'autre. C'est l'approche la plus fiable car vous contrôlez les deux endpoints et il n'y a aucune dépendance à une offre gratuite tierce.

Renforcement de la sécurité

Règles de pare-feu

Si vous exécutez l'agent Beszel en mode standalone sur un serveur distant (sans utiliser la méthode du socket Unix), il écoute sur le port 45876. Seul le hub doit atteindre ce port :

ufw allow from <hub-ip-address> to any port 45876 proto tcp comment "Beszel agent"
ufw status numbered

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere
[ 4] 45876/tcp                  ALLOW IN    <hub-ip-address>

N'ouvrez pas le port 45876 au monde entier. L'agent expose les métriques système sans authentification sur ce port. Il s'appuie sur la clé SSH du hub pour la vérification, mais la restriction au niveau réseau ajoute une défense en profondeur.

Pour la configuration sur un seul VPS de ce guide, le port 45876 n'est pas nécessaire du tout car le hub et l'agent communiquent via un socket Unix.

Uptime Kuma : désactiver l'authentification par mot de passe pour l'API

Si vous accédez à Uptime Kuma uniquement via son interface web, désactivez l'accès API via Settings > Security > API Key. Moins d'endpoints exposés, moins de choses à patcher.

Masquage de version

Uptime Kuma et Beszel exposent tous deux les informations de version dans leur interface web par défaut. Votre reverse proxy ne doit pas aggraver cela. Dans votre Caddyfile, Caddy omet déjà les en-têtes Server par défaut. Si vous utilisez Nginx à la place :

server_tokens off;

La divulgation de version aide les attaquants à cibler des vulnérabilités connues. Gardez-la minimale.

Comment sauvegarder les données d'Uptime Kuma et Beszel ?

Les deux outils utilisent des bases de données basées sur SQLite. Les fichiers SQLite ne peuvent pas être copiés en toute sécurité pendant que l'application écrit dedans. Utilisez les méthodes de sauvegarde appropriées.

Sauvegarde Uptime Kuma

Uptime Kuma stocke tout dans /app/data (mappé vers ./data dans le fichier Compose). La sauvegarde intégrée exporte un fichier JSON :

Allez dans Settings > Backup.
Cliquez sur Export. Sauvegardez le fichier JSON hors du serveur.

Pour les sauvegardes automatisées, arrêtez brièvement le conteneur ou utilisez la sauvegarde en ligne de SQLite :

sqlite3 /opt/uptime-kuma/data/kuma.db ".backup '/opt/backups/kuma-$(date +%F).db'"

Sauvegarde Beszel

Beszel utilise PocketBase. Sauvegardez le répertoire de données :

sqlite3 /opt/beszel/beszel_data/data.db ".backup '/opt/backups/beszel-$(date +%F).db'"

Stockez les sauvegardes hors du serveur. Un stack de monitoring qui perd son historique quand le disque lâche ne surveille rien du tout. Sauvegarder et restaurer les volumes Docker sur un VPS

Comment mettre à jour Uptime Kuma et Beszel en toute sécurité ?

Épinglez la version mineure, pas latest. Cela empêche les changements cassants d'arriver sans votre accord.

# Update Uptime Kuma
cd /opt/uptime-kuma
docker compose pull
docker compose up -d

[+] Pulling 1/1
 ✔ uptime-kuma Pulled
[+] Running 1/1
 ✔ Container uptime-kuma  Started

docker compose ps

Vérifiez que la colonne STATUS affiche (healthy). Si la nouvelle version cause des problèmes, épinglez la version précédente dans compose.yaml et recréez :

# In compose.yaml, change the image tag to the previous version:
# image: louislam/uptime-kuma:2.2.1
docker compose up -d

Le même processus s'applique à Beszel. Sauvegardez toujours avant de mettre à jour.

Stratégie d'épinglage des images

Le tag louislam/uptime-kuma:2 suit la dernière version 2.x. C'est pratique mais signifie que docker compose pull peut sauter de 2.2.1 à 2.3.0 sans prévenir. En production, épinglez une version mineure spécifique :

image: louislam/uptime-kuma:2.2

Consultez les notes de version avant de pull. Uptime Kuma publie ses versions sur GitHub. Beszel fait de même sur sa page de releases.

Abonnez-vous aux notifications de versions des deux dépôts (Watch > Custom > Releases sur GitHub) pour savoir quand les correctifs de sécurité sortent.

Limites de ressources, healthchecks et politiques de redémarrage Docker Compose

Dépannage

Uptime Kuma affiche (unhealthy) dans docker compose ps :

docker compose logs uptime-kuma --tail 50

Causes courantes : base de données SQLite corrompue (restaurez depuis une sauvegarde), conflit de port (un autre service sur 3001), ou mémoire insuffisante (augmentez la limite de ressources).

L'agent Beszel ne se connecte pas au hub :

docker compose logs beszel-agent --tail 50

Vérifiez que la KEY dans .env correspond à la clé affichée dans la boîte de dialogue Add System du hub. Si vous utilisez des sockets Unix, vérifiez que le chemin du volume partagé correspond sur les deux services.

Beszel n'affiche pas les statistiques des conteneurs Docker :

Le montage du socket Docker est manquant ou le chemin du socket Docker est incorrect. Vérifiez :

ls -la /var/run/docker.sock

srw-rw---- 1 root docker 0 Mar 20 10:00 /var/run/docker.sock

Le socket doit exister et le conteneur doit avoir un accès en lecture. Le montage :ro dans le fichier Compose gère cela.

Les notifications n'arrivent pas :

Pour le SMTP : vérifiez que le port 587 (ou 465) sortant n'est pas bloqué par votre hébergeur. Certains hébergeurs bloquent le SMTP sortant par défaut. Testez avec :

nc -zv smtp.example.com 587

Connection to smtp.example.com 587 port [tcp/submission] succeeded!

Pour Telegram : vérifiez le token du bot et le chat ID. Le chat ID doit être un nombre, pas le nom d'utilisateur du bot.

Utilisation mémoire élevée :

Le nombre de moniteurs compte. Uptime Kuma v2.x utilise environ 100 Mo au repos. Chaque moniteur HTTP ajoute un état de connexion. Si vous dépassez 100 moniteurs avec une limite mémoire de 256 Mo, augmentez la limite ou répartissez sur plusieurs instances.

Vérifiez l'utilisation réelle :

docker stats --no-stream uptime-kuma beszel-hub beszel-agent

CONTAINER ID   NAME           CPU %     MEM USAGE / LIMIT   MEM %     NET I/O       BLOCK I/O   PIDS
abc123         uptime-kuma    0.15%     99MiB / 256MiB      38.67%    1.2kB / 2kB   0B / 0B     8
def456         beszel-hub     0.08%     10MiB / 128MiB      7.81%     1kB / 1.5kB   0B / 745kB  8
ghi789         beszel-agent   0.05%     22MiB / 64MiB       34.38%    0B / 0B       0B / 0B     5

Rotation des logs Docker : empêcher vos logs de saturer le disque VPS

Auto-héberger Uptime Kuma et Beszel sur un VPS avec Docker Compose