La tua app è in produzione. Gli utenti si stanno registrando. Ma non hai idea se va giù alle 3 di notte, o se il disco si riempie mentre dormi.

Questa guida distribuisce due strumenti di monitoraggio su un singolo VPS usando Docker Compose:

Uptime Kuma (84k+ stelle GitHub) monitora la disponibilità esterna: endpoint HTTP, porte TCP, record DNS, certificati SSL.
Beszel (~20k stelle) monitora lo stato interno del server: CPU, RAM, disco, rete e statistiche Docker per container.

Insieme consumano circa 150-180 MB di RAM. Uno stack Prometheus + Grafana + node_exporter per lo stesso lavoro richiede 800+ MB.

Prerequisiti: Un VPS con Debian 12 o Ubuntu 24.04 con Docker e Docker Compose installati. Un reverse proxy (Caddy o Nginx) che gestisce il TLS. Un nome di dominio con DNS che punta al tuo server. Questa guida usa Caddy per gli esempi di reverse proxy. Docker in produzione su un VPS: cosa si rompe e come risolvere

Qual è la differenza tra Uptime Kuma e Beszel?

Uptime Kuma monitora la disponibilità esterna. Ti dice se i tuoi siti web, API e servizi sono raggiungibili dall'esterno del server. Beszel monitora lo stato interno del server: utilizzo CPU, RAM, spazio su disco, banda di rete e statistiche Docker per container. Un server web può mostrare CPU bassa e molta memoria libera pur essendo completamente irraggiungibile a causa di un firewall mal configurato o un certificato TLS scaduto. Hai bisogno di entrambi gli strumenti.

Funzionalità	Uptime Kuma	Beszel
Cosa monitora	HTTP, TCP, DNS, ping, scadenza SSL, push/heartbeat	CPU, RAM, disco, rete, temperatura, container Docker
Architettura	Container singolo, interfaccia web	Hub + agent (un agent per server monitorato)
Database	SQLite (predefinito) o MariaDB	PocketBase (SQLite integrato)
Canali di notifica	90+ (email, Telegram, Discord, Slack, webhook, ecc.)	Email (SMTP via PocketBase)
Pagine di stato	Sì, pubbliche con dominio personalizzato	No
Utilizzo RAM	~80-120 MB	Hub: ~10-50 MB, Agent: ~25 MB
Stelle GitHub	84k+	~20k

Nessuno dei due strumenti sostituisce l'altro. Uptime Kuma rileva i guasti esterni. Beszel rileva l'esaurimento delle risorse prima che causi guasti esterni.

Quanta RAM usa lo stack di monitoraggio?

Uptime Kuma v2.x usa circa 80-120 MB di RAM a seconda del numero di monitor. L'hub Beszel aggiunge 10-50 MB e ogni agent usa circa 25 MB. Lo stack combinato funziona comodamente su un VPS da 1 GB, usando circa 150-180 MB in totale. Per confronto, Prometheus + Grafana + node_exporter insieme richiedono 800+ MB solo a riposo.

Stack	RAM a riposo	Tempo di configurazione	Ideale per
Uptime Kuma + Beszel	~150-180 MB	30 minuti	Installazioni self-hosted piccole e medie
Prometheus + Grafana + node_exporter	~800 MB+	2-4 ore	Infrastrutture su larga scala con query personalizzate
Netdata	~300-400 MB	15 minuti	Metriche in tempo reale, server singolo

Come installo Uptime Kuma con Docker Compose?

Uptime Kuma funziona come un singolo container che serve la sua interfaccia web sulla porta 3001. Il file Compose qui sotto fissa il tag alla versione major 2, si lega solo a localhost, imposta limiti di risorse e aggiunge un health check.

Crea la directory del progetto:

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

Crea il file 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

Il binding 127.0.0.1:3001:3001 assicura che il container ascolti solo su localhost. Senza il prefisso 127.0.0.1, Docker pubblica la porta su tutte le interfacce, aggirando il firewall. Docker bypassa UFW: 4 soluzioni testate per il tuo VPS

Avvia il container:

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

Lo stato (healthy) significa che l'health check integrato è passato. Se vedi (starting), attendi 15 secondi per il completamento dello start_period.

Reverse proxy con Caddy

Aggiungi una voce al tuo Caddyfile:

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

