Comment auto-héberger Uptime Kuma sur un VPS

Vous pouvez auto-héberger Uptime Kuma sur un VPS VoyraCloud en sélectionnant l'image d'application préinstallée, en créant le premier administrateur via un tunnel SSH privé, puis en ajoutant des moniteurs pour les services que vous exploitez. L'image fournit un point de départ Uptime Kuma persistant, tandis que l'accès public, HTTPS de confiance, les notifications, les sauvegardes, les mises à jour, la planification de capacité et la réponse aux incidents restent sous votre contrôle.

TL;DR

L'image d'application VoyraCloud Uptime Kuma fournit un tableau de bord de surveillance préinstallé sur Cloud VPS et Residential IP VPS.
Le port 3001 est lié à 127.0.0.1 par défaut, donc créez le premier administrateur via un tunnel SSH au lieu d'exposer une page de configuration non initialisée à Internet.
Uptime Kuma prend en charge les moniteurs HTTP, HTTPS, TCP, ping, DNS, WebSocket, push, mot-clé et requête JSON, parmi d'autres types de moniteurs documentés par le projet.
L'accès au tableau de bord public ou à la page d'état nécessite votre propre domaine, un proxy inverse qui prend en charge les mises à niveau WebSocket et HTTPS de confiance pour le navigateur.
La configuration, les utilisateurs, l'historique de surveillance, les notifications et les pages d'état sont stockés sous /app/data sur un stockage local persistant. La persistance après redémarrage n'est pas une sauvegarde.
Une charge de travail de 20 moniteurs, avec un intervalle de 60 secondes, est le profil de validation initial de l'image, et non une garantie de moniteurs illimités ou un substitut pour mesurer votre propre charge de travail.
La surveillance depuis le même VPS présente un point aveugle important : si ce VPS, sa région ou son chemin réseau échoue, Uptime Kuma peut ne pas être en mesure d'envoyer l'alerte.

Qu'est-ce qu'Uptime Kuma ?

Uptime Kuma est une application de surveillance open-source et auto-hébergée pour vérifier les sites web, les API, les services réseau et d'autres points de terminaison accessibles depuis un tableau de bord que vous contrôlez. Elle enregistre les résultats des vérifications et les informations de réponse, présente l'historique des services et peut envoyer des notifications via des intégrations configurées par l'administrateur.

Le projet officiel Uptime Kuma liste le support pour des types de moniteurs tels que HTTP(S), TCP, mot-clé HTTP(S), requête JSON HTTP(S), WebSocket, ping, enregistrement DNS, push et surveillance de conteneurs Docker. Il fournit également plusieurs pages d'état, des informations sur les certificats, des graphiques de ping, une authentification à deux facteurs, un support proxy et une large gamme d'intégrations de notifications.

L'auto-hébergement est utile lorsque vous souhaitez :

Un tableau de bord de surveillance sous votre propre administration de serveur.
Un contrôle sur la configuration des moniteurs, les utilisateurs, l'historique et les pages d'état.
Une manière simple de vérifier plusieurs sites web, API ou services réseau.
L'option de connecter des fournisseurs de notifications que vous utilisez déjà.
Un outil de surveillance qui peut fonctionner en continu sur un petit VPS.

Uptime Kuma n'est pas un service de surveillance géré lorsqu'il est déployé de cette manière. Vous possédez le VPS, les contrôles d'accès, les mises à jour, les sauvegardes, les informations d'identification de notification et le processus de réponse. Vous devez également décider si un emplacement de surveillance fournit suffisamment de visibilité pour les services qui vous importent.

Comment commencer avec l'image d'application VoyraCloud ?

Le moyen le plus rapide d'auto-héberger Uptime Kuma est de créer un VPS VoyraCloud pris en charge avec l'image d'application et de compléter la première configuration via un tunnel SSH local. Vous n'avez pas besoin d'installer Uptime Kuma manuellement, mais vous devez créer l'administrateur de manière sécurisée avant de configurer les moniteurs.

