Pendant longtemps, ma supervision se résumait à ça : je me connectais en SSH sur un serveur quand quelque chose semblait lent, je faisais un htop, je regardais si la RAM était pleine, et je passais à autre chose. Pour des incidents qui se produisent à 3h du matin, c'est évidemment inutile. J'ai découvert un VPS à court de disque deux jours après qu'il ait commencé à rejeter des requêtes — les logs de Traefik étaient saturés depuis le début mais personne ne les regardait.

J'avais essayé Netdata. Trop lourd pour des petits VPS à 4 Go de RAM où chaque ressource compte. Grafana + Prometheus ? Overkill pour ce que je voulais faire, et une demi-journée de configuration pour avoir un dashboard basique. Ce que je cherchais, c'était simple : voir en un coup d'œil l'état de toutes mes machines, et recevoir une notification sur mon téléphone quand quelque chose déraille.

Beszel fait exactement ça, sans rien de plus. Léger, rapide à déployer, et il s'intègre parfaitement dans mon environnement existant : Portainer pour la stack, WireGuard pour que les agents restent dans mon réseau isolé.

Ce qu'est Beszel

Beszel c'est un outil de supervision serveur open-source avec une architecture hub-agent. Le hub centralise tout et expose l'interface web. Les agents tournent sur chaque machine à surveiller et remontent les métriques au hub. CPU, RAM, disque, réseau, températures si disponibles — les essentiels, pas plus.

Ce qui m'a convaincu par rapport aux alternatives : la consommation ressources est ridicule. L'agent consomme moins de 10 Mo de RAM en fonctionnement. Sur un VPS à 2 Go, c'est un détail. Sur Netdata, c'était 200 à 300 Mo juste pour l'agent. Et l'interface est réactive — pas de dashboard qui met 5 secondes à charger des dizaines de panels Grafana.

L'autre point fort : la sécurité du modèle de connexion. Comme Portainer, c'est l'agent qui initie la connexion vers le hub, pas l'inverse. Ça change tout pour l'architecture réseau.

La stack Docker via Portainer

Le hub tourne sur mon serveur local principal, derrière Traefik. Je le gère comme toutes mes autres stacks, directement depuis Portainer :

version: "3"

services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel
    restart: unless-stopped
    volumes:
      - /opt/beszel/data:/beszel_data
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.beszel.rule=Host(`beszel.arnaudallouche.fr`)"
      - "traefik.http.routers.beszel.entrypoints=websecure"
      - "traefik.http.routers.beszel.tls.certresolver=letsencrypt"
      - "traefik.http.services.beszel.loadbalancer.server.port=8090"

networks:
  default:
    external:
      name: traefik_web

Premier démarrage, vous créez votre compte admin via l'interface web, et vous récupérez la clé publique SSH du hub dans les paramètres — c'est elle qui authentifie la connexion des agents.

Les agents via WireGuard : rien n'est exposé

Chaque machine à superviser fait tourner un agent Beszel. La subtilité : l'agent écoute par défaut sur le port 45876 en TCP. Comme pour Portainer, je bind ce port uniquement sur l'interface WireGuard de la machine. Depuis Internet, ce port n'existe pas.

Sur chaque serveur à superviser, en stack Portainer :

version: "3"

services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      PORT: 45876
      KEY: "ssh-ed25519 AAAA... (clé publique du hub)"

Le network_mode: host est nécessaire pour que l'agent ait accès aux métriques réseau réelles de la machine (pas celles du namespace réseau Docker). Sans ça, les graphes réseau sont faux — j'ai mis un moment à comprendre pourquoi mes VPS semblaient avoir zéro trafic réseau dans le dashboard.

Ensuite, la règle firewall sur l'interface WireGuard — même pattern que pour Portainer :

# Autoriser le port agent uniquement depuis le VPN
ufw allow in on wg0 to any port 45876 proto tcp

Dans l'interface Beszel, quand vous ajoutez un système, vous renseignez l'adresse IP VPN de la machine (10.8.0.x) et le port 45876. Le hub se connecte via WireGuard, la connexion est établie. Depuis Internet, personne ne peut joindre ces agents.