Ricarica Caddy:

systemctl reload caddy

Caddy ottiene automaticamente un certificato TLS da Let's Encrypt. Apri https://status.example.com nel browser. Uptime Kuma ti chiede di creare un account amministratore al primo accesso.

Abilita subito il 2FA

Dopo aver creato l'account amministratore, vai su Settings > Security > Two-Factor Authentication e abilitalo. La dashboard di Uptime Kuma dà accesso in lettura all'intera topologia della tua infrastruttura. Chiunque comprometta il login vede ogni endpoint monitorato. Configura il 2FA prima di aggiungere qualsiasi monitor.

Come configuro Beszel per monitorare il mio VPS?

Beszel usa un'architettura hub-agent. L'hub è la dashboard web che archivia i dati e visualizza le metriche. L'agent gira su ogni server che vuoi monitorare e trasmette le metriche all'hub. Quando entrambi girano sullo stesso VPS, comunicano tramite un socket Unix anziché via rete.

Crea la directory del progetto:

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

Crea il file 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"

Informazioni su questa configurazione:

L'immagine dell'hub è fissata a 0.18, che include la correzione per CVE-2026-27734 (v0.18.4). Fissare a una versione minor previene modifiche incompatibili inattese continuando a ricevere aggiornamenti di patch.
L'agent usa network_mode: host per poter leggere le statistiche delle interfacce di rete dell'host. Questo è necessario per un monitoraggio accurato della banda.
L'agent e l'hub condividono un volume beszel_socket per la comunicazione via socket Unix. Questo evita di esporre la porta 45876 sulla rete quando entrambi girano sullo stesso server.
Il socket Docker è montato in sola lettura (:ro). Maggiori dettagli nella sezione sicurezza qui sotto.

Sicurezza del socket Docker

Montare /var/run/docker.sock dà all'agent accesso all'API Docker. Anche con :ro, questo è effettivamente un accesso equivalente a root perché l'API Docker può creare container privilegiati, leggere variabili d'ambiente da qualsiasi container e accedere ai volumi. Sicurezza Docker: Rootless Mode, Seccomp e AppArmor su VPS

Beszel ha bisogno del socket per raccogliere statistiche di CPU, memoria e rete per container. Se non hai bisogno del monitoraggio dei container, rimuovi completamente il mount del socket Docker.

CVE-2026-27734 (corretto in v0.18.4) ha dimostrato questo rischio: un utente Beszel autenticato poteva attraversare l'API Docker tramite ID container non sanificati, raggiungendo endpoint arbitrari come /version o /containers/json. La correzione sanifica tutti gli input utente prima di costruire gli URL dell'API Docker. Assicurati di eseguire v0.18.4 o successiva. Il tag 0.18 nel file Compose sopra si risolve in v0.18.4 (ultima patch a marzo 2026).

Generare la chiave dell'agent

Avvia prima l'hub:

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

Apri l'hub su https://beszel.example.com (dopo aver configurato il reverse proxy, sezione successiva). Crea un account amministratore. Vai su Add System nella dashboard. L'hub mostra una chiave pubblica. Copiala.

Crea un file .env per l'agent:

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

chmod 600 /opt/beszel/.env

Ora avvia l'agent:

docker compose up -d beszel-agent

Nell'interfaccia dell'hub, aggiungi il sistema usando il percorso del socket /beszel_socket/beszel.sock. In pochi secondi appaiono le metriche di CPU, RAM, disco e container Docker.

Reverse proxy per Beszel

Aggiungi al tuo Caddyfile:

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

systemctl reload caddy

Come configuro le notifiche in Uptime Kuma?

Uptime Kuma supporta oltre 90 canali di notifica. I tre più comuni per il self-hosting sono email (SMTP), Telegram e Discord.

Notifiche email SMTP

Vai su Settings > Notifications > Setup Notification. Seleziona Email (SMTP) come tipo.

Campo	Valore
Hostname	Il tuo server SMTP (es. `smtp.example.com`)
Port	`587` (STARTTLS) o `465` (TLS implicito)
Security	STARTTLS o TLS
Username	Il tuo nome utente SMTP
Password	La tua password SMTP
From Email	`monitoring@example.com`
To Email	`tu@example.com`