Ouvrez la page VoyraCloud pour Uptime Kuma et continuez jusqu'au processus d'achat de VPS.
Sélectionnez un plan Cloud VPS ou Residential IP VPS éligible, puis choisissez une région actuellement offerte par ce produit.
Confirmez qu'Uptime Kuma est sélectionné dans la section Images, puis créez le VPS.
Attendez que la ressource VPS et l'application soient prêtes.
Ouvrez les détails de la ressource et localisez la section Application.
Copiez la commande de tunnel SSH affichée. Elle suit ce modèle :

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

7. Gardez cette session SSH ouverte et naviguez vers :

http://127.0.0.1:3001

8. Complétez la page de configuration officielle d'Uptime Kuma et créez un nom d'utilisateur administrateur unique et un mot de passe fort.

9. Connectez-vous, créez un moniteur de test et confirmez que les vérifications apparaissent dans le tableau de bord.

10. Redémarrez le VPS une fois et vérifiez qu'Uptime Kuma redémarre automatiquement et que le compte, le moniteur et l'historique restent disponibles.

L'adresse du navigateur est locale, mais l'application fonctionne sur le VPS. SSH redirige votre port local 3001 à travers une connexion cryptée vers 127.0.0.1:3001 sur le serveur. Fermer la session SSH ferme le tunnel ; cela n'arrête pas Uptime Kuma.

Si votre ordinateur utilise déjà le port local 3001, choisissez un autre port local sans changer la destination distante :

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

Vous ouvririez alors http://127.0.0.1:33001 dans votre navigateur. Gardez le côté distant comme 127.0.0.1:3001.

Utilisez le nom d'utilisateur SSH et le port indiqués pour votre propre ressource plutôt que de supposer root et le port 22.

Que comprend l'image d'application ?

L'image d'application comprend une instance Uptime Kuma préinstallée et persistante, mais elle ne transforme pas le VPS en un service de surveillance géré. La frontière suivante est importante lors de la planification d'une utilisation en production.

Livré par l'image d'application	Géré par l'utilisateur ou non inclus
Version stable d'Uptime Kuma approuvée pour l'image	Mises à jour automatiques de l'application
Environnement d'exploitation Cloud VPS ou Residential IP VPS	Administration de serveur gérée
Récupération de service après un redémarrage normal du VPS	Haute disponibilité ou basculement automatique
Accès local uniquement sur `127.0.0.1:3001`	Exposition du port public `3001`
Flux de configuration du premier administrateur officiel	Administrateur précréé ou mot de passe fixe
Stockage local persistant `/app/data`	Sauvegardes automatiques hors serveur
Tableau de bord de surveillance, historique, notifications et fonctionnalités de page d'état	Comptes de notification tiers préconfigurés
Instructions de tunnel SSH dans les détails de la ressource	Enregistrement de domaine, proxy inverse ou HTTPS de confiance
Configuration de moniteur contrôlée par l'utilisateur	Précision de détection garantie ou livraison d'alerte
Uptime Kuma sous sa licence open-source	Maintenance de Uptime Kuma par VoyraCloud après livraison

L'image n'inclut pas d'identifiant administrateur fixe, de mode sans authentification, de secrets de notification, de domaine, de certificat ou d'un point de gestion public. Cela garde le premier accès privé et évite de placer une page de création de compte non initialisée directement sur Internet.

Quels types de moniteurs devriez-vous utiliser ?

Choisissez chaque type de moniteur Uptime Kuma en fonction de la couche que vous devez tester, car un ping réussi ne prouve pas qu'un site web, une API ou une application fonctionne correctement. Un ensemble de surveillance utile vérifie la couche orientée utilisateur et les dépendances sélectionnées plutôt que de se fier à un seul heartbeat générique.

