Uptime Kuma sur Google Cloud Run

Uptime Kuma est un outil de supervision auto-hébergé et élégant qui suit la disponibilité des sites web, des API, des ports TCP, des enregistrements DNS et bien plus, avec un tableau de bord épuré, des pages de statut et plus de 90 canaux de notification. Ce module déploie Uptime Kuma sur Cloud Run v2 en s'appuyant sur le socle App_CloudRun, qui provisionne et gère l'infrastructure Google Cloud partagée.

Ce guide se concentre sur les services cloud utilisés par Uptime Kuma et sur la manière de les explorer et de les exploiter depuis la console Google Cloud et la ligne de commande. Pour les mécanismes communs à toutes les applications Cloud Run — identité du service, entrée et équilibrage de charge, mise à l'échelle et concurrence, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, sauvegardes et cycle de vie du déploiement — reportez-vous au guide du socle App_CloudRun plutôt que de les répéter ici.

1. Vue d'ensemble

Uptime Kuma s'exécute sous forme de conteneur Node.js sur Cloud Run v2. C'est l'un des modules les plus simples du catalogue — il n'y a ni base de données externe, ni cache, ni secret applicatif. Le déploiement assemble un ensemble ciblé de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	Cloud Run v2	Service Node.js, 1 vCPU / 512 MiB par défaut, CPU toujours allouée
État persistant	Filestore (NFS)	Base de données SQLite intégrée et fichiers téléversés sous `/app/data` (gen2 requis)
Image de conteneur	Artifact Registry	Build Cloud Build personnalisé (`container_image_source = "custom"`) — une fine couche `FROM louislam/uptime-kuma` qui modifie le mode de journalisation SQLite pour la sécurité sur NFS (voir ci-dessous)
Base de données	—	Aucune — Uptime Kuma v1 utilise SQLite intégré ; `database_type = "NONE"`
Cache	—	Aucun — Redis n'est pas requis (`enable_redis = false`)
Secrets	Secret Manager	Aucun secret applicatif (`secret_ids = {}`) ; les identifiants administrateur sont stockés dans SQLite
Entrée	URL Cloud Run / Cloud Load Balancing	URL `run.app` par défaut ; équilibreur de charge HTTPS externe + domaine personnalisé en option

Valeurs par défaut judicieuses à connaître d'emblée :

