Uptime Kuma

Overview

Uptime Kuma is a self-hosted uptime monitoring tool (MIT-licensed) — outside-in HTTP(s), TCP, DNS, and ping checks against your apps and third-party dependencies, alerts through 90+ notification providers, and public status pages. This template deploys a single stateful workload with its SQLite database on a persistent volume, served on the canonical *.cpln.app endpoint. The admin account is created by the first visitor to the URL — complete the first-visit setup immediately after installing.

Architecture

Uptime Kuma — A single-replica stateful workload serving the dashboard, monitoring engine, and status pages on port 3001 (HTTP + WebSocket).
SQLite on a persistent volume — All state (monitors, users, notification settings, heartbeat history) lives in a SQLite database on the workload’s volume set; there is no database dependency.

What Gets Created

Stateful Uptime Kuma Workload — A single replica serving the dashboard, monitoring engine, and status pages on port 3001.
Volume Set — A 10 GiB persistent volume mounted at /app/data holding the SQLite database, uploads, and generated keys. A final snapshot is kept for 7 days on delete.
Identity — The workload identity, with no grants — this template creates no secrets and no policies.

This template does not create a GVC. You must deploy it into an existing GVC.

Prerequisites

None — a default install needs no secrets, cloud accounts, or external resources. Install the template using your preferred method:

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

First-Visit Setup

Uptime Kuma has no way to preset admin credentials — the admin account is created through a setup wizard by the first person to open the URL. The template preselects SQLite, so the wizard asks only for the admin username and password.

Open the dashboard and create the admin account immediately after install. Until you complete the setup wizard, anyone who can reach the endpoint can claim the instance by creating the admin account. Once one account exists, the wizard is permanently disabled.

Wait for the workload to become ready

A fresh install is typically ready within a minute. Find the canonical endpoint under status.canonicalEndpoint of the {release}-uptime-kuma workload.

Open the endpoint and create the admin account

Visit https://<canonical>.cpln.app — you are redirected to the setup wizard. Choose an admin username and a strong password.

Configuration

The default values.yaml for this template:

image: louislam/uptime-kuma:2.4.0

resources:
  cpu: 500m
  memory: 512Mi
  minCpu: 125m
  minMemory: 256Mi

volumeset:
  capacity: 10 # GiB (minimum 10) — SQLite database, uploads, and generated keys

publicAccess:
  enabled: true # dashboard + public status pages on the canonical *.cpln.app HTTPS endpoint

internalAccess: # internal firewall scope (in-GVC callers, e.g. status-page consumers)
  type: same-gvc # options: none, same-gvc, same-org, workload-list
  workloads: [] # used with workload-list, e.g. //gvc/GVC_NAME/workload/WORKLOAD_NAME

Uptime Kuma Instance

image — The Uptime Kuma container image.
resources — CPU and memory for the Uptime Kuma container.
volumeset.capacity — Volume size in GiB (minimum 10) for the SQLite database, uploads, and generated keys.

Access

publicAccess.enabled — Serve the dashboard and status pages on the canonical *.cpln.app HTTPS endpoint (default). The dashboard is gated by Uptime Kuma’s own login; status pages are public by design. Set to false for an internal-only instance (external requests are blocked at the edge; in-GVC callers still reach it per internalAccess).
internalAccess.type — Internal firewall scope of the Uptime Kuma workload:

Type	Description
`none`	No internal access.
`same-gvc`	Allow access from all workloads in the same GVC (default).
`same-org`	Allow access from all workloads in the same organization.
`workload-list`	Allow access only from workloads listed in `internalAccess.workloads`.

Connecting

What	Value
Dashboard (public)	`https://<canonical>.cpln.app` — `status.canonicalEndpoint` of `{release}-uptime-kuma`
Status pages (public)	`https://<canonical>.cpln.app/status/{slug}` — no login required
Internal (same GVC)	`http://{release}-uptime-kuma.{gvc}.cpln.local:3001`
Login	The admin account you create in the first-visit setup

Monitors, Notifications, and Status Pages

Everything Uptime Kuma monitors is configured in the app UI after login — none of it is deploy-time configuration:

Monitors — HTTP(s), TCP port, DNS, and ICMP ping checks all work out of the box; the workload has unrestricted outbound access, so it can reach any public target as well as in-GVC workloads by their internal hostnames.
Notifications — 90+ providers (Slack, email, webhooks, PagerDuty, and more), configured per monitor or globally in the UI. Webhook targets inside the GVC work using internal *.cpln.local hostnames.
Status pages — Published at /status/{slug} on the same endpoint, publicly reachable without login.

The dashboard’s live updates arrive over a WebSocket (socket.io) connection to the same endpoint, which works through the canonical endpoint without any extra configuration; status pages are plain HTTP.

Resetting the Admin Password

If you lose the admin password, run upstream’s documented recovery command inside the container:

cpln workload exec {release}-uptime-kuma --gvc {gvc} --container uptime-kuma -- npm run reset-password

Important Notes

Complete the first-visit setup immediately after install — until an admin account exists, anyone who can reach the endpoint can create it; once one account exists the wizard is permanently disabled. See First-Visit Setup.
Single instance only — upstream supports exactly one instance (no clustering), so the workload is pinned to 1 replica and there is no replicas knob. A restart means a brief monitoring gap; monitors resume automatically on boot, and all data survives on the volume set.
No cloud backups in this template — durability is the persistent volume plus a 7-day final snapshot on uninstall. Uninstalling and reinstalling starts a fresh instance.
Do not switch the database to MariaDB in place — upstream does not support migrating an existing SQLite instance; a MariaDB-backed deployment must be a fresh install.
Forgot the admin password? Reset it from inside the container — see Resetting the Admin Password.

External References

Uptime Kuma on GitHub

Upstream source repository

Uptime Kuma Wiki

Official documentation wiki

Environment Variables

Environment variables reference

Docker Tags

Image tags and variants reference

Uptime Kuma Template

View the source files, default values, and chart definition

Template Catalog

Templates

Overview

Architecture

What Gets Created

Prerequisites

UI

CLI

Terraform

Pulumi

First-Visit Setup

Configuration

Uptime Kuma Instance

Access

Connecting

Monitors, Notifications, and Status Pages

Resetting the Admin Password

Important Notes

External References

Uptime Kuma on GitHub

Uptime Kuma Wiki

Environment Variables

Docker Tags

Uptime Kuma Template

​Overview

​Architecture

​What Gets Created

​Prerequisites

UI

CLI

Terraform

Pulumi

​First-Visit Setup

​Configuration

​Uptime Kuma Instance

​Access

​Connecting

​Monitors, Notifications, and Status Pages

​Resetting the Admin Password

​Important Notes

​External References

Uptime Kuma on GitHub

Uptime Kuma Wiki

Environment Variables

Docker Tags

Uptime Kuma Template

Overview

Architecture

What Gets Created

Prerequisites

First-Visit Setup

Configuration

Uptime Kuma Instance

Access

Connecting

Monitors, Notifications, and Status Pages

Resetting the Admin Password

Important Notes

External References