Type de moniteur	Ce qu'il peut vérifier	Limitation importante
HTTP ou HTTPS	Une URL répond et renvoie un statut attendu	Une réponse réussie peut encore contenir un contenu incorrect
Mot-clé	Une réponse inclut ou exclut un texte attendu	Les vérifications de texte ne valident pas chaque fonction commerciale
Requête JSON	Une réponse API contient une valeur attendue	La requête doit correspondre à la structure de réponse réelle
Port TCP	Un service réseau accepte une connexion	Un port ouvert ne prouve pas que l'application est saine
Ping	Un hôte répond à ICMP	ICMP peut être filtré, et une réponse ne prouve pas qu'une application fonctionne
Enregistrement DNS	Un résolveur renvoie l'enregistrement attendu	Une vue de résolveur peut ne pas représenter la propagation mondiale
WebSocket	Un point de terminaison WebSocket peut être atteint	Il ne valide pas chaque flux de message
Push	Un travail ou un processus distant signale son propre heartbeat	Un push manquant nécessite une fenêtre d'alerte conçue pour ce travail
Informations sur le certificat	État du certificat et informations sur l'expiration	Le renouvellement dépend toujours de votre processus de certificat

Pour un site web public, un ensemble pratique pourrait inclure une vérification HTTPS, une vérification de mot-clé ou JSON pour un contenu significatif, et une vérification d'expiration de certificat. Pour un service interne accessible depuis le VPS, une vérification TCP ou HTTP peut ajouter de la visibilité à l'infrastructure. Pour un travail programmé, un moniteur push peut détecter quand le heartbeat attendu n'arrive pas.

Évitez de créer plusieurs moniteurs qui échouent tous pour la même raison et de les traiter ensuite comme des preuves indépendantes. La conception des moniteurs doit refléter les modes d'échec réels : DNS, TLS, accessibilité réseau, réponse d'application, exactitude du contenu et achèvement des travaux en arrière-plan.

Que signifie le profil de validation de 20 moniteurs ?

Le profil de 20 moniteurs est une charge de travail d'acceptation conservatrice pour la configuration initiale de l'image, pas une promesse de capacité maximale. La validation prévue utilise 20 moniteurs à des intervalles de 60 secondes pendant 24 heures, suivie d'un redémarrage du VPS et d'une vérification de persistance.

Cette validation vise à répondre à une question étroite : la configuration d'entrée éligible peut-elle exécuter une petite installation Uptime Kuma sans événements de mémoire insuffisante, blocage de base de données, redémarrages de conteneurs inattendus ou perte de données sous une charge de travail définie ? Cela ne prouve pas que le même plan peut supporter :

Des moniteurs illimités.
Des intervalles de vérification très courts.
De grands corps de réponse ou des requêtes JSON coûteuses.
De nombreux utilisateurs simultanés ou visiteurs de page d'état publics.
De longues périodes de conservation sans croissance de stockage.
Un volume de notifications important.
La surveillance Docker avec accès au socket hôte.
D'autres applications partageant le même VPS.

L'utilisation réelle des ressources dépend du type de moniteur, de l'intervalle, du délai d'attente, de la taille de la réponse, de la conservation de l'historique, du comportement des notifications, de l'activité du tableau de bord et d'autres logiciels sur le serveur. Commencez avec un ensemble mesuré, surveillez l'utilisation du CPU, de la mémoire, du disque, le comportement de la base de données et la durée des vérifications, puis passez à une configuration de VPS VoyraCloud éligible plus grande lorsque la charge de travail réelle l'exige.

Ne considérez pas le minimum du processus d'achat comme une recommandation de dimensionnement universelle. C'est une porte d'entrée d'éligibilité pour le profil de départ validé.

Comment publier Uptime Kuma en toute sécurité ?

Publiez Uptime Kuma via un domaine ou sous-domaine dédié, un proxy inverse capable de WebSocket et HTTPS de confiance tout en gardant le port 3001 lié à localhost. Un accès SSH-tunnel à long terme est également valide lorsque seuls les administrateurs ont besoin du tableau de bord et qu'aucune page d'état publique n'est requise.

