Uptime Kuma on Google Cloud Run

Uptime Kuma is a fancy, self-hosted monitoring tool for tracking the uptime of websites, APIs, TCP ports, DNS records, and more, with a clean dashboard, status pages, and 90+ notification channels. This module deploys Uptime Kuma on Cloud Run v2 on top of the App_CloudRun foundation, which provisions and manages the shared Google Cloud infrastructure.

This guide focuses on the cloud services Uptime Kuma uses and how to explore and operate them from the Google Cloud Console and the command line. For the mechanics common to every Cloud Run application — service identity, ingress and load balancing, scaling and concurrency, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, backups, and the deployment lifecycle — refer to the App_CloudRun foundation guide rather than repeating them here.

1. Overview

Uptime Kuma runs as a Node.js container on Cloud Run v2. It is one of the simplest modules in the catalogue — there is no external database, no cache, and no application secret. The deployment wires together a focused set of Google Cloud services:

Capability	Google Cloud service	Notes
Compute	Cloud Run v2	Node.js service, 1 vCPU / 512 MiB by default, CPU always allocated
Persistent state	Filestore (NFS)	Embedded SQLite database and uploads under `/app/data` (gen2 required)
Container image	Artifact Registry	The official `louislam/uptime-kuma` image is mirrored in (prebuilt, no Cloud Build)
Database	—	None — Uptime Kuma v1 uses embedded SQLite; `database_type = "NONE"`
Cache	—	None — Redis is not required (`enable_redis = false`)
Secrets	Secret Manager	No application secrets (`secret_ids = {}`); admin credentials live in SQLite
Ingress	Cloud Run URL / Cloud Load Balancing	Default `run.app` URL, optional external HTTPS load balancer + custom domain

Sensible defaults worth knowing up front:

cpu_always_allocated = true is the default and is deliberate — the monitoring loop IS the product. Uptime Kuma polls its monitors from an in-process scheduler with no inbound request. Under Cloud Run's request-based billing the CPU is throttled to near-zero between requests, so checks would stall or fire late. Instance-based (always-allocated) CPU keeps the scheduler running at full speed while an instance is alive. Do not set this to false.
min_instance_count defaults to 0 — the service can scale to zero when nothing keeps an instance alive, and monitoring pauses while it is scaled to zero. For genuine 24/7 monitoring, set min_instance_count = 1 (a single always-on instance).
No external database. database_type = "NONE", enable_cloudsql_volume = false, and there is no db-init job. Uptime Kuma creates its embedded SQLite schema automatically on first boot.
NFS persistence is mandatory. enable_nfs = true with nfs_mount_path = "/app/data" mounts a Filestore (NFS) volume holding the SQLite database and uploads, so monitors and history survive restarts and revisions. Requires the gen2 execution environment.
Single-writer SQLite. SQLite over NFS relies on file locking; run a single instance in production (max_instance_count = 1). The module default is max_instance_count = 3 for burst headroom on the dashboard — lower it for production.
Prebuilt image. container_image_source = "prebuilt" deploys the official louislam/uptime-kuma:1 image directly; enable_image_mirroring = true copies it into Artifact Registry to avoid Docker Hub rate limits.
No application secrets — there is nothing to inject from Secret Manager. The admin account is created interactively on first access.

2. Google Cloud Services & How to Explore Them

All commands assume PROJECT and REGION are set. Service and resource names are reported in the deployment Outputs.

A. Cloud Run — the Uptime Kuma service

Uptime Kuma runs as a Cloud Run v2 service with CPU always allocated so its background check scheduler keeps polling between requests. Each deployment creates an immutable revision; traffic can be split across revisions for safe rollouts.

Console: Cloud Run → select the service for revisions, traffic, logs, and metrics.

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"

See App_CloudRun for scaling, concurrency, execution environment, and traffic splitting.

B. Filestore (NFS) — the persistent data volume

All Uptime Kuma state — the embedded SQLite database, monitor history, uploads, and settings (including the admin user) — lives under /app/data, which the module mounts from a Filestore (NFS) share. Without it, everything is lost on restart. The gen2 execution environment is required for NFS mounts.

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)"

See App_CloudRun for the NFS mount model and CMEK.

C. Artifact Registry — the mirrored image

With enable_image_mirroring = true (the default) the official louislam/uptime-kuma image is copied into the project's Artifact Registry before deployment, insulating deploys from Docker Hub rate limits and outages. There is no Cloud Build step — the image is prebuilt upstream.

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. Networking & ingress

The service is reachable at its run.app URL by default. An external HTTPS load balancer with a custom domain, Cloud CDN, and Cloud Armor can be layered on; ingress settings and VPC egress control connectivity. Note that Uptime Kuma also makes outbound connections — every monitor check is an egress call from the container.

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

CLI:

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

See App_CloudRun.

E. Cloud Logging & Monitoring

Container logs flow to Cloud Logging; Cloud Run metrics flow to Cloud Monitoring, with optional uptime checks and alert policies. Yes — you can point a Google Cloud uptime check at your Uptime Kuma instance to monitor the monitor.

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

CLI:

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

3. Uptime Kuma Application Behaviour

No initialization jobs. Uptime Kuma creates its embedded SQLite schema automatically on first boot; there is no db-init or migration job, and initialization_jobs defaults to [].
First-run setup. On first access, Uptime Kuma presents a setup page asking you to create the admin account — there are no default credentials baked into the image. The account is stored in SQLite on the NFS volume, so it persists across revisions.
The check scheduler runs in-process. Monitor polling, retries, and notification dispatch all run inside the Node.js process, driven by timers — not by inbound HTTP requests. This is why cpu_always_allocated = true is the default and why continuous monitoring additionally requires an instance to be running (min_instance_count = 1).
Scale-to-zero pauses monitoring. With the default min_instance_count = 0, Cloud Run stops the last instance when it goes idle. While scaled to zero, no checks execute and no alerts fire; polling resumes when the next request (e.g. opening the dashboard) cold-starts an instance. This is safe for casual/lab use but wrong for production monitoring.
Single-writer SQLite. SQLite is a single-writer database. Multiple concurrent instances writing the same SQLite file over NFS risk lock contention or corruption — keep max_instance_count = 1 in production.
Health path. Startup and liveness probes target / on port 3001, which returns HTTP 200 once the app is up. The startup probe allows up to 30 s initial delay plus 30 failures at 10 s intervals.

Verification:

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. Configuration Variables

Variables are grouped exactly as they appear on the deployment platform. Only settings specific to or notable for Uptime Kuma are listed; every other input is inherited from App_CloudRun with its standard behaviour.