Clicca Test per inviare una notifica di prova prima di salvare. Uptime Kuma invia il test immediatamente. Se fallisce, controlla le credenziali SMTP e le regole del firewall (la porta 587 in uscita deve essere aperta).

Notifiche bot Telegram

Scrivi a @BotFather su Telegram e crea un nuovo bot con /newbot.
Copia il token del bot (formato: 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11).
Avvia una chat con il tuo bot e invia un messaggio qualsiasi.
Ottieni il tuo chat ID: apri https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates nel browser. Il campo chat.id nella risposta è il tuo chat ID.
In Uptime Kuma, aggiungi una notifica Telegram. Incolla il token del bot e il chat ID. Clicca Test.

Notifiche webhook Discord

Nel tuo server Discord, vai su Server Settings > Integrations > Webhooks > New Webhook.
Assegnagli un nome (es. "Uptime Kuma"), scegli un canale e copia l'URL del webhook.
In Uptime Kuma, aggiungi una notifica Discord e incolla l'URL del webhook. Clicca Test.

Imposta la notifica predefinita per applicarla a tutti i nuovi monitor spuntando Default Enabled. Così ogni monitor che crei eredita il canale di notifica senza configurazione manuale.

Quali tipi di monitor Uptime Kuma dovrei configurare?

Uptime Kuma supporta molti tipi di monitor. Ecco i quattro più utili per uno stack self-hosted:

HTTP(s) - Controlla un URL, opzionalmente cerca una parola chiave nel corpo della risposta. Usalo per web app, API e dashboard. Imposta la parola chiave su una stringa che appare solo quando l'app è sana (es. il nome della tua app nel titolo HTML).
TCP - Si connette a un host:porta. Usalo per database (PostgreSQL su 5432), server di posta (SMTP su 587) o qualsiasi servizio senza endpoint HTTP.
DNS - Risolve un hostname e verifica che il risultato corrisponda a un IP atteso. Rileva il dirottamento DNS o record mal configurati.
Push / Heartbeat - Uptime Kuma genera un URL. Il tuo cronjob o script di backup lo chiama in caso di successo. Se l'URL non viene chiamato entro l'intervallo, Uptime Kuma lancia un avviso. È l'unico modo per monitorare script che non hanno una porta in ascolto.

Esempio di monitor push per cronjob

Crea un monitor Push in Uptime Kuma. Imposta l'intervallo di heartbeat sulla frequenza del tuo cron più un periodo di grazia. Copia l'URL push.

Aggiungi la chiamata curl alla fine del tuo script di backup:

#!/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"

Se lo script fallisce prima di raggiungere la riga curl, o se cron non si esegue, Uptime Kuma segna il monitor come down dopo la scadenza dell'intervallo.

Come configuro gli avvisi Beszel per CPU e disco?

Gli avvisi Beszel ti notificano quando le metriche del server superano una soglia. Clicca l'icona della campanella accanto a qualsiasi sistema nella dashboard per configurare gli avvisi.

Soglie raccomandate per un piccolo VPS (2-4 vCPU, 4-8 GB RAM):

Metrica	Avvertimento	Critico	Perché
CPU	> 70% per 5 min	> 90% per 2 min	CPU alta sostenuta significa processi fuori controllo o istanza sottodimensionata
RAM	> 80% per 5 min	> 90% per 2 min	Linux inizia a swappare pesantemente sopra l'85%, degradando le prestazioni
Disco	> 80%	> 90%	Immagini Docker, log e database crescono silenziosamente. Al 100% i servizi crashano
Banda	> 80% del limite del piano	> 95%	Previene addebiti per eccesso o throttling

Queste soglie sono intenzionalmente più basse dei valori predefiniti enterprise. Su un piccolo VPS hai meno margine. Un picco dal 70% al 100% di CPU richiede secondi, non minuti.

Configurare SMTP per gli avvisi Beszel

Beszel usa PocketBase come backend. SMTP si configura tramite il pannello admin di PocketBase:

Vai su https://beszel.example.com/_/ (l'URL admin di PocketBase, nota l'underscore).
Accedi con le credenziali di amministratore create durante l'installazione.
Vai su Settings > Mail settings.
Abilita Use SMTP mail server.
Inserisci host SMTP, porta, nome utente e password.
Imposta l'indirizzo del mittente.
Clicca Save e Send test email.