cpu_always_allocated = true est la valeur par défaut, et c'est délibéré — la boucle de supervision EST le produit. Uptime Kuma interroge ses moniteurs à partir d'un planificateur interne au processus, sans aucune requête entrante. Avec la facturation à la requête de Cloud Run, la CPU est bridée quasiment à zéro entre les requêtes, si bien que les vérifications se bloqueraient ou se déclencheraient en retard. La CPU facturée à l'instance (toujours allouée) maintient le planificateur à pleine vitesse tant qu'une instance est active. Ne la définissez pas sur false.
min_instance_count vaut 0 par défaut — le service peut descendre à zéro lorsque rien ne maintient une instance active, et la supervision est suspendue tant qu'il est à zéro. Pour une véritable supervision 24 h/24 et 7 j/7, définissez min_instance_count = 1 (une seule instance toujours active).
Pas de base de données externe. database_type = "NONE", enable_cloudsql_volume = false, et il n'y a pas de job db-init. Uptime Kuma crée automatiquement son schéma SQLite intégré au premier démarrage.
La persistance NFS est obligatoire. enable_nfs = true avec nfs_mount_path = "/app/data" monte un volume Filestore (NFS) contenant la base de données SQLite et les fichiers téléversés, afin que les moniteurs et l'historique survivent aux redémarrages et aux révisions. Nécessite l'environnement d'exécution gen2.
SQLite à écrivain unique. SQLite sur NFS repose sur le verrouillage de fichiers ; exécutez une seule instance en production (max_instance_count = 1). La valeur par défaut du module est max_instance_count = 3 pour absorber les pics sur le tableau de bord — réduisez-la en production.
Le build personnalisé modifie SQLite pour la sécurité sur NFS. container_image_source = "custom" est la valeur par défaut — ne la remplacez pas par "prebuilt". Uptime Kuma définit inconditionnellement PRAGMA journal_mode = WAL à chaque démarrage (codé en dur dans server/database.js, non configurable par variable d'environnement) ; WAL repose sur un verrouillage par plages d'octets en mémoire partagée entre le fichier de base de données et son fichier annexe -wal, que le volume /app/data adossé à NFS ne fournit pas de manière fiable, ce qui a provoqué des erreurs SQLITE_CORRUPT constatées. L'étape Cloud Build (UptimeKuma_Common/scripts/Dockerfile) modifie ce PRAGMA dans le code source pour passer en mode DELETE, qui n'a besoin que du verrouillage standard du fichier entier, que NFS gère correctement. enable_image_mirroring = true pousse en outre l'image construite dans Artifact Registry afin d'éviter les limites de débit de Docker Hub.
Aucun secret applicatif — il n'y a rien à injecter depuis Secret Manager. Le compte administrateur est créé de manière interactive lors du premier accès.

2. Services Google Cloud et comment les explorer

Toutes les commandes supposent que PROJECT et REGION sont définies. Les noms des services et des ressources figurent dans les sorties du déploiement.

A. Cloud Run — le service Uptime Kuma

Uptime Kuma s'exécute comme un service Cloud Run v2 avec une CPU toujours allouée, afin que son planificateur de vérifications en arrière-plan continue d'interroger les cibles entre les requêtes. Chaque déploiement crée une révision immuable ; le trafic peut être réparti entre les révisions pour des déploiements progressifs sûrs.

Console : Cloud Run → sélectionnez le service pour consulter les révisions, le trafic, les journaux et les métriques.

CLI :

gcloud run services list --project "$PROJECT" --region "$REGION"
gcloud run services describe <service-name> --project "$PROJECT" --region "$REGION"
gcloud run revisions list --service <service-name> --project "$PROJECT" --region "$REGION"

Consultez App_CloudRun pour la mise à l'échelle, la concurrence, l'environnement d'exécution et la répartition du trafic.

B. Filestore (NFS) — le volume de données persistant

Tout l'état d'Uptime Kuma — la base de données SQLite intégrée, l'historique des moniteurs, les fichiers téléversés et les paramètres (y compris l'utilisateur administrateur) — se trouve sous /app/data, que le module monte depuis un partage Filestore (NFS). Sans lui, tout est perdu au redémarrage. L'environnement d'exécution gen2 est requis pour les montages NFS.

Console : Filestore → Instances.

CLI :

gcloud filestore instances list --project "$PROJECT"
gcloud run services describe <service-name> --project "$PROJECT" --region "$REGION" \
  --format="yaml(spec.template.spec.volumes)"

Consultez App_CloudRun pour le modèle de montage NFS et CMEK.

C. Artifact Registry — l'image mise en miroir

Avec container_image_source = "custom" (la valeur par défaut), une étape Cloud Build construit une fine image personnalisée FROM louislam/uptime-kuma, en appliquant un correctif au code source qui fait passer le journal_mode SQLite codé en dur de WAL à DELETE — le verrouillage en mémoire partagée de WAL n'est pas sûr sur le volume /app/data adossé à NFS (voir la Vue d'ensemble). Avec enable_image_mirroring = true (la valeur par défaut), l'image construite est ensuite poussée dans l'Artifact Registry du projet, ce qui protège les déploiements des limites de débit et des pannes de Docker Hub.

Console : Artifact Registry → Repositories.

CLI :

gcloud artifacts repositories list --project "$PROJECT" --location "$REGION"
gcloud artifacts docker images list <region>-docker.pkg.dev/$PROJECT/<repo>

D. Réseau et entrée