Le guide de proxy inverse Uptime Kuma officiel explique que l'application utilise WebSocket et nécessite que le proxy transmette les en-têtes Upgrade et Connection. Il note également qu'Uptime Kuma ne prend pas en charge l'hébergement sous un sous-répertoire d'URL normal tel que /uptime-kuma ; utilisez un nom d'hôte dédié tel que status.example.com.

Un bloc de localisation Nginx typique comprend :

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";
}

Ce snippet ne couvre que le chemin du proxy. Vous devez configurer séparément le nom d'hôte, le certificat TLS de confiance, le renouvellement du certificat, la redirection HTTP vers HTTPS, le pare-feu et la politique d'accès. Vérifiez l'exemple officiel actuel pour votre proxy inverse choisi avant de l'appliquer.

Utilisez cette liste de contrôle de production :

Créez un enregistrement DNS pour un nom d'hôte dédié.
Gardez 3001/tcp indisponible depuis Internet public.
Configurez le proxy inverse pour atteindre 127.0.0.1:3001.
Préservez les en-têtes de mise à niveau WebSocket.
Installez un certificat de confiance pour les navigateurs normaux.
Redirigez HTTP simple vers HTTPS.
Confirmez que le tableau de bord se met à jour sans erreurs WebSocket.
Testez la connexion, la déconnexion, les mises à jour de moniteur et les pages d'état.
Restreignez le nom d'hôte d'administration lorsque l'accès public n'est pas nécessaire.
Examinez les paramètres de proxy de confiance uniquement après que le chemin du proxy et du pare-feu est correct.

HTTPS de confiance protège les informations d'identification et le trafic de session en transit, mais cela ne sécurise pas un mot de passe administrateur faible ou un serveur obsolète. Gardez SSH renforcé, limitez les privilèges, activez l'authentification à deux facteurs lorsque cela est approprié, et maintenez le système d'exploitation et le proxy inverse.

Comment fonctionnent les notifications et les pages d'état ?

Les notifications et les pages d'état sont des fonctionnalités que vous configurez après l'initialisation ; l'image n'inclut pas de comptes tiers, d'informations d'identification, de garanties de livraison ou de domaine public. Uptime Kuma prend en charge de nombreuses méthodes de notification, mais chaque fournisseur a son propre compte, disponibilité, tarification, limites et comportement de livraison.

La documentation des méthodes de notification officielle fournit des références de configuration spécifiques au fournisseur. Ajoutez uniquement des intégrations que votre équipe possède, stockez les informations d'identification avec soin et envoyez une notification de test avant de compter sur elles. Un test réussi prouve qu'un message a fonctionné à ce moment-là ; cela ne garantit pas la livraison future.

Pour chaque moniteur important :

Décidez qui doit recevoir une alerte.
Définissez un intervalle de vérification et une politique de réessai qui conviennent au service.
Configurez une ou plusieurs méthodes de notification détenues par l'utilisateur.
Testez les notifications d'échec et de récupération.
Confirmez qu'une personne de garde peut agir sur le message.
Documentez quoi faire lorsque le moniteur signale un échec.

Les pages d'état vous permettent de partager les états de moniteur sélectionnés et les informations sur les incidents. Elles n'ont pas besoin d'exposer chaque moniteur interne. Regroupez les services d'une manière que les clients comprennent, évitez de publier des noms d'hôte sensibles ou une topologie interne, et utilisez votre propre domaine et chemin de proxy sécurisé pour un accès public.

Ne supposez pas que chaque intégration de notification est gratuite. Certains services peuvent facturer, limiter l'utilisation, changer leurs API ou nécessiter une configuration supplémentaire. VoyraCloud ne fournit pas ces comptes tiers et ne peut garantir qu'un fournisseur accepte ou livre un message.

