Come fare il self-hosting di Beszel nel 2026: agent, rete privata e backup

La demo più semplice di Beszel dimostra che un processo è in ascolto sulla porta 8090. In produzione servono prove più solide. Questo scenario deve funzionare anche dopo la sostituzione del container: registrare un agent, visualizzare i grafici di CPU, memoria e disco, attivare un alert al superamento di una soglia e riconnettere l'agent dopo il riavvio di un hub.

Beszel viene distribuito per uno scopo preciso: monitorare server in modo leggero all'interno di un container di piccole dimensioni. Il problema di deployment più comune è che l'hub non riesca a raggiungere la porta 45876 su un agent o che la relativa chiave SSH sia cambiata; per questo la gestione dell'URL pubblico e dello stato persistente devono ricevere la stessa attenzione dell'avvio dell'immagine.

Definire i confini di runtime di Beszel

Per Beszel, lo stato del processo e lo stato del prodotto sono due aspetti distinti. La porta 8090 può rispondere mentre la transazione lato utente continua a non funzionare. Il contratto di rete di Beszel prevede un agent Beszel su ogni macchina monitorata. Mantieni gli endpoint privati su DNS interno, consenti solo le chiamate outbound necessarie e assegna a Beszel una credenziale di servizio con permessi limitati.

Esegui questo test di readiness dopo modifiche significative alla configurazione: registra un agent, visualizza i grafici di CPU, memoria e disco, attiva un alert al superamento di una soglia e riconnetti l'agent dopo il riavvio di un hub. Evita di inserire controlli esterni costosi nelle probe di liveness, così un'interruzione del provider non causa un restart loop. Il lavoro sulla capacità deve tenere traccia del numero di agent, della retention delle metriche, dello storage dell'hub e della raggiungibilità di rete di ogni agent sulla propria porta dedicata: aspetti più vicini alla reale pressione su Beszel rispetto alle richieste alle pagine.

Rendere inequivocabile l'origine pubblica

Browser, client API e Beszel devono concordare su un'unica origine. Per ottenere questo risultato, instrada l'hub tramite HTTPS e mantieni private le porte degli agent. Conserva l'host e il protocollo originali, impedendo al contempo che la porta 8090 sia disponibile come indirizzo pubblico alternativo.

La guida alla risoluzione dei problemi relativi a un sito non raggiungibile aiuta a distinguere una route irraggiungibile da un'applicazione che risponde. Questa distinzione è importante: l'hub non riesce a raggiungere la porta 45876 su un agent oppure la relativa chiave SSH è cambiata. Solo il primo problema si risolve modificando l'ingress; il secondo richiede l'analisi dei log, dello stato o del workload di Beszel.

Eseguire la prima istanza simile a quella di produzione

Il primo container deve poter essere eliminato e ricreato facilmente. Mantieni i dati fuori dal writable layer, associa la porta 8090 solo dove il proxy può raggiungerla e passa la configurazione a runtime.

docker run -d \
  --name beszel \
  --restart unless-stopped \
  -p 127.0.0.1:8090:8090 \
  -v beszel-data:/beszel_data \
  henrygd/beszel:latest

Dopo il test iniziale, blocca la versione dell'immagine. Leggi il primo errore di avvio invece dell'ultimo messaggio di riavvio, verifica ogni mount con docker inspect e segui i log mentre registri un agent, visualizzi i grafici di CPU, memoria e disco, attivi un alert al superamento di una soglia e riconnetti l'agent dopo il riavvio di un hub. Questa sequenza distingue un comando errato dell'immagine da un problema di dipendenze o permessi.

Log che aiutano a rispondere alla domanda successiva

Un container in stato green è necessario, ma non sufficiente. Lo service-level indicator è il completamento riuscito di “registrare un agent, visualizzare i grafici di CPU, memoria e disco, attivare un alert al superamento di una soglia e riconnettere l'agent dopo il riavvio di un hub”, mentre i principali segnali di pressione sono il numero di agent, la retention delle metriche, lo storage dell'hub e la raggiungibilità di rete di ogni agent sulla propria porta dedicata.

Il change control è importante perché le versioni di hub e agent devono essere testate insieme: le modifiche al protocollo possono apparire come lacune di monitoraggio silenziose. Conserva la vecchia immagine, testa le migrazioni su una copia dello stato e documenta se il rollback è supportato dopo la modifica dello schema. Se l'hub non riesce a raggiungere la porta 45876 su un agent oppure la relativa chiave SSH è cambiata, analizza il primo confine che differisce dall'ambiente funzionante.

Un acceptance test di produzione per Beszel

Prima dell'arrivo degli utenti reali, prepara una release worksheet per Beszel. Deve indicare l'immagine con versione bloccata, la porta 8090, l'origine canonica, i percorsi persistenti e il responsabile di un agent Beszel su ogni macchina monitorata. Allega il risultato atteso di questa transazione: registrare un agent, visualizzare i grafici di CPU, memoria e disco, attivare un alert al superamento di una soglia e riconnettere l'agent dopo il riavvio di un hub.

