Quando un homelab cresce oltre il singolo server, arriva inevitabilmente il momento in cui serve sapere cosa stanno facendo le macchine. CPU, RAM, dischi, container Docker, temperature: senza una visione d’insieme si naviga al buio, e quando qualcosa rallenta restano solo top e htop aperti su molti terminali diversi.
La risposta canonica della comunità self-hosted è da anni la stessa: Prometheus per raccogliere le metriche, node_exporter e cAdvisor sugli host, Grafana per le dashboard, eventualmente Alertmanager per le notifiche. Funziona ed è potentissimo, ma chiunque l’abbia configurato sa che mettere in piedi quella catena richiede ore tra file YAML, target di scraping, query PromQL e dashboard JSON da importare.
Beszel arriva da un’angolazione opposta: un singolo binario Go per l’agent, un container per l’hub e zero configurazione iniziale. Il risultato è una piattaforma che in pochi minuti mostra grafici puliti su CPU, memoria, rete, dischi, GPU e container, con storico, allarmi e supporto multi-account. Il footprint è ridottissimo, con l’agent che gira tipicamente sotto i 10 MB di RAM, rendendolo adatto anche a Raspberry Pi, mini-PC ARM o VPS economici dove ogni megabyte conta.
Va detto subito che si tratta di un progetto ancora giovane, con la versione 0.18.x rilasciata nella primavera 2026, e con un perimetro funzionale volutamente limitato. Proprio per questo ha senso esaminarlo nel dettaglio: capire cosa fa bene, dove conviene ancora la stack tradizionale e come integrarlo nel proprio flusso di lavoro.
Hub e agent: due binari, una connessione cifrata
L’architettura di Beszel è volutamente semplice e si articola su due componenti che comunicano in modo asimmetrico. L’hub è un’applicazione web costruita su PocketBase che espone l’interfaccia, gestisce gli account, conserva lo storico delle metriche in SQLite e centralizza la configurazione degli allarmi. Su ciascuna macchina da monitorare gira invece un agent: un binario Go statico, oppure un’immagine Docker minimale, che raccoglie le statistiche dal sistema operativo e le rende disponibili al hub.
A differenza dello stack Prometheus, dove il server “scrapa” attivamente i target via HTTP, Beszel può funzionare in due modalità di trasporto. La prima, storicamente quella di default, prevede che l’agent agisca come un server SSH ultraleggero su una porta dedicata (la 33873 di norma) e che sia l’hub a connettersi via SSH per leggere le metriche. La seconda, più recente e oggi consigliata negli ambienti dietro NAT o reverse proxy, sfrutta una connessione WebSocket in uscita dall’agent verso l’hub, autenticata con un token.
Questo dettaglio architetturale ha conseguenze praticamente decisive. Significa che non occorre esporre porte sui sistemi monitorati né bucare il firewall del datacenter, e l’agent può collegarsi all’hub passando da Tailscale, WireGuard, Cloudflare Tunnel o qualunque overlay network già in uso. La crittografia è basata su chiavi pubbliche generate al primo avvio dell’hub, e l’autenticazione di ogni nuovo agent richiede di incollare quella chiave nella sua configurazione. Niente certificati x.509, niente CA private, niente reverse proxy obbligatorio.
Cinque minuti dal docker-compose alla dashboard
L’installazione dell’hub si esaurisce in un singolo docker-compose.yml di poche righe, che monta una directory per la persistenza dei dati ed espone la porta 8090. Bastano poi docker compose up -d e una visita al browser per andare sulla schermata di registrazione del primo account, che diventa automaticamente amministratore dell’istanza.
services:
beszel:
image: henrygd/beszel:latest
container_name: beszel
restart: unless-stopped
environment:
APP_URL: http://localhost:8090
ports:
- 8090:8090
volumes:
- ./beszel_data:/beszel_dataA questo punto si clicca “Add System” e l’interfaccia mostra direttamente il blocco docker-compose o lo script bash da copiare sull’host da monitorare, già completi di chiave pubblica e token. Sull’agent Linux il modo più rapido è il comando curl -sL https://get.beszel.dev -o /tmp/install-agent.sh && /tmp/install-agent.sh, che crea un account beszel non privilegiato, installa il binario in /opt/beszel-agent e registra un service systemd.
Abilitando l’opzione dedicata si attivano anche gli aggiornamenti automatici giornalieri. Per chi preferisce Docker, l’agent va eseguito in network_mode: host per leggere correttamente le statistiche di rete dell’host, e va montato /var/run/docker.sock in sola lettura per accedere alle metriche dei container.
Tornando nell’hub, dopo qualche secondo il nuovo sistema appare con il pallino verde e i grafici iniziano a popolarsi. È sensato dedicare i primi minuti a popolare i tag (ambiente, ruolo, posizione fisica) e a impostare gli allarmi di base su CPU, memoria, disco e status, perché il valore di un sistema di monitoraggio si misura quando qualcosa va male, non quando tutto funziona.
GPU, S.M.A.R.T. e ZFS: cosa è arrivato nelle ultime release
Le ultime release hanno spostato l’asticella di Beszel su funzionalità che fino a un anno fa appartenevano solo alle stack pesanti. Il monitoring GPU è stato esteso oltre Nvidia per coprire anche le schede AMD via ROCm e le iGPU Intel, mentre nella versione 0.18 è approdato il supporto sperimentale alle GPU Apple Silicon attraverso integrazioni come nvtop, particolarmente utile per chi sta facendo girare modelli locali su Mac mini M-series usati come nodi inference. La variabile d’ambiente GPU_COLLECTOR consente inoltre di forzare manualmente il backend, su sistemi misti o con driver custom.
Sul fronte storage il quadro è cambiato in modo simile. Beszel legge i dati S.M.A.R.T. dei dischi connessi, con esposizione opzionale di temperature, ore di funzionamento, sector reallocation count e percentuale di vita residua. Include la salute delle eMMC tramite sysfs per chi ha mini-PC e SBC con storage saldato, e mostra lo stato degli array mdraid Linux. ZFS ARC viene tracciato come componente separata della memoria, dettaglio non banale per chi gira TrueNAS e si chiede perché la RAM “sembra sempre piena”.
Per i container, infine, non serve cAdvisor né altri componenti: l’agent parla direttamente al socket Docker o Podman e fornisce CPU, memoria e rete per singolo container, con possibilità di ordinare e filtrare la tabella. Combinato con una pagina globale “All Containers” che aggrega tutti i sistemi connessi, diventa molto rapido individuare quale servizio sta divorando RAM e su quale nodo si trova, senza saltare tra dieci tab di Portainer.
Allarmi, OAuth e backup S3: il livello operativo
Un sistema di monitoring diventa davvero utile nel momento in cui ti avvisa al posto di costringerti a guardare le dashboard. Beszel gestisce gli allarmi con regole su soglia per CPU, memoria, disco, banda, temperatura, load average e stato di connessione, con valori configurabili anche manualmente da campo testo, utile per soglie del tipo 87% che le slider non centrano mai.
Le notifiche viaggiano su due canali: SMTP classico e Shoutrrr, libreria che parla nativamente con Discord, Telegram, Pushover, Gotify, Ntfy, Slack, Matrix e una decina di altri provider tramite URL strutturate. Chi ha un’istanza Ntfy self-hosted può configurare l’invio in un singolo campo, senza scrivere webhook custom.
Sul versante autenticazione, Beszel ha aggiunto OAuth/OIDC con i principali provider, e questo lo rende immediatamente integrabile in ambienti dove gira già Authelia, Authentik o Pocket-ID. Si può disattivare completamente il login con password e legare gli account al proprio Identity Provider, allineando il monitoring alle stesse policy di accesso usate per il resto dei servizi self-hosted. La gestione multi-account permette di dare a colleghi o familiari la visibilità solo sui sistemi di loro competenza.
I backup automatici si configurano dall’interfaccia e supportano sia destinazioni locali, sia bucket S3-compatibili come Backblaze B2, MinIO, Cloudflare R2 o AWS S3. Il dump comprende l’intero database PocketBase ed è ripristinabile con un click, dettaglio che aiuta a non trasformare il pannello di monitoring nel primo single point of failure dell’infrastruttura.
Quando Beszel basta e quando serve qualcosa di più
Vale la pena chiarire cosa Beszel non è. Non è una piattaforma di osservabilità completa: non ingerisce log, non raccoglie metriche applicative custom, non parla in formato OpenTelemetry, non fa tracing distribuito e non offre un linguaggio di query alla PromQL. Chi sta scrivendo SLO, ha bisogno di metriche avanzate o gestisce un ambiente di produzione multi-team continuerà giustamente a usare Prometheus, VictoriaMetrics o stack commerciali.
L’ecosistema di plugin e dashboard di terze parti è inoltre più piccolo di quello di Grafana, in modo prevedibile per un progetto ancora giovane. Beszel offre semplicità operativa al posto della flessibilità illimitata.
La forza del progetto sta nell’aver identificato con chiarezza quella fascia di chi gestisce infrastrutture che la stack canonica serve male: l’homelabber con cinque-quindici nodi, la piccola agenzia con un paio di VPS, il singolo sviluppatore che gira mezza dozzina di servizi su un dedicato. In quei contesti il 90% di ciò che si guarda davvero è “quali CPU, quanta RAM, quanto disco, quali container girano correttamente?”. Beszel risponde a queste domande con un costo di mantenimento prossimo allo zero, senza il debito tecnico di una stack che richiede attenzione regolare.
Se ti riconosci in questo profilo vale la pena dedicargli qualche minuto di prova: avvia l’hub in un container, lancia l’install script su un paio di host e nel giro di un pomeriggio avrai una dashboard più pulita di quella costruita su Grafana negli anni. Se in seguito le esigenze cresceranno, niente vieta di affiancare Prometheus per le metriche custom, mantenendo Beszel come pannello operativo quotidiano.