Comment les données Uptime Kuma sont-elles stockées et sauvegardées ?

Uptime Kuma conserve son état d'application sous /app/data, qui doit rester sur un stockage local persistant et doit être sauvegardé séparément du VPS en cours d'exécution. Les directives d'installation officielles exigent un support de système de fichiers pour les verrous de fichiers POSIX et mettent en garde contre les problèmes de verrouillage de fichiers couramment associés à NFS.

Les données persistantes incluent la base de données et l'état de l'application nécessaires pour des éléments tels que :

Paramètres de l'administrateur et des utilisateurs.
Définitions de moniteur.
Historique de surveillance.
Configuration des notifications.
Pages d'état.
Calendriers de maintenance.
Autres paramètres d'instance.

Un redémarrage normal du VPS devrait préserver ces données et redémarrer l'application. Ce comportement est de la persistance, pas de la récupération après sinistre. Une suppression accidentelle, une corruption de base de données, des informations d'identification compromises, une mise à jour échouée, une perte de stockage ou la suppression du VPS peuvent toujours supprimer la seule copie.

Une routine de sauvegarde plus sûre est :

Identifiez le volume Docker local réel ou le répertoire local mappé à /app/data.
Planifiez des sauvegardes vers une destination en dehors du VPS.
Quiescez ou arrêtez Uptime Kuma lorsque la méthode de sauvegarde choisie nécessite une copie de base de données cohérente.
Copiez l'ensemble des données complet, pas seulement une liste de moniteurs exportée.
Chiffrez et protégez la sauvegarde car elle peut contenir des détails opérationnels et des informations d'identification de notification.
Conservez plus d'un point de récupération.
Restaurez sur une instance de test séparée et vérifiez les comptes, les moniteurs, l'historique, les notifications et les pages d'état.
Enregistrez la version de l'application associée à la sauvegarde.

Ne placez pas le répertoire /app/data en direct sur NFS pour cette image. Une destination de sauvegarde distante est appropriée pour les artefacts de sauvegarde copiés ; elle est différente de l'exécution de la base de données active directement sur un système de fichiers réseau.

Quel est le point aveugle de la surveillance sur le même serveur ?

Une instance Uptime Kuma ne peut pas signaler de manière fiable des échecs qui suppriment également son propre chemin de calcul, de réseau ou de notification. Si Uptime Kuma fonctionne sur le même VPS que le site web qu'il surveille, une panne du VPS peut arrêter à la fois le site web et le moniteur avant que l'alerte ne soit envoyée.

Même lorsque le service surveillé est sur un autre serveur, un emplacement Uptime Kuma l'observe toujours depuis un réseau et une région. Un itinéraire ISP local, un problème de réseau régional, une différence de résolveur DNS ou une politique de pare-feu peuvent affecter cette vue sans représenter l'expérience de chaque utilisateur.

Utilisez le déploiement en fonction de la conséquence :

Besoins en surveillance	Approche appropriée
Tableau de bord pratique pour de petits services	Une instance Uptime Kuma auto-hébergée peut être suffisante
Surveiller un service sur un autre VPS	Placez Uptime Kuma en dehors du domaine de défaillance du serveur surveillé lorsque cela est pratique
Détecter des différences d'accessibilité régionales	Utilisez des vérifications indépendantes depuis plusieurs emplacements
Alerter en cas de défaillance du VPS de surveillance	Ajoutez un heartbeat externe ou un service de surveillance indépendant
Surveillance à haute disponibilité	Concevez une architecture de surveillance multi-systèmes séparée

L'image d'application ne fournit pas de surveillance distribuée, de haute disponibilité ou de vérification externe indépendante. Traitez-la comme un point de surveillance et ajoutez une couverture indépendante lorsque des alertes manquées auraient un impact commercial significatif.

Comment mettre à jour Uptime Kuma ?

