Uptime Kuma in Docker.
Monitoring in one container.

Run it with Docker Compose

The bundled docker-compose.yml is intentionally small: one service, one named volume, and the built-in SQLite database inside it.

# RemarkableCloud Uptime Kuma - standalone. SQLite; /app/data volume. Set up the admin on first visit.
name: uptime-kuma
services:
  uptime-kuma:
    image: ${UK_IMAGE:-ghcr.io/remarkablecloud/uptime-kuma:1-r1}
    restart: unless-stopped
    ports: ["${HTTP_PORT:-3001}:3001"]
    volumes:
      - uk-data:/app/data
volumes:
  uk-data:

Walking through it:

• image pins the RemarkableCloud tag by default and lets you override it with UK_IMAGE for testing a newer build.
• restart: unless-stopped brings the monitor back after a host reboot or crash, which matters for a tool whose job is to always be watching.
• ports publishes the container’s port 3001 on the host. In a standalone test that is http://localhost:3001. In production you leave this on an internal network and let the proxy reach 3001 directly.
• volumes keeps all state (the SQLite database, monitor definitions, history, and uploaded assets) under /app/data in the named uk-data volume.

Start it, then open the UI and create your admin account:

docker compose up -d

The first visit to http://localhost:3001 shows a setup screen where you choose the admin username and password. There is no generated password to look up, because Uptime Kuma provisions the admin interactively on first use.

Behind Traefik

In production the platform runs Uptime Kuma behind Traefik, which terminates TLS. Point the proxy at container port 3001. Uptime Kuma does not need a base-URL environment variable for normal use; it serves correctly from the hostname the proxy forwards. If you enable a public status page, set its domain in the status page settings inside the app.

Environment variable reference

This image sets no application environment variables. The catalog defines none, and the compose file exposes only two overrides:

Variable	Compose default	Platform value (catalog)	Notes
UK_IMAGE	ghcr.io/remarkablecloud/uptime-kuma:1-r1	pinned by catalog	Image reference; override only to test a build.
HTTP_PORT	3001	n/a (proxy reaches 3001)	Host port published by compose, mapped to container 3001.

Uptime Kuma is configured through its web UI rather than environment variables. Monitors, notifications, status pages, and the admin account are all managed in-app and stored in the /app/data volume.

Hardening notes

• Create the admin account immediately. Until you complete the first-visit setup, the instance is unclaimed. Do the setup as soon as the container is reachable, ideally before it is exposed publicly, and choose a strong password.
• Terminate TLS at the proxy. Serve Uptime Kuma over HTTPS through Traefik and keep the raw port on an internal network. Do not expose port 3001 to the internet directly.
• Enable two-factor authentication. Uptime Kuma supports 2FA on the admin account; turn it on from the settings once you are logged in.
• Scope status pages deliberately. A public status page reveals which services you monitor and their state. Publish only what you intend to be public, and keep internal checks on private pages.
• Guard notification secrets. Notification integrations store tokens and webhook URLs in the database, so protect the /app/data volume and its backups the same way you would protect credentials.

Backups

All state lives in the /app/data volume: the SQLite database (kuma.db), monitor definitions, check history, and settings. Backing up that volume backs up the whole instance.

For a consistent file-level backup, stop the container so the SQLite database is not written mid-copy, archive the volume, then start it again:

docker compose stop uptime-kuma
docker run --rm -v uptime-kuma_uk-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/uptime-kuma-data.tgz -C /data .
docker compose start uptime-kuma

The volume archive is the reliable backup. The in-app export under Settings, then Backup, is deprecated in the 1.x line and does not capture everything, so treat it as a convenience rather than your primary backup. Test a restore into a throwaway stack before you rely on any backup.

Upgrades

Uptime Kuma migrates its own database at startup, so upgrading is a matter of moving to a newer image tag.

1. Read the changelog and the upstream release notes for the target version.
2. Back up the /app/data volume first (see above). Database migrations are one-way.
3. Pull the new tag, then recreate the container:

   docker compose pull
   docker compose up -d

4. Confirm the container reports healthy and check that your monitors resume.

Never downgrade after a migration has run without restoring from a pre-upgrade backup.