Le service est accessible par défaut à son URL run.app. Un équilibreur de charge HTTPS externe avec un domaine personnalisé, Cloud CDN et Cloud Armor peut être ajouté ; les paramètres d'entrée et la sortie VPC contrôlent la connectivité. Notez qu'Uptime Kuma établit aussi des connexions sortantes — chaque vérification de moniteur est un appel sortant depuis le conteneur.

Console : Cloud Run (URL du service) ; Network services → Load balancing.

CLI :

gcloud run services describe <service-name> --region "$REGION" --format='value(status.url)'
gcloud compute addresses list --project "$PROJECT"

Consultez App_CloudRun.

E. Cloud Logging et Monitoring

Les journaux des conteneurs sont envoyés à Cloud Logging ; les métriques Cloud Run sont envoyées à Cloud Monitoring, avec des tests de disponibilité et des règles d'alerte en option. Eh oui — vous pouvez diriger un test de disponibilité Google Cloud vers votre instance Uptime Kuma pour superviser le superviseur.

Console : Logging → Logs Explorer ; Monitoring → Dashboards / Alerting.

CLI :

gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" --limit 50

3. Comportement de l'application Uptime Kuma

Aucun job d'initialisation. Uptime Kuma crée automatiquement son schéma SQLite intégré au premier démarrage ; il n'existe aucun job db-init ni de migration, et initialization_jobs vaut [] par défaut.
Configuration au premier lancement. Lors du premier accès, Uptime Kuma présente une page de configuration qui vous demande de créer le compte administrateur — aucun identifiant par défaut n'est intégré à l'image. Le compte est stocké dans SQLite sur le volume NFS, il persiste donc d'une révision à l'autre.
Le planificateur de vérifications s'exécute dans le processus. L'interrogation des moniteurs, les nouvelles tentatives et l'envoi des notifications s'exécutent tous dans le processus Node.js, pilotés par des minuteurs — et non par des requêtes HTTP entrantes. C'est pourquoi cpu_always_allocated = true est la valeur par défaut, et pourquoi une supervision continue exige en outre qu'une instance soit en cours d'exécution (min_instance_count = 1).
La mise à l'échelle à zéro suspend la supervision. Avec la valeur par défaut min_instance_count = 0, Cloud Run arrête la dernière instance lorsqu'elle devient inactive. Tant que le service est à zéro, aucune vérification ne s'exécute et aucune alerte ne se déclenche ; l'interrogation reprend lorsque la requête suivante (par exemple l'ouverture du tableau de bord) démarre une instance à froid. C'est acceptable pour un usage occasionnel ou de lab, mais inadapté à une supervision de production.
SQLite à écrivain unique. SQLite est une base de données à écrivain unique. Plusieurs instances simultanées écrivant dans le même fichier SQLite via NFS risquent des conflits de verrouillage ou une corruption — conservez max_instance_count = 1 en production.
Chemin de santé. Les sondes de démarrage et de vivacité ciblent / sur le port 3001, qui renvoie HTTP 200 une fois l'application démarrée. La sonde de démarrage autorise un délai initial allant jusqu'à 30 s, plus 30 échecs à intervalles de 10 s.

Vérification :

SERVICE=$(gcloud run services list --project "$PROJECT" --region "$REGION" \
  --filter="metadata.name~uptimekuma" --format="value(metadata.name)" --limit=1)
SERVICE_URL=$(gcloud run services describe "$SERVICE" \
  --project "$PROJECT" --region "$REGION" --format="value(status.url)")
curl -s -o /dev/null -w "%{http_code}\n" "$SERVICE_URL/"

4. Variables de configuration

Les variables sont regroupées exactement comme elles apparaissent sur la plateforme de déploiement. Seuls les paramètres propres à Uptime Kuma ou notables pour lui sont listés ; toutes les autres entrées sont héritées d'App_CloudRun avec leur comportement standard.