Mettez à jour Uptime Kuma délibérément en vérifiant les directives de publication officielles, en sauvegardant /app/data et en validant la nouvelle version avant de compter dessus. VoyraCloud ne met pas automatiquement à jour les instances des clients après la création du VPS.

Suivez les directives de mise à jour Uptime Kuma officielles qui s'appliquent à la version majeure installée et à la méthode de déploiement. Avant une mise à jour :

Lisez les notes de version et les exigences de migration.
Enregistrez la version de l'application actuellement en cours d'exécution.
Créez et vérifiez une sauvegarde hors serveur de /app/data.
Confirmez qu'il y a suffisamment d'espace disque libre.
Planifiez une fenêtre de maintenance pour une instance de surveillance importante.
Utilisez une version spécifique approuvée plutôt qu'une balise flottante non examinée.
Démarrez l'instance mise à jour et examinez ses journaux.
Testez la connexion administrateur, plusieurs types de moniteurs, une notification, une page d'état et la récupération après redémarrage.
Conservez un plan de retour en arrière compatible avec les changements de base de données décrits par la publication.

Ne supposez pas que revenir à l'image du conteneur est toujours suffisant. Une migration de version majeure peut changer les données de l'application, donc la récupération peut nécessiter la sauvegarde des données pré-mise à jour ainsi que la version d'image antérieure.

Les mises à jour du système d'exploitation, les mises à jour Docker, les mises à jour de proxy inverse et le renouvellement de certificat sont des responsabilités séparées. Un conteneur Uptime Kuma actuel ne rend pas le reste du serveur actuel.

Erreurs courantes à éviter

La plupart des erreurs de déploiement Uptime Kuma proviennent de l'exposition de l'initialisation, de la surestimation d'un emplacement de surveillance ou du traitement du stockage persistant comme un plan d'opérations complet. Évitez ces erreurs :

Publier le port 3001 avant de créer l'administrateur. Gardez-le sur localhost et utilisez le tunnel SSH.
Laisser le tableau de bord sur HTTP public. Utilisez HTTPS de confiance pour tout accès public.
Oublier les en-têtes de proxy WebSocket. L'interface peut se charger mais échouer à se mettre à jour correctement.
Héberger sous un sous-répertoire. Utilisez un domaine ou sous-domaine dédié.
Exécuter le /app/data actif sur NFS. Gardez-le sur un stockage local compatible.
Appeler la persistance après redémarrage une sauvegarde. Stockez des copies testées en dehors du VPS.
Supposer qu'une page d'état crée une surveillance indépendante. Elle est présentée par la même instance Uptime Kuma.
Surveiller un VPS uniquement depuis lui-même. Une défaillance complète du serveur peut faire taire à la fois le service et son moniteur.
Traiter 20 moniteurs comme un maximum ou un minimum garanti. C'est une charge de validation définie, pas un résultat de capacité universelle.
Attendre que la livraison de notification soit garantie. La disponibilité du fournisseur, les informations d'identification, les quotas, le routage et l'hôte de surveillance comptent tous.
Activer chaque intégration sans propriétaire. Configurez uniquement les canaux que quelqu'un teste et répond.
Mettre à jour sans une copie de données restaurable. Sauvegardez l'ensemble des données de l'application avant de changer de version.

FAQ

Puis-je auto-héberger Uptime Kuma sans l'installer manuellement ?

Oui. L'image d'application VoyraCloud fournit une instance Uptime Kuma préinstallée sur un Cloud VPS ou Residential IP VPS éligible. Vous devez toujours créer le premier administrateur, ajouter des moniteurs, configurer des notifications et gérer la sécurité, les mises à jour, les sauvegardes et l'accès public.

Pourquoi `http://127.0.0.1:3001` est-il affiché au lieu de l'IP du serveur ?

