AutoKuma is an MIT-licensed Rust utility that creates Uptime Kuma monitors automatically from Docker container labels, .json/.toml files, or Kubernetes custom resources, made for self-hosters and operators who run Uptime Kuma next to containerized services and do not want to add monitors one by one in the web UI.

What it is

AutoKuma lives in the self-hosted monitoring ecosystem around Uptime Kuma. It connects to a running Uptime Kuma instance over the SocketIO API, watches supported sources for monitor definitions, and creates, updates, and manages the corresponding monitors, notifications, tags, and maintenance entries on your behalf. Docker is the primary source: monitors are declared as container labels, and AutoKuma reconciles them into Uptime Kuma whenever containers start, stop, or change.

The specific thing it replaces is manual monitor creation in the Uptime Kuma UI. Instead of logging into the dashboard and filling in a form for every service, an operator attaches labels such as kuma.my-app.http.name and kuma.my-app.http.url to a container, and the monitor appears automatically. Configuration also supports files in .json and .toml format, Docker Swarm service and container labels, and Kubernetes custom resources defined in autokuma/kubernetes/crds-autokuma.yml.

Key capabilities

• Label-driven monitor creation using the format kuma..., for example kuma.my-app.http.url.
• Configurable label prefix through the AUTOKUMA__DOCKER__LABEL_PREFIX environment variable, defaulting to kuma.
• A Files provider that sources monitors from .json and .toml files, alongside the Docker provider.
• Kubernetes support through CRDs shipped in autokuma/kubernetes/crds-autokuma.yml, plus Docker Swarm service and container labels.
• Monitor types beyond HTTP, including ping and dns, with groups, notifications, tags, templating, snippets, and static monitors covered in the documentation.
• The companion Kuma CLI, a terminal tool with monitor, tag, notification, maintenance, status-page, and docker-host resources, each exposing subcommands such as add, delete, edit, list, get, pause, resume, and test.
• The kuma-client Rust crate, a client library for the Uptime Kuma SocketIO API, available for anyone building their own integrations.

Who uses it and how

• Homelab and small-server operators running a Docker Compose stack where Uptime Kuma is reachable at an internal address such as http://uptime-kuma:3001, with AutoKuma mounting /var/run/docker.sock and a persistent autokuma-data:/data volume.
• Teams that deploy many containers and want monitoring to follow the deployment, so a new service is watched as soon as its Compose file is applied.
• Operators who prefer declarative version control, writing monitor definitions into .json or .toml files rather than clicking through a dashboard.
• Administrators who want terminal-driven management, using the Kuma CLI with subcommands such as monitor add and maintenance pause, installed from GitHub Releases, Snap, or Cargo.
• Kubernetes and Docker Swarm users, with the caveat that both sources are supported on an as-is basis.

Getting started

The fastest path is Docker Compose with the image ghcr.io/bigboot/autokuma:latest, setting AUTOKUMA__KUMA__URL, AUTOKUMA__KUMA__USERNAME, and AUTOKUMA__KUMA__PASSWORD to point at your Uptime Kuma instance. Prebuilt binaries for Windows, Linux, and macOS are also published on GitHub Releases, and the Kuma CLI installs through sudo snap install kuma or cargo install --git https://github.com/BigBoot/AutoKuma.git kuma-cli.

How it compares

This registry entry does not provide a list of paid products that AutoKuma replaces, so no commercial comparison is drawn here. Among similar tools, the facts name none: AutoKuma stands alone in this registry, and it complements Uptime Kuma rather than competing with it, since Uptime Kuma remains the instance that stores and evaluates every monitor AutoKuma defines.

When to use it — and when not to

A self-hoster must already run an Uptime Kuma instance with credentials available to AutoKuma, grant the container access to the Docker socket, and provide persistent storage for /data. Anyone who does not use Docker, files, Swarm, or Kubernetes as a monitor source gains nothing here, and anyone who needs a maintained Swarm or Kubernetes integration should be cautious: the README states that those sources are supported on an as-is basis, that the maintainer does not run them, and that they are effectively looking for a maintainer. The project is actively pushed and MIT-licensed, but the Docker provider is clearly the well-trodden path.

version: '3'

services:
  autokuma:
    image: ghcr.io/bigboot/autokuma:latest
    restart: unless-stopped
    environment:
      AUTOKUMA__KUMA__URL: http://uptime-kuma:3001
      AUTOKUMA__KUMA__USERNAME: <username>
      AUTOKUMA__KUMA__PASSWORD: <password>
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - autokuma-data:/data

volumes:
  autokuma-data:

labels:
  kuma.my-app.http.name: "My App"
  kuma.my-app.http.url: "https://my-app.example.com"

<prefix>.<id>.<type>.<setting>: <value>

AUTOKUMA__KUMA__URL=http://localhost:3001
AUTOKUMA__KUMA__USERNAME=<username>
AUTOKUMA__KUMA__PASSWORD=<password>

sudo snap install kuma
# or
cargo install --git https://github.com/BigBoot/AutoKuma.git kuma-cli