La vue d'ensemble sur toutes les machines

Une fois les agents connectés, le dashboard principal affiche toutes les machines en temps réel. Pour moi : 2 VPS et 2 serveurs locaux, tous visibles sur le même écran.

Ce que je surveille concrètement :

• CPU et RAM sur les VPS — pour détecter un conteneur qui part en boucle ou une fuite mémoire
• Disque — c'est ce qui m'a le plus manqué avant. Beszel affiche le pourcentage d'utilisation et l'évolution. Plus de surprise à 2h du matin
• Réseau — utile pour repérer un trafic anormal, surtout sur les VPS qui ont une limite de bande passante mensuelle
• Conteneurs Docker — Beszel remonte aussi l'état et les métriques des conteneurs individuels si vous montez le socket Docker. Je vois d'un coup d'œil si un conteneur a redémarré ou consomme anormalement

La granularité temporelle va de quelques minutes à plusieurs semaines. Pour un incident, je zoome sur les dernières heures. Pour de la capacité planning, je regarde les tendances sur le mois.

Les alertes Discord

C'est la fonctionnalité qui rend le système réellement utile. Sans alertes, un dashboard c'est un outil passif — vous voyez les problèmes quand vous regardez, pas quand ils se produisent.

Beszel supporte nativement les webhooks. Je l'ai branché sur un canal Discord dédié, ce qui me donne des notifications push sur mon téléphone dès qu'un seuil est franchi.

Configuration dans Settings → Notifications → Add notification :

• Type : Webhook
• URL : l'URL webhook de votre canal Discord (Settings du canal → Intégrations → Webhooks)

Ensuite, par système, vous définissez vos seuils d'alerte :

CPU  > 85% pendant 5 minutes  → alerte
RAM  > 90%                    → alerte
Disk > 80%                    → alerte
Statut agent offline          → alerte immédiate

Le seuil "agent offline" est celui que j'utilise le plus. Si une machine tombe ou si le réseau WireGuard a un problème, je reçois une notification en moins d'une minute. Avant je le découvrais au hasard.

Un point pratique : les alertes Discord arrivent avec le nom de la machine, la métrique concernée et la valeur actuelle. Pas besoin d'ouvrir le dashboard pour comprendre ce qui se passe — la notification dit "VPS-1 : disque à 87%", c'est directement actionnable.

Ce que ça m'a permis de corriger

Deux semaines après avoir mis Beszel en place, j'ai reçu une alerte RAM à 91% sur le VPS 2. En regardant les métriques des conteneurs, c'était un conteneur Node.js qui grossissait progressivement depuis plusieurs jours — fuite mémoire classique. Sans la supervision, j'aurais découvert le problème quand le VPS aurait commencé à swapper et que les temps de réponse auraient explosé.

J'ai aussi reçu deux alertes disque. La première sur un VPS où les logs Nginx s'accumulaient sans rotation configurée — 40 Go de logs en trois mois. La deuxième sur mon serveur local où les sauvegardes Docker montaient sans limite. Les deux auraient fini par saturer le disque et faire tomber les services.

Pourquoi cette combinaison fonctionne bien

Ce qui rend le setup cohérent, c'est que les trois outils partagent la même philosophie réseau. WireGuard crée le réseau isolé. Portainer et Beszel font écouter leurs agents uniquement sur ce réseau. Depuis Internet, la surface exposée reste minimale — juste le 443 de Traefik.

Administrativement, tout se gère depuis Portainer : déployer un nouvel agent Beszel sur une nouvelle machine prend deux minutes. Je colle la stack, je renseigne la clé publique du hub, et la machine apparaît dans le dashboard. Même workflow que pour tout le reste de mon infra.

Beszel est en développement actif, l'écosystème est encore jeune. Il manque quelques fonctionnalités qu'on trouve dans des solutions plus matures — pas de gestion fine des droits utilisateurs, les options d'alerte sont basiques comparées à AlertManager. Mais pour superviser une infra personnelle ou une petite équipe, c'est largement suffisant. Et la légèreté reste son principal avantage — je ne sacrifie pas 300 Mo de RAM sur chaque serveur pour avoir un dashboard.