Come creo una pagina di stato pubblica con Uptime Kuma?

Uptime Kuma può servire pagine di stato pubbliche che mostrano la disponibilità dei tuoi servizi. Sono utili per comunicare l'uptime agli utenti senza esporre la dashboard di monitoraggio.

Vai su Status Pages nella barra laterale sinistra.
Clicca New Status Page. Scegli un nome e uno slug (es. status).
Aggiungi gruppi (es. "Servizi Web", "API", "Infrastruttura").
Trascina i monitor in ogni gruppo.
Pubblica la pagina. È accessibile su https://status.example.com/status/<slug>.

Dominio personalizzato per la pagina di stato

Se vuoi che https://status.example.com serva direttamente la pagina di stato, impostala come predefinita nelle impostazioni di Uptime Kuma. Il percorso radice mostrerà la pagina pubblica mentre la dashboard resterà su /dashboard.

Le pagine di stato non richiedono autenticazione. Non mettere monitor in un gruppo della pagina di stato se rivelare l'esistenza dell'endpoint è una preoccupazione di sicurezza.

Gestione degli incidenti

Quando un servizio va giù, Uptime Kuma lo mostra automaticamente come degradato nella pagina di stato. Puoi anche creare incidenti manuali:

Vai su Status Pages, seleziona la tua pagina, clicca Create Incident.
Scrivi un titolo e una descrizione (es. "Manutenzione database, stimati 15 minuti").
Imposta lo stile su info, warning, danger o primary.
Pubblica. Il banner dell'incidente appare in cima alla pagina di stato pubblica.

Risolvi l'incidente quando è finito. Uptime Kuma mantiene uno storico degli incidenti passati così i tuoi utenti possono vedere il tuo track record operativo.

Come monitoro il mio stack di monitoraggio dall'esterno?

Se il tuo VPS va giù, Uptime Kuma e Beszel vanno giù con lui. Scopri il disservizio nello stesso momento dei tuoi utenti. La soluzione: un watchdog esterno che monitora la tua istanza Uptime Kuma da una posizione diversa.

Opzione 1: UptimeRobot (piano gratuito)

Crea un account gratuito su UptimeRobot.
Aggiungi un nuovo monitor: tipo HTTP(s), URL https://status.example.com/api/status-page/heartbeat/<slug>.
Imposta l'intervallo di controllo a 5 minuti.
Configura le notifiche email o Telegram.

L'endpoint /api/status-page/heartbeat/<slug> restituisce un payload JSON con lo stato. UptimeRobot lo controlla e ti avvisa se la tua istanza Uptime Kuma diventa irraggiungibile.

Opzione 2: Healthchecks.io (piano gratuito)

Healthchecks.io funziona con il modello push. Crea un check, copia l'URL di ping e aggiungi un cronjob sul tuo VPS:

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

Se il ping del cron smette di arrivare (perché il tuo server è giù), Healthchecks.io ti invia un avviso. Questo copre lo scenario in cui l'intero VPS diventa irraggiungibile.

Opzione 3: monitorare da un secondo VPS

Se gestisci più server, installa Uptime Kuma su un VPS diverso e fai in modo che ogni istanza monitori l'altra. Questo è l'approccio più affidabile perché controlli entrambi gli endpoint e non c'è dipendenza da un servizio gratuito di terze parti.

Hardening della sicurezza

Regole firewall

Se esegui l'agent Beszel in modalità standalone su un server remoto (senza usare il metodo del socket Unix), ascolta sulla porta 45876. Solo l'hub deve raggiungere questa porta:

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>

Non aprire la porta 45876 al mondo. L'agent espone metriche di sistema senza autenticazione su quella porta. Si affida alla chiave SSH dell'hub per la verifica, ma la restrizione a livello di rete aggiunge difesa in profondità.

Per la configurazione su singolo VPS di questa guida, la porta 45876 non è affatto necessaria perché hub e agent comunicano tramite socket Unix.

Uptime Kuma: disabilitare l'autenticazione con password per l'API

Se accedi a Uptime Kuma solo tramite l'interfaccia web, disabilita l'accesso API da Settings > Security > API Key. Meno endpoint esposti, meno cose da aggiornare.

Nascondere la versione