Usa la worksheet dopo una sostituzione normale e dopo un ripristino pulito. Il recovery è accettato solo se sistemi, cronologia e alert tornano disponibili e ogni agent ripristinato riprende a inviare metriche aggiornate. Raccogli anche una breve traccia delle risorse che copra il numero di agent, la retention delle metriche, lo storage dell'hub e la raggiungibilità di rete di ogni agent sulla propria porta dedicata; conservala insieme alla release, così i futuri cambiamenti di capacità potranno essere confrontati con lo stesso workload.

Includi un failure test controllato: nega temporaneamente all'identità di test l'accesso a un agent Beszel su ogni macchina monitorata. Verifica che Beszel segnali il problema al confine corretto, ripristina la condizione valida ed esegui nuovamente la transazione. In questo modo verifichi la visibilità degli errori, non solo il successo, evitando che un'interfaccia apparentemente sana nasconda un worker, una callback o una connessione al database non funzionante.

Progettare il ripristino di Beszel prima del lancio

Fai l'inventario di ogni artefatto durevole: dati dell'hub, utenti, sistemi e configurazione degli alert. Monta /beszel_data prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che quel percorso è effettivamente persistente. Includi anche la configurazione che modifica il modo in cui i dati memorizzati vengono interpretati, non solo la directory più grande.

Imposta la retention, copia i backup fuori dall'host ed esegui un ripristino in un ambiente clean-room. Il test di Beszel è completo quando sistemi, cronologia e alert tornano disponibili e ogni agent ripristinato riprende a inviare metriche aggiornate. Se i snapshot fanno parte del piano, usa le indicazioni su PITR e snapshot per documentare cosa può recuperare ciascun meccanismo.

Chiudere gli accessi temporanei di configurazione

Definisci il threat model dell'azione eseguita da Beszel, non solo della sua pagina di login. In questo caso, l'errore ad alto rischio consiste nel pubblicare su Internet i listener degli agent senza network control. Implementa questo confine: mantieni i listener degli agent su reti private e proteggi l'account dell'hub e le chiavi di enrollment.

In questa configurazione di base Beszel non richiede un secret di bootstrap obbligatorio; proteggi invece il suo account amministratore effettivo o l'autenticazione upstream. Non risolvere un errore di permessi eseguendo il container come root o montando liberamente l'host. Anche i resource limit fanno parte del security design, perché il numero di agent, la retention delle metriche, lo storage dell'hub e la raggiungibilità di rete di ogni agent sulla propria porta dedicata possono essere influenzati dagli utenti.

Spostare il lavoro infrastrutturale ripetibile su Dockup

Per Beszel, Dockup è particolarmente utile al confine tra un'immagine e un servizio durevole. Mantiene associati route verso la porta 8090, TLS, valori dei secret e storage durante le sostituzioni dei container, indipendentemente dal fatto che il compute appartenga a Dockup o al server collegato.

Concludi con le attività specifiche dell'applicazione: instrada l'hub tramite HTTPS e mantieni private le porte degli agent; collega e testa un agent Beszel su ogni macchina monitorata; quindi esegui questa verifica: registra un agent, visualizza i grafici di CPU, memoria e disco, attiva un alert al superamento di una soglia e riconnetti l'agent dopo il riavvio di un hub. Conserva il risultato come deployment check, così il prossimo aggiornamento dell'immagine verrà valutato in base al comportamento e non allo stato del container.

Domande frequenti

Cosa serve a Beszel per un deployment in produzione?

Instrada il container Beszel sulla porta 8090 attraverso un'unica origine HTTPS. Il requisito di rete complementare è un agent Beszel su ogni macchina monitorata. Non considerare Beszel pronto finché non puoi registrare un agent, visualizzare i grafici di CPU, memoria e disco, attivare un alert al superamento di una soglia e riconnettere l'agent dopo il riavvio di un hub.

Quali dati di Beszel devono essere inclusi in un backup?

Rendi persistente /beszel_data e includi dati dell'hub, utenti, sistemi e configurazione degli alert nello stesso recovery manifest. Un ripristino pulito di Beszel è riuscito solo quando sistemi, cronologia e alert tornano disponibili e ogni agent ripristinato riprende a inviare metriche aggiornate.

Beszel richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origine pubblica di Beszel e mantieni la porta 8090 sulla route interna. Applica correttamente la configurazione di Beszel: instrada l'hub tramite HTTPS e mantieni private le porte degli agent. Per Beszel, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento del client sensibile all'origine.

Come testare un upgrade di Beszel?

Ripristina lo stato attuale di Beszel in un deployment isolato, applica la versione candidata e ripeti la relativa acceptance transaction. Presta particolare attenzione al fatto che le versioni di hub e agent devono essere testate insieme: le modifiche al protocollo possono apparire come lacune di monitoraggio silenziose. Conserva la precedente immagine di Beszel finché non avrai compreso i confini della migrazione dei dati e del rollback.