L'adresse locale empêche la page de configuration de l'administrateur non initialisée d'être exposée directement à Internet. Établissez le tunnel SSH depuis votre ordinateur, gardez la session ouverte, puis naviguez vers l'URL locale. Le tunnel redirige en toute sécurité votre connexion de navigateur vers Uptime Kuma sur le VPS.

Puis-je exposer le port `3001` directement à Internet ?

L'exposition directe n'est pas le chemin de production recommandé. Gardez le service lié à localhost et utilisez un proxy inverse avec un nom d'hôte dédié, un support WebSocket, HTTPS de confiance et une politique d'accès appropriée. L'image d'application ne configure pas automatiquement ce chemin public.

Uptime Kuma inclut-il des services de notification SMS, email, Slack ou autres gratuits ?

Non. Uptime Kuma peut s'intégrer à de nombreux fournisseurs de notifications, mais vous fournissez et gérez le compte et les informations d'identification du fournisseur. La tarification, les quotas, la disponibilité et la livraison des messages des tiers sont en dehors de l'image d'application et peuvent changer.

Un VPS de 1 Go est-il suffisant pour Uptime Kuma ?

Il peut être un point de départ éligible uniquement après que la validation de l'image définie soit réussie, mais la capacité réelle dépend de votre charge de travail. Le profil initial utilise 20 moniteurs à des intervalles de 60 secondes pendant 24 heures. Plus de moniteurs, des intervalles plus courts, des réponses plus grandes, un historique plus long, des services supplémentaires ou une utilisation plus intensive du tableau de bord peuvent nécessiter plus de mémoire, de CPU et de stockage.

Uptime Kuma fournit-il une haute disponibilité ou une surveillance externe ?

Non. Cette image fournit une instance Uptime Kuma auto-hébergée sur un seul VPS. La haute disponibilité, les vérifications distribuées et la surveillance externe indépendante nécessitent des systèmes et une architecture supplémentaires qui ne sont pas inclus.

Uptime Kuma m'alertera-t-il si son propre VPS échoue ?

Il se peut que non, car le processus qui envoie l'alerte peut échouer avec le VPS ou son chemin réseau. Utilisez un heartbeat externe ou un emplacement de surveillance indépendant lorsque la détection de la défaillance de l'hôte Uptime Kuma est importante.

Que dois-je sauvegarder ?

Sauvegardez l'ensemble des données persistantes mappées à /app/data et stockez la copie de récupération en dehors du VPS. Protégez la sauvegarde car elle peut contenir la configuration de surveillance et des secrets de notification, et testez une restauration au lieu de supposer qu'un ensemble de fichiers copiés est utilisable.

VoyraCloud met-il automatiquement à jour Uptime Kuma ?

Non. Les nouvelles ressources VPS reçoivent la version de l'application approuvée pour l'image au moment de la création, tandis que les mises à jour ultérieures sont gérées par le client. Consultez les instructions de mise à niveau officielles, sauvegardez /app/data et testez l'instance mise à jour avant de compter dessus.

Conclusion

Auto-hébergez Uptime Kuma lorsque vous souhaitez un tableau de bord de surveillance simple, des vérifications configurables, des notifications et des pages d'état sous votre propre administration. Commencez en privé via le tunnel SSH, concevez des moniteurs autour de modes d'échec réels, gardez /app/data sur un stockage local persistant, sauvegardez-le en dehors du VPS, et ajoutez un proxy inverse capable de WebSocket avec HTTPS de confiance uniquement lorsque l'accès public est requis.

Une instance est utile pour de nombreux petits besoins de surveillance, mais elle reste un point d'observation avec un domaine de défaillance. Ajoutez une surveillance indépendante lorsque l'hôte Uptime Kuma lui-même, l'accessibilité régionale ou la continuité des alertes doivent également être couvertes.

Utilisez l'image d'application VoyraCloud pour Uptime Kuma pour commencer à partir d'un environnement VPS VoyraCloud préinstallé tout en gardant l'accès, les données, les notifications et les opérations sous votre contrôle.