Uptime Kuma

Self-hosted uptime monitoring with a modern web UI. Uptime Kuma checks HTTP, TCP, DNS, Ping, Docker, WebSocket, and 20+ other monitor types on configurable intervals, sends alerts via 90+ notification services (Telegram, Discord, Slack, email, and more), and publishes customizable public status pages.

Key Features

• 20+ monitor types — HTTP(s), TCP, Ping, DNS, Docker, WebSocket, Steam, MQTT, and more
• 90+ notification services — Telegram, Discord, Slack, Email, Pushover, Gotify, and more
• Public status pages — customizable status pages with custom domains
• Two-factor authentication — built-in 2FA for the admin account
• SQLite or MariaDB — embedded SQLite (default) or MariaDB-compatible subchart
• External database — connect to an existing MariaDB/MySQL instance
• Smart S3 backup — tar for SQLite mode, mysqldump for MariaDB mode
• Custom CA certificates — monitor internal HTTPS services with private CA
• Gateway API and Ingress — expose the UI with classic Ingress or HTTPRoute
• External Secrets Operator — source database and S3 credentials from external providers
• Dual-stack Services — optional ipFamilyPolicy and ipFamilies controls
• Secure runtime defaults — seccomp, dropped capabilities, read-only root filesystem, and no API token mount
• Availability controls — optional PodDisruptionBudget and NetworkPolicy

Installation

HTTPS repository:

helm repo add helmforge https://repo.helmforge.dev
helm repo update
helm install uptime-kuma helmforge/uptime-kuma -f values.yaml

OCI registry:

helm install uptime-kuma oci://ghcr.io/helmforgedev/helm/uptime-kuma -f values.yaml

After deploying with default values, access the setup wizard to create the admin account:

kubectl port-forward svc/<release>-uptime-kuma 3001:80
# Open http://localhost:3001 in your browser

Deployment Examples

# values.yaml — Uptime Kuma with SQLite (default, no database configuration needed)
persistence:
  enabled: true
  size: 2Gi

ingress:
  enabled: true
  ingressClassName: traefik
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  hosts:
    - host: status.example.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: uptime-kuma-tls
      hosts:
        - status.example.com

# values.yaml — Uptime Kuma with bundled MariaDB subchart
database:
  type: mariadb

mysql:
  enabled: true
  auth:
    password: 'mariadb-password'

persistence:
  enabled: true
  size: 2Gi

ingress:
  enabled: true
  ingressClassName: traefik
  hosts:
    - host: status.example.com
      paths:
        - path: /
          pathType: Prefix

# values.yaml — Uptime Kuma with external MariaDB/MySQL
database:
  type: mariadb
  external:
    host: mariadb.database.svc.cluster.local
    port: '3306'
    name: uptime_kuma
    username: uptime_kuma
    existingSecret: uptime-kuma-db-credentials
    existingSecretPasswordKey: password

mysql:
  enabled: false

persistence:
  enabled: true
  size: 2Gi

ingress:
  enabled: true
  ingressClassName: traefik
  hosts:
    - host: status.example.com
      paths:
        - path: /
          pathType: Prefix

# values.yaml — Monitor internal HTTPS services with a private CA certificate
# The CA certificate must be stored in the /app/data PVC at /app/data/ca.pem
uptimeKuma:
  extraEnv:
    - name: NODE_EXTRA_CA_CERTS
      value: /app/data/ca.pem

persistence:
  enabled: true
  size: 2Gi

ingress:
  enabled: true
  ingressClassName: traefik
  hosts:
    - host: status.example.com
      paths:
        - path: /
          pathType: Prefix

# values.yaml — Daily S3 backup
# Backup strategy is automatic: tar for SQLite mode, mysqldump for MariaDB mode
backup:
  enabled: true
  schedule: '0 2 * * *'
  s3:
    endpoint: https://s3.amazonaws.com
    bucket: my-uptime-kuma-backups
    prefix: uptime-kuma
    existingSecret: uptime-kuma-s3-credentials

persistence:
  enabled: true
  size: 2Gi

