Come auto-ospitare Uptime Kuma su un VPS

Puoi auto-ospitare Uptime Kuma su un VPS VoyraCloud selezionando l'immagine dell'applicazione preinstallata, creando il primo amministratore attraverso un tunnel SSH privato e poi aggiungendo monitor per i servizi che gestisci. L'immagine fornisce un punto di partenza persistente per Uptime Kuma, mentre l'accesso pubblico, HTTPS fidato, notifiche, backup, aggiornamenti, pianificazione della capacità e risposta agli incidenti rimangono sotto il tuo controllo.

TL;DR

L'immagine dell'applicazione VoyraCloud Uptime Kuma fornisce un cruscotto di monitoraggio preinstallato su Cloud VPS e Residential IP VPS.
La porta 3001 è legata a 127.0.0.1 per impostazione predefinita, quindi crea il primo amministratore attraverso un tunnel SSH invece di esporre una pagina di configurazione non inizializzata su Internet.
Uptime Kuma supporta monitor di tipo HTTP, HTTPS, TCP, ping, DNS, WebSocket, push, keyword e JSON, tra gli altri tipi di monitor documentati dal progetto.
L'accesso al cruscotto pubblico o alla pagina di stato richiede il tuo dominio, un reverse proxy che supporta gli aggiornamenti WebSocket e HTTPS fidato dal browser.
Configurazione, utenti, cronologia di monitoraggio, notifiche e pagine di stato sono memorizzati sotto /app/data su storage locale persistente. La persistenza al riavvio non è un backup.
Un carico di lavoro di 20 monitor, con intervallo di 60 secondi, è il profilo di validazione iniziale dell'immagine, non una garanzia di monitor illimitati o un sostituto per misurare il tuo carico di lavoro.
Il monitoraggio dallo stesso VPS ha un importante punto cieco: se quel VPS, la sua regione o il suo percorso di rete falliscono, Uptime Kuma potrebbe non essere in grado di inviare l'allerta.

Che cos'è Uptime Kuma?

Uptime Kuma è un'applicazione di monitoraggio open-source e auto-ospitata per controllare siti web, API, servizi di rete e altri endpoint raggiungibili da un cruscotto che controlli. Registra i risultati dei controlli e le informazioni di risposta, presenta la cronologia dei servizi e può inviare notifiche attraverso integrazioni configurate dall'amministratore.

L'progetto ufficiale di Uptime Kuma elenca il supporto per tipi di monitor come HTTP(S), TCP, keyword HTTP(S), query JSON HTTP(S), WebSocket, ping, record DNS, push e monitoraggio di container Docker. Fornisce anche più pagine di stato, informazioni sui certificati, grafici di ping, autenticazione a due fattori, supporto proxy e un'ampia gamma di integrazioni per le notifiche.

Auto-ospitare è utile quando desideri:

Un cruscotto di monitoraggio sotto la tua amministrazione del server.
Controllo sulla configurazione dei monitor, utenti, cronologia e pagine di stato.
Un modo semplice per controllare diversi siti web, API o servizi di rete.
L'opzione di connettere fornitori di notifiche che già utilizzi.
Uno strumento di monitoraggio che può funzionare continuamente su un piccolo VPS.

Uptime Kuma non è un servizio di monitoraggio gestito quando viene distribuito in questo modo. Possiedi il VPS, i controlli di accesso, gli aggiornamenti, le credenziali di notifica e il processo di risposta. Devi anche decidere se un'unica posizione di monitoraggio fornisce abbastanza visibilità per i servizi che ti interessano.

Come iniziare con l'immagine dell'applicazione VoyraCloud?

Il modo più veloce per auto-ospitare Uptime Kuma è creare un VPS VoyraCloud supportato con l'immagine dell'applicazione e completare la prima configurazione attraverso un tunnel SSH locale. Non è necessario installare manualmente Uptime Kuma, ma devi creare in modo sicuro l'amministratore prima di configurare i monitor.

Apri la pagina VoyraCloud per Uptime Kuma e continua con il flusso di acquisto del VPS.
Seleziona un piano Cloud VPS o Residential IP VPS idoneo, quindi scegli qualsiasi regione attualmente offerta da quel prodotto.
Conferma che Uptime Kuma sia selezionato nella sezione Immagini, quindi crea il VPS.
Attendi fino a quando le risorse e l'applicazione del VPS sono pronte.
Apri i dettagli della risorsa e individua la sezione Applicazione.
Copia il comando del tunnel SSH visualizzato. Segue questo modello:

ssh -p <ssh-port> -L 3001:127.0.0.1:3001 <ssh-user>@<server-ip>

7. Tieni aperta quella sessione SSH e naviga a:

http://127.0.0.1:3001

8. Completa la pagina di configurazione ufficiale di Uptime Kuma e crea un nome utente amministratore unico e una password forte.

9. Accedi, crea un monitor di prova e conferma che i controlli appaiano nel cruscotto.

10. Riavvia il VPS una volta e verifica che Uptime Kuma ritorni automaticamente e che l'account, il monitor e la cronologia rimangano disponibili.

L'indirizzo del browser è locale, ma l'applicazione gira sul VPS. SSH inoltra la tua porta locale 3001 attraverso una connessione crittografata a 127.0.0.1:3001 sul server. Chiudere la sessione SSH chiude il tunnel; non ferma Uptime Kuma.

Se il tuo computer utilizza già la porta locale 3001, scegli un'altra porta locale senza cambiare la destinazione remota:

ssh -p <ssh-port> -L 33001:127.0.0.1:3001 <ssh-user>@<server-ip>

Apriresti quindi http://127.0.0.1:33001 nel tuo browser. Mantieni il lato remoto come 127.0.0.1:3001.

Utilizza il nome utente SSH e la porta mostrati per la tua risorsa piuttosto che assumere root e porta 22.

Cosa include l'immagine dell'applicazione?

L'immagine dell'applicazione include un'istanza di Uptime Kuma preinstallata e persistente, ma non converte il VPS in un servizio di monitoraggio gestito. I seguenti confini sono importanti quando si pianifica l'uso in produzione.

Fornito dall'immagine dell'applicazione	Gestito dall'utente o non incluso
Versione stabile di Uptime Kuma approvata per l'immagine	Aggiornamenti automatici dell'applicazione
Ambiente operativo Cloud VPS o Residential IP VPS	Amministrazione del server gestita
Recupero del servizio dopo un riavvio normale del VPS	Alta disponibilità o failover automatico
Accesso solo locale su `127.0.0.1:3001`	Esposizione della porta pubblica `3001`
Flusso di configurazione del primo amministratore ufficiale	Amministratore precreato o password fissa
Storage locale persistente `/app/data`	Backup automatici off-server
Funzionalità del cruscotto di monitoraggio, cronologia, notifiche e pagine di stato	Account di notifica di terze parti preconfigurati
Istruzioni per il tunnel SSH nei dettagli della risorsa	Registrazione del dominio, reverse proxy o HTTPS fidato
Configurazione del monitor controllata dall'utente	Accuratezza di rilevamento garantita o consegna delle allerte
Uptime Kuma sotto la sua licenza open-source	Manutenzione di Uptime Kuma da parte di VoyraCloud dopo la consegna

L'immagine non include una credenziale di amministratore fissa, modalità senza autenticazione, segreti di notifica, un dominio, un certificato o un endpoint di gestione pubblico. Questo mantiene il primo accesso privato ed evita di posizionare una pagina di creazione account non inizializzata direttamente su Internet.

Quali tipi di monitor dovresti usare?

Scegli ogni tipo di monitor Uptime Kuma in base al livello che devi testare, perché un ping riuscito non prova che un sito web, API o applicazione funzioni correttamente. Un set di monitoraggio utile controlla il livello visibile all'utente e le dipendenze selezionate piuttosto che fare affidamento su un generico heartbeat.

Tipo di monitor	Cosa può verificare	Limitazione importante
HTTP o HTTPS	Un URL risponde e restituisce uno stato atteso	Una risposta riuscita può comunque contenere contenuti errati
Keyword	Una risposta include o esclude testo atteso	I controlli di testo non convalidano ogni funzione aziendale
JSON query	Una risposta API contiene un valore atteso	La query deve corrispondere alla struttura della risposta reale
Porta TCP	Un servizio di rete accetta una connessione	Una porta aperta non prova che l'applicazione sia sana
Ping	Un host risponde a ICMP	ICMP può essere filtrato e una risposta non prova che un'app funzioni
Record DNS	Un resolver restituisce il record atteso	Una vista del resolver potrebbe non rappresentare la propagazione globale
WebSocket	Un endpoint WebSocket può essere raggiunto	Non convalida ogni flusso di messaggi
Push	Un lavoro o processo remoto riporta il proprio heartbeat	Un push mancante necessita di una finestra di allerta progettata per quel lavoro
Informazioni sul certificato	Stato del certificato e informazioni sulla scadenza	Il rinnovo dipende ancora dal tuo processo di certificato