Uptime Kuma e Beszel espongono entrambi informazioni sulla versione nella loro interfaccia web per impostazione predefinita. Il tuo reverse proxy non dovrebbe aggiungere a questo problema. Nel tuo Caddyfile, Caddy omette già gli header Server per impostazione predefinita. Se usi Nginx:

server_tokens off;

La divulgazione della versione aiuta gli attaccanti a puntare a vulnerabilità note. Mantienila al minimo.

Come faccio il backup dei dati di Uptime Kuma e Beszel?

Entrambi gli strumenti usano database basati su SQLite. I file SQLite non possono essere copiati in sicurezza mentre l'applicazione ci scrive. Usa i metodi di backup appropriati.

Backup di Uptime Kuma

Uptime Kuma archivia tutto in /app/data (mappato su ./data nel file Compose). Il backup integrato esporta un file JSON:

Vai su Settings > Backup.
Clicca Export. Salva il file JSON fuori dal server.

Per backup automatizzati, ferma brevemente il container o usa il backup online di SQLite:

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

Backup di Beszel

Beszel usa PocketBase. Fai il backup della directory dati:

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

Conserva i backup fuori dal server. Uno stack di monitoraggio che perde il suo storico quando il disco muore non sta monitorando nulla. Backup e ripristino dei volumi Docker su un VPS

Come aggiorno Uptime Kuma e Beszel in sicurezza?

Fissa la versione minor, non latest. Questo impedisce che modifiche incompatibili arrivino senza il tuo consenso.

# 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

Controlla che la colonna STATUS mostri (healthy). Se la nuova versione causa problemi, fissa la versione precedente in compose.yaml e ricrea:

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

Lo stesso processo si applica a Beszel. Fai sempre il backup prima di aggiornare.

Strategia di pinning delle immagini

Il tag louislam/uptime-kuma:2 segue l'ultima release 2.x. È comodo ma significa che docker compose pull può saltare da 2.2.1 a 2.3.0 senza preavviso. In produzione, fissa una versione minor specifica:

image: louislam/uptime-kuma:2.2

Controlla le note di rilascio prima di fare pull. Uptime Kuma pubblica le release su GitHub. Beszel fa lo stesso sulla sua pagina di release.

Iscriviti alle notifiche di rilascio di entrambi i repository (Watch > Custom > Releases su GitHub) così sai quando escono le patch di sicurezza.

Limiti di risorse, healthcheck e politiche di riavvio in Docker Compose

Risoluzione dei problemi

Uptime Kuma mostra (unhealthy) in docker compose ps:

docker compose logs uptime-kuma --tail 50

Cause comuni: database SQLite corrotto (ripristina dal backup), conflitto di porta (un altro servizio su 3001), o memoria insufficiente (aumenta il limite di risorse).

L'agent Beszel non si connette all'hub:

docker compose logs beszel-agent --tail 50

Controlla che la KEY nel .env corrisponda alla chiave mostrata nella finestra Add System dell'hub. Se usi socket Unix, verifica che il percorso del volume condiviso corrisponda su entrambi i servizi.

Beszel non mostra le statistiche dei container Docker:

Il mount del socket Docker manca o il percorso del socket Docker è sbagliato. Controlla:

ls -la /var/run/docker.sock

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

Il socket deve esistere e il container deve avere accesso in lettura. Il mount :ro nel file Compose gestisce questo.

Le notifiche non arrivano:

Per SMTP: controlla che la porta 587 (o 465) in uscita non sia bloccata dal tuo provider di hosting. Alcuni provider bloccano l'SMTP in uscita per impostazione predefinita. Testa con:

nc -zv smtp.example.com 587

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

Per Telegram: verifica il token del bot e il chat ID. Il chat ID deve essere un numero, non il nome utente del bot.

Utilizzo di memoria elevato:

Il numero di monitor conta. Uptime Kuma v2.x usa circa 100 MB a riposo. Ogni monitor HTTP aggiunge stato di connessione. Se superi 100 monitor con un limite di memoria di 256 MB, aumenta il limite o distribuisci su più istanze.

Controlla l'utilizzo effettivo:

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

Rotazione dei log Docker: evitare che i log riempiano il disco del VPS

Self-hosting di Uptime Kuma e Beszel su un VPS con Docker Compose