ingress:
  enabled: true
  ingressClassName: traefik
  hosts:
    - host: status.example.com
      paths:
        - path: /
          pathType: Prefix

# values.yaml — expose Uptime Kuma through Gateway API
persistence:
  enabled: true
  size: 2Gi

gatewayAPI:
  enabled: true
  httpRoutes:
    - name: uptime-kuma
      spec:
        parentRefs:
          - name: public-gateway
            namespace: gateway-system
        hostnames:
          - status.example.com
        rules:
          - matches:
              - path:
                  type: PathPrefix
                  value: /

# values.yaml — external database and S3 credentials managed by External Secrets Operator
database:
  type: mariadb
  external:
    host: mariadb.database.svc.cluster.local
    username: uptime_kuma
    existingSecret: uptime-kuma-db
    existingSecretPasswordKey: password

backup:
  enabled: true
  s3:
    endpoint: https://s3.amazonaws.com
    bucket: my-uptime-kuma-backups
    existingSecret: uptime-kuma-s3

externalSecrets:
  enabled: true
  apiVersion: external-secrets.io/v1
  refreshInterval: 1h
  items:
    - name: database
      spec:
        secretStoreRef:
          name: platform-secrets
          kind: ClusterSecretStore
        target:
          name: uptime-kuma-db
          creationPolicy: Owner
        data:
          - secretKey: password
            remoteRef:
              key: uptime-kuma/database
              property: password
    - name: s3
      spec:
        secretStoreRef:
          name: platform-secrets
          kind: ClusterSecretStore
        target:
          name: uptime-kuma-s3
          creationPolicy: Owner
        data:
          - secretKey: access-key
            remoteRef:
              key: uptime-kuma/s3
              property: accessKey
          - secretKey: secret-key
            remoteRef:
              key: uptime-kuma/s3
              property: secretKey

Architecture and Production Boundaries

One Uptime Kuma pod receives traffic from a ClusterIP Service and optional Ingress or HTTPRoute. The pod stores state either on /app/data in SQLite mode or in a bundled/external MariaDB-compatible database. An optional CronJob reads that same data path and uploads a tar archive or database dump to S3-compatible storage.

Uptime Kuma must remain single-replica because monitor execution and WebSocket state are not coordinated between application processes. The optional PodDisruptionBudget protects against voluntary disruption, but it does not make the application highly available.

Security Defaults

Application, database-wait, and backup containers deny privilege escalation, drop all Linux capabilities, use runtime-default seccomp, and keep the image root filesystem read-only. Writable temporary state uses bounded emptyDir volumes. Service-account API token mounting is disabled by default, and database contract changes trigger a workload rollout through a checksum annotation.

The official standard Uptime Kuma image starts as UID 0, so this chart does not claim a non-root runtime. Platform admission controls, node isolation, explicit resources, tested backups, and network policy remain operator responsibilities.

Configuration Reference

Core

Image

Uptime Kuma Configuration

Database

Database — MySQL Subchart

Persistence

Backup

The backup strategy adapts to the configured database mode automatically:

• SQLite mode — archives the full /app/data directory using tar.
• MariaDB mode — runs mysqldump against the database and uploads the SQL dump.

Service

Ingress

Gateway API

Use Gateway API when your cluster standardizes HTTP routing through Gateway resources. The chart renders HTTPRoutes that target the Uptime Kuma Service by default.

External Secrets Operator

External Secrets can materialize database, S3, or integration credentials without storing them directly in Helm values.

Probes

Resources and Security

Service Account

Availability and Network Isolation

Scheduling

Extra

Upgrade Notes

Uptime Kuma 2.5.6 fixes average-response badge calculations and updates security-sensitive dependencies. The container and storage contracts are unchanged. Review the upstream 2.5.6 release and back up the /app/data PVC before upgrading.

After each backup or chart upgrade, restore the newest backup in a disposable namespace and verify monitor history, status pages, and notification settings. For Helm upgrades, prefer a reviewed values file with --reset-then-reuse-values so new security defaults are adopted without losing intentional overrides.

More Information

• Uptime Kuma Official Website
• Uptime Kuma GitHub Repository
• HelmForge Uptime Kuma Chart Source