Per un sito web pubblico, un set pratico potrebbe includere un controllo HTTPS, un controllo keyword o JSON per contenuti significativi e un controllo di scadenza del certificato. Per un servizio interno raggiungibile dal VPS, un controllo TCP o HTTP può aggiungere visibilità all'infrastruttura. Per un lavoro programmato, un monitor push può rilevare quando l'heartbeat atteso non arriva.

Evita di creare diversi monitor che falliscono tutti per lo stesso motivo e poi trattarli come prove indipendenti. Il design del monitor dovrebbe riflettere i veri modi di fallimento: DNS, TLS, raggiungibilità di rete, risposta dell'applicazione, correttezza del contenuto e completamento dei lavori in background.

Cosa significa il profilo di validazione di 20 monitor?

Il profilo di 20 monitor è un carico di lavoro di accettazione conservativo per la configurazione iniziale dell'immagine, non una promessa di capacità massima. La validazione pianificata utilizza 20 monitor a intervalli di 60 secondi per 24 ore, seguita da un riavvio del VPS e un controllo di persistenza.

Quella validazione è intesa a rispondere a una domanda ristretta: può la configurazione di ingresso idonea eseguire una piccola installazione di Uptime Kuma senza eventi di esaurimento della memoria, blocco del database, riavvii imprevisti dei container o dati persi sotto un carico di lavoro definito? Non prova che lo stesso piano possa supportare:

Monitor illimitati.
Intervalli di controllo molto brevi.
Corpi di risposta grandi o query JSON costose.
Molti utenti contemporanei o visitatori di pagine di stato pubbliche.
Periodi di retention lunghi senza crescita dello storage.
Volume di notifiche elevato.
Monitoraggio Docker con accesso al socket host.
Ulteriori applicazioni che condividono lo stesso VPS.

Il reale utilizzo delle risorse dipende dal tipo di monitor, intervallo, timeout, dimensione della risposta, retention della cronologia, comportamento delle notifiche, attività del cruscotto e altro software sul server. Inizia con un set misurato, osserva l'uso della CPU, della memoria, del disco, il comportamento del database e la durata dei controlli, quindi passa a una configurazione VPS VoyraCloud più grande quando il reale carico di lavoro lo richiede.

Non interpretare il minimo del flusso di acquisto come una raccomandazione di dimensionamento universale. È un gate di idoneità per il profilo di partenza validato.

Come dovresti pubblicare Uptime Kuma in modo sicuro?

Pubblica Uptime Kuma attraverso un dominio o sottodominio dedicato, un reverse proxy capace di WebSocket e HTTPS fidato dal browser mantenendo la porta 3001 legata a localhost. L'accesso a lungo termine tramite tunnel SSH è anche valido quando solo gli amministratori necessitano del cruscotto e non è necessaria alcuna pagina di stato pubblica.

La guida al reverse proxy di Uptime Kuma spiega che l'applicazione utilizza WebSocket e richiede al proxy di passare gli header Upgrade e Connection. Nota anche che Uptime Kuma non supporta di essere ospitato sotto un normale sottodirectory URL come /uptime-kuma; utilizza un hostname dedicato come status.example.com.

Un tipico blocco di posizione Nginx include:

