Applications Azure

Uptime Kuma on Ubuntu 24.04 on Azure User Guide

| Product: Uptime Kuma on Ubuntu 24.04 LTS on Azure

Overview

Uptime Kuma is a popular open source, self hosted uptime and status monitor with a clean real time dashboard. It watches your websites, APIs and services over HTTP(S), TCP, ping, DNS, push, Docker and gRPC, alerts you through more than ninety notification integrations, and publishes status pages you can share.

The cloudimg image installs Uptime Kuma 1.23.17 from source under /opt/uptime-kuma, runs it as the dedicated uptimekuma system user bound to loopback 127.0.0.1:3001, and fronts it with nginx on port 80. nginx is configured for the socket.io WebSocket traffic the live dashboard relies on and is ready for your TLS certificate.

Secure by default: the image ships with no administrator and no database rows. Your first visit lands on the one screen setup wizard where you create your own admin. A uptime-kuma-firstboot.service oneshot ensures the data directory exists, resolves the instance URL and starts the stack on first boot, then disables itself.

What is included:

  • Uptime Kuma 1.23.17 (MIT) under /opt/uptime-kuma
  • Embedded SQLite database at /var/lib/uptime-kuma/data/kuma.db (no separate database to run)
  • uptime-kuma.service running as uptimekuma, bound to 127.0.0.1:3001
  • nginx reverse proxy on port 80, socket.io / WebSocket aware, ready for TLS
  • uptime-kuma-firstboot.service for first boot data directory + stack start
  • Node.js 20 LTS runtime
  • Ubuntu 24.04 LTS base, fully patched
  • 24/7 cloudimg support, 24h response SLA

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet with a subnet. Recommended VM size: Standard_B2s (Uptime Kuma is lightweight; 4 GB RAM is comfortable for hundreds of monitors).

Step 1: Deploy from the Azure Portal

Search the Marketplace for Uptime Kuma on Ubuntu 24.04, choose your VM size, and attach an NSG that allows TCP 22 (SSH) from your management network and TCP 80 / 443 (the dashboard) from the networks that need it. Front port 80 with TLS in production (see the HTTPS section below).

Step 2: Deploy from the Azure CLI

RG="uptime-kuma-prod"; LOCATION="eastus"; VM_NAME="uptime-kuma-01"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/uptime-kuma-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az network vnet create -g "$RG" --name kuma-vnet --address-prefix 10.80.0.0/16 --subnet-name kuma-subnet --subnet-prefix 10.80.1.0/24
az network nsg create -g "$RG" --name kuma-nsg
az network nsg rule create -g "$RG" --nsg-name kuma-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp
az network nsg rule create -g "$RG" --nsg-name kuma-nsg --name allow-web --priority 110 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 80 443 --access Allow --protocol Tcp
az vm create -g "$RG" --name "$VM_NAME" --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name kuma-vnet --subnet kuma-subnet --nsg kuma-nsg --public-ip-sku Standard

Step 3: Connect via SSH

ssh azureuser@<vm-ip>

Step 4: Verify the services are running

Uptime Kuma listens on loopback 127.0.0.1:3001; nginx fronts the dashboard on port 80 and proxies its WebSocket traffic.

sudo systemctl is-active uptime-kuma nginx
ss -tln | grep -E ':80 |127.0.0.1:3001'
curl -s -o /dev/null -w 'GET /dashboard -> HTTP %{http_code}\n' http://127.0.0.1/dashboard

Both services report active, the Node server is bound to 127.0.0.1:3001, nginx is bound to :80, and the dashboard returns HTTP 200 through nginx.

uptime-kuma.service and nginx.service active, the Node server bound to 127.0.0.1:3001, nginx on port 80, and the dashboard returning HTTP 200

Step 5: Secure by default, no admin ships

Nothing sensitive ships in the image. The SQLite database has zero user rows, so every instance starts at the setup wizard, and the per VM instance info note in /root is root only and contains no credential, only the resolved URL.

sudo sqlite3 /var/lib/uptime-kuma/data/kuma.db 'SELECT COUNT(*) AS users FROM user;'
sudo stat -c '%n perms=%a owner=%U:%G' /root/uptime-kuma-info.txt
sudo grep -E '^UPTIME_KUMA_URL|^NOTE' /root/uptime-kuma-info.txt

The user count is 0, the note is 600 root:root, and it tells you to create your admin at the setup wizard on first visit.

The shipped image has zero users in kuma.db and a root only instance info note that holds no credential, only the resolved dashboard URL

Step 6: Complete the first run setup wizard

Open http://<vm-ip>/ in your browser. Because no administrator ships, Uptime Kuma redirects you to its one screen setup wizard. Choose a language, then enter a Username and a strong Password and click Create. This is where you secure the instance, so pick a real password.

The Uptime Kuma first run setup wizard where you create your own administrator account; no admin ships in the image

After creating the admin you are signed in automatically and land on the dashboard, with Quick Stats across the top and an empty monitor list on the left.

The Uptime Kuma dashboard immediately after creating the administrator, with Quick Stats and an empty monitor list

Step 7: Add your first monitor

Click Add New Monitor. Leave the Monitor Type as HTTP(s), give it a Friendly Name, enter the URL you want to watch, and set the check interval and retries. Then click Save.

The Add New Monitor form with an HTTP(s) monitor for a website, showing friendly name, URL, heartbeat interval and retries

The monitor starts checking immediately. It appears in the list with a live uptime percentage and a heartbeat bar, and the dashboard records the result, for example 200 - OK with an Up status.

The dashboard showing the new monitor live at 100 percent uptime with an Up status and a 200 OK result

Step 8: The runtime stack

node -v
nginx -v
jq -r .version /opt/uptime-kuma/package.json

Node.js 20 LTS runs the server, nginx 1.24 fronts it, and the pinned Uptime Kuma release is 1.23.17.

Node.js 20 LTS, nginx 1.24 and Uptime Kuma 1.23.17, with the prebuilt frontend present and the SPA serving HTTP 200

Step 9: Data and persistence

All monitoring data lives in the embedded SQLite database under /var/lib/uptime-kuma/data, captured into the image and carried onto every instance.

sudo ls -lh /var/lib/uptime-kuma/data/kuma.db
systemctl is-enabled uptime-kuma-firstboot.service
apt-mark showhold

The database file is present, the first boot service is enabled for the next fresh instance, and there are no held packages, so the OS security baseline is intact.

The kuma.db database on disk, the first boot service state, and an intact OS patch baseline with no held packages

Step 10: Enable HTTPS

nginx already fronts Uptime Kuma on port 80 and is ready for TLS. Point a DNS record at your VM, then obtain a certificate with certbot:

sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain> --agree-tos -m <your-email> --redirect

certbot installs the certificate, rewrites the nginx server block for TLS, and sets up automatic renewal. Your dashboard is then served over HTTPS.

Managing the service

sudo systemctl status uptime-kuma
sudo systemctl restart uptime-kuma
sudo journalctl -u uptime-kuma -f

The Node server logs to the journal. nginx logs are under /var/log/nginx/. Back up the instance by snapshotting the OS disk or copying /var/lib/uptime-kuma/data/kuma.db while the service is stopped.

Support

cloudimg provides 24/7 support for this image via email and live chat: deployment, nginx TLS termination, upgrades, notification integrations and performance tuning. Email support@cloudimg.co.uk.

This is a repackaged open source software product with additional charges for cloudimg support services. Uptime Kuma is a trademark of its respective owner. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.