location / {
    proxy_pass http://127.0.0.1:3001;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Questo frammento copre solo il percorso del proxy. Devi configurare separatamente l'hostname, il certificato TLS fidato, il rinnovo del certificato, il reindirizzamento da HTTP a HTTPS, il firewall e la politica di accesso. Verifica l'esempio ufficiale attuale per il tuo reverse proxy scelto prima di applicarlo.

Utilizza questa checklist di produzione:

Crea un record DNS per un hostname dedicato.
Mantieni 3001/tcp non disponibile da Internet pubblico.
Configura il reverse proxy per raggiungere 127.0.0.1:3001.
Preserva gli header di aggiornamento WebSocket.
Installa un certificato fidato dai normali browser.
Reindirizza HTTP semplice a HTTPS.
Conferma che il cruscotto si aggiorni senza errori WebSocket.
Testa l'accesso, il logout, gli aggiornamenti dei monitor e le pagine di stato.
Limita l'hostname di amministrazione quando l'accesso pubblico non è necessario.
Rivedi le impostazioni del proxy fidato solo dopo che il percorso del proxy e del firewall è corretto.

HTTPS fidato protegge le credenziali e il traffico di sessione in transito, ma non protegge una password di amministratore debole o un server obsoleto. Mantieni SSH rinforzato, limita i privilegi, abilita l'autenticazione a due fattori dove appropriato e mantieni il sistema operativo e il reverse proxy.

Come funzionano le notifiche e le pagine di stato?

Le notifiche e le pagine di stato sono funzionalità che configuri dopo l'inizializzazione; l'immagine non include account di terze parti, credenziali, garanzie di consegna o un dominio pubblico. Uptime Kuma supporta molti metodi di notifica, ma ogni fornitore ha il proprio account, disponibilità, prezzi, limiti e comportamento di consegna.

La documentazione sui metodi di notifica ufficiali fornisce riferimenti di configurazione specifici per fornitore. Aggiungi solo integrazioni di cui il tuo team è proprietario, conserva le credenziali con attenzione e invia una notifica di test prima di fare affidamento su di esse. Un test riuscito prova che un messaggio ha funzionato in quel momento; non garantisce la consegna futura.

Per ogni monitor importante:

Decidi chi dovrebbe ricevere un'allerta.
Imposta un intervallo di controllo e una politica di ripetizione che si adatti al servizio.
Configura uno o più metodi di notifica di proprietà dell'utente.
Testa le notifiche di fallimento e recupero.
Conferma che una persona di guardia possa agire sul messaggio.
Documenta cosa fare quando il monitor riporta un fallimento.

Le pagine di stato ti consentono di condividere stati di monitor selezionati e informazioni sugli incidenti. Non è necessario esporre ogni monitor interno. Raggruppa i servizi in un modo che i clienti comprendano, evita di pubblicare nomi host sensibili o topologie interne e utilizza il tuo dominio e percorso proxy sicuro per l'accesso pubblico.

Non assumere che ogni integrazione di notifica sia gratuita. Alcuni servizi potrebbero addebitare, limitare l'uso, cambiare le loro API o richiedere configurazioni aggiuntive. VoyraCloud non fornisce quegli account di terze parti e non può garantire che un fornitore accetti o consegni un messaggio.

Come vengono memorizzati e backup i dati di Uptime Kuma?

Uptime Kuma mantiene il suo stato applicativo sotto /app/data, che deve rimanere su storage locale persistente e deve essere backupato separatamente dal VPS in esecuzione. Le linee guida ufficiali per l'installazione richiedono supporto del filesystem per i blocchi di file POSIX e avvertono contro problemi di blocco dei file comunemente associati a NFS.

I dati persistenti includono il database e lo stato dell'applicazione necessari per elementi come:

Impostazioni di amministratore e utente.
Definizioni dei monitor.
Cronologia di monitoraggio.
Configurazione delle notifiche.
Pagine di stato.
Programmi di manutenzione.
Altre impostazioni dell'istanza.

Un normale riavvio del VPS dovrebbe preservare quei dati e riavviare l'applicazione. Quel comportamento è persistenza, non recupero da disastri. Cancellazioni accidentali, corruzione del database, credenziali compromesse, un aggiornamento fallito, perdita di storage o cancellazione del VPS possono comunque rimuovere l'unica copia.

Una routine di backup più sicura è:

Identificare il volume Docker locale effettivo o la directory locale mappata a /app/data.
Pianificare backup a una destinazione al di fuori del VPS.
Quiescere o fermare Uptime Kuma quando il metodo di backup scelto richiede una copia del database coerente.
Copiare l'intero set di dati, non solo un elenco di monitor esportato.
Crittografare e proteggere il backup perché può contenere dettagli operativi e credenziali di notifica.
Conservare più di un punto di recupero.
Ripristinare a un'istanza di test separata e verificare account, monitor, cronologia, notifiche e pagine di stato.
Registrare la versione dell'applicazione associata al backup.

Non posizionare la directory live /app/data su NFS per questa immagine. Una destinazione di backup remota è appropriata per gli artefatti di backup copiati; è diversa dall'esecuzione del database attivo direttamente su un filesystem di rete.

Qual è il punto cieco del monitoraggio sullo stesso server?

Un'istanza di Uptime Kuma non può segnalare in modo affidabile i fallimenti che rimuovono anche il proprio percorso di calcolo, rete o notifica. Se Uptime Kuma gira sullo stesso VPS del sito web che monitora, un'interruzione del VPS può fermare sia il sito web che il monitor prima che l'allerta venga inviata.

Anche quando il servizio monitorato è su un altro server, una posizione di Uptime Kuma osserva comunque da una rete e una regione. Un percorso ISP locale, un problema di rete regionale, una differenza nel resolver DNS o una politica di firewall possono influenzare quella vista senza rappresentare l'esperienza di ogni utente.

Utilizza il deployment in base alla conseguenza:

Esigenza di monitoraggio	Approccio appropriato
Cruscotto conveniente per piccoli servizi	Un'istanza di Uptime Kuma auto-ospitata può essere sufficiente
Monitorare un servizio su un altro VPS	Posizionare Uptime Kuma al di fuori del dominio di guasto del server monitorato quando pratico
Rilevare differenze di raggiungibilità regionale	Utilizzare controlli indipendenti da più posizioni
Allerta durante il guasto del VPS di monitoraggio	Aggiungere un heartbeat esterno o un servizio di monitoraggio indipendente
Monitoraggio ad alta disponibilità	Progettare un'architettura di monitoraggio multi-sistema separata

L'immagine dell'applicazione non fornisce monitoraggio distribuito, alta disponibilità o un controllore esterno indipendente. Trattala come un punto di monitoraggio e aggiungi copertura indipendente quando allerte perse avrebbero un significativo impatto commerciale.

Come dovresti aggiornare Uptime Kuma?

Aggiorna Uptime Kuma deliberatamente controllando le linee guida ufficiali per il rilascio, eseguendo il backup di /app/data e convalidando la nuova versione prima di fare affidamento su di essa. VoyraCloud non aggiorna automaticamente le istanze dei clienti dopo la creazione del VPS.

Segui le linee guida ufficiali per l'aggiornamento di Uptime Kuma che si applicano alla versione principale installata e al metodo di distribuzione. Prima di un aggiornamento:

Leggi le note di rilascio e i requisiti di migrazione.
Registra la versione dell'applicazione attualmente in esecuzione.
Crea e verifica un backup off-server di /app/data.
Conferma spazio libero su disco sufficiente.
Pianifica una finestra di manutenzione per un'importante istanza di monitoraggio.
Utilizza una versione specifica approvata piuttosto che un tag fluttuante non revisionato.
Avvia l'istanza aggiornata e controlla i suoi log.
Testa l'accesso dell'amministratore, diversi tipi di monitor, una notifica, una pagina di stato e il recupero dal riavvio.
Mantieni un piano di rollback compatibile con le modifiche al database descritte dal rilascio.

Non assumere che il ripristino dell'immagine del container sia sempre sufficiente. Una migrazione di versione principale può cambiare i dati dell'applicazione, quindi il recupero può richiedere il backup dei dati pre-aggiornamento così come la versione precedente dell'immagine.

Gli aggiornamenti del sistema operativo, gli aggiornamenti di Docker, gli aggiornamenti del reverse proxy e il rinnovo del certificato sono responsabilità separate. Un container Uptime Kuma attuale non rende il resto del server attuale.

Errori comuni da evitare

La maggior parte degli errori di distribuzione di Uptime Kuma deriva dall'esporre l'inizializzazione, sovrastimare una posizione di monitoraggio o trattare lo storage persistente come un piano operativo completo. Evita questi errori:

Pubblicare la porta 3001 prima di creare l'amministratore. Mantienila su localhost e utilizza il tunnel SSH.
Lasciare il cruscotto su HTTP pubblico. Utilizza HTTPS fidato per qualsiasi accesso pubblico.
Dimenticare gli header del proxy WebSocket. L'interfaccia potrebbe caricarsi ma non aggiornarsi correttamente.
Ospitare sotto un sottodirectory. Utilizza un dominio o sottodominio dedicato.
Eseguire /app/data attivo su NFS. Mantienilo su storage locale compatibile.
Chiamare la persistenza al riavvio un backup. Conserva copie testate al di fuori del VPS.
Assumere che una pagina di stato crei monitoraggio indipendente. È presentata dalla stessa istanza di Uptime Kuma.
Monitorare un VPS solo da se stesso. Un guasto completo del server può silenziare sia il servizio che il suo monitor.
Trattare 20 monitor come un massimo o minimo garantito. È un carico di lavoro di validazione definito, non un risultato di capacità universale.
Aspettarsi che la consegna delle notifiche sia garantita. La disponibilità del fornitore, le credenziali, le quote, il routing e l'host di monitoraggio sono tutti importanti.
Abilitare ogni integrazione senza un proprietario. Configura solo i canali che qualcuno testa e a cui risponde.
Aggiornare senza una copia di dati ripristinabile. Esegui il backup dell'intero set di dati dell'applicazione prima di cambiare versione.

FAQ

Posso auto-ospitare Uptime Kuma senza installarlo manualmente?

Sì. L'immagine dell'applicazione VoyraCloud fornisce un'istanza di Uptime Kuma preinstallata su un Cloud VPS o Residential IP VPS idoneo. Devi comunque creare il primo amministratore, aggiungere monitor, configurare notifiche e gestire sicurezza, aggiornamenti, backup e accesso pubblico.

Perché viene mostrato `http://127.0.0.1:3001` invece dell'IP del server?

L'indirizzo locale impedisce che la pagina di configurazione dell'amministratore non inizializzata venga esposta direttamente su Internet. Stabilire il tunnel SSH dal tuo computer, mantenere la sessione aperta e poi navigare all'URL locale. Il tunnel inoltra in modo sicuro la tua connessione del browser a Uptime Kuma sul VPS.

Posso esporre la porta `3001` direttamente su Internet?

L'esposizione diretta non è il percorso di produzione raccomandato. Mantieni il servizio legato a localhost e utilizza un reverse proxy con un hostname dedicato, supporto WebSocket, HTTPS fidato e una politica di accesso appropriata. L'immagine dell'applicazione non configura automaticamente quel percorso pubblico.

Uptime Kuma include servizi di notifica SMS, email, Slack o altri gratuiti?

No. Uptime Kuma può integrarsi con molti fornitori di notifica, ma tu fornisci e gestisci l'account e le credenziali del fornitore. Prezzi di terze parti, quote, disponibilità e consegna dei messaggi sono al di fuori dell'immagine dell'applicazione e possono cambiare.

Un VPS da 1 GB è sufficiente per Uptime Kuma?

Potrebbe essere un punto di partenza idoneo solo dopo che la validazione dell'immagine definita è superata, ma la reale capacità dipende dal tuo carico di lavoro. Il profilo iniziale utilizza 20 monitor a intervalli di 60 secondi per 24 ore. Più monitor, intervalli più brevi, risposte più grandi, cronologia più lunga, servizi extra o un uso più intenso del cruscotto potrebbero richiedere più memoria, CPU e storage.

Uptime Kuma fornisce alta disponibilità o monitoraggio esterno?

No. Questa immagine fornisce un'istanza di Uptime Kuma auto-ospitata su un VPS. Alta disponibilità, controlli distribuiti e monitoraggio esterno indipendente richiedono sistemi e architetture aggiuntive che non sono inclusi.

Uptime Kuma mi avviserà se il suo stesso VPS fallisce?

Potrebbe non farlo, perché il processo che invia l'allerta può fallire con il VPS o il suo percorso di rete. Utilizza un heartbeat esterno o una posizione di monitoraggio indipendente quando è importante rilevare il fallimento dell'host di Uptime Kuma.

Cosa devo backupare?

Esegui il backup dell'intero set di dati persistenti mappato a /app/data e conserva la copia di recupero al di fuori del VPS. Proteggi il backup perché può contenere configurazioni di monitoraggio e segreti di notifica, e testa un ripristino invece di assumere che un set di file copiato sia utilizzabile.

VoyraCloud aggiorna automaticamente Uptime Kuma?

No. Le nuove risorse VPS ricevono la versione dell'applicazione approvata per l'immagine al momento della creazione, mentre gli aggiornamenti successivi sono gestiti dal cliente. Rivedi le istruzioni ufficiali per l'aggiornamento, esegui il backup di /app/data e testa l'istanza aggiornata prima di fare affidamento su di essa.

Conclusione

Auto-ospita Uptime Kuma quando desideri un cruscotto di monitoraggio semplice, controlli configurabili, notifiche e pagine di stato sotto la tua amministrazione. Inizia privatamente attraverso il tunnel SSH, progetta monitor attorno a veri modi di fallimento, mantieni /app/data su storage locale persistente, esegui il backup al di fuori del VPS e aggiungi un reverse proxy capace di WebSocket con HTTPS fidato solo quando è richiesto l'accesso pubblico.

Un'istanza è utile per molte piccole esigenze di monitoraggio, ma rimane un punto di osservazione con un dominio di guasto. Aggiungi monitoraggio indipendente quando l'host di Uptime Kuma stesso, la raggiungibilità regionale o la continuità delle allerte devono essere coperte.

Utilizza l'immagine dell'applicazione VoyraCloud per Uptime Kuma per iniziare da un ambiente VPS VoyraCloud preinstallato mantenendo accesso, dati, notifiche e operazioni sotto il tuo controllo.