Observability Azure

Komari on Ubuntu 24.04 on Azure User Guide

| Product: Komari on Ubuntu 24.04 LTS on Azure

Overview

Komari is a lightweight, open-source, self-hosted server monitoring dashboard. A central server renders the web dashboard and stores the history, and a small agent on each monitored machine reports CPU, memory, disk, network, load and uptime back to it over a websocket. The result is one live view of every server you run, with per-host detail and historical charts, from a stack small enough to run comfortably on the smallest instance.

This image is the Komari server — the dashboard half. It ships with the Komari agent preinstalled and already registered against its own server, so the dashboard shows real metrics for its own host the moment you sign in, rather than an empty page.

The Komari server is a single static Go binary with an embedded SQLite datastore. The cloudimg image runs it behind nginx as a reverse proxy: the server listens on 127.0.0.1:25774 and is reached through nginx on port 80 (and 443 once you add TLS).

How the first-boot credential works, and why it matters here. Stock Komari ships with no account at all: on a database with no users it serves an unauthenticated setup wizard in which the first visitor to reach the machine becomes the administrator. On an internet-facing VM that is a race. The cloudimg image closes that gap: on the first boot of every deployed VM a one-shot service generates a 32-character administrator password, completes the setup itself over the loopback interface, and only then allows nginx to start serving port 80. There is no window in which the open wizard is reachable from the network, and no shared credential ships in the image. The login is written to /root/komari-credentials.txt with mode 0600. Backed by 24/7 cloudimg support.

What is included:

  • Komari server 1.4.1 (single static Go binary at /opt/komari/komari) behind an nginx reverse proxy on :80, with the server bound to loopback 127.0.0.1:25774
  • Komari agent 1.2.60 (komari-agent.service), preinstalled and auto-registered against this host, running with remote control and auto-update disabled
  • A dedicated Azure data disk at /var/lib/komari holding the SQLite database, the metric store and per-instance state, separate from the OS disk and re-provisioned with every VM
  • Per-VM administrator login generated at first boot, in a root-only file
  • The server running as a dedicated unprivileged komari system account, not root
  • komari.service, komari-agent.service and nginx.service as systemd units, enabled and active
  • 24/7 cloudimg support

Komari sign-in dialog over the live dashboard

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point and comfortably monitors dozens of agents; scale up for a larger fleet or a longer retention window. NSG inbound: allow 22/tcp from your management network and 80/tcp (plus 443/tcp once you enable TLS) from the networks your users and agents reach the dashboard on.

Step 1 — Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Komari by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Review the dedicated data disk on the Disks tab, then Review + create → Create.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name komari \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name komari --port 80 --priority 1010

First-boot initialisation takes under a minute after the VM reaches the Running state. Until it finishes, port 80 deliberately does not answer — that is the guard described in the Overview, not a fault.

Step 3 — Connect and retrieve the administrator login

Connect over SSH as azureuser (or the administrator account you chose) with the VM's public IP:

ssh azureuser@<vm-public-ip>

The per-VM administrator password is written to a root-only file on first boot:

cat /root/komari-credentials.txt

You will see the dashboard URL, the administrator username and the generated password. Confirm the file is readable only by root:

stat -c '%a %U:%G %n' /root/komari-credentials.txt

Retrieving the per-VM Komari administrator credentials over SSH

Store the password in your password manager and treat this file as a secret. Nothing else on the VM holds a copy in plaintext.

Note on the dashboard URL. The URL recorded in the credentials file is resolved at first boot from the Azure instance metadata service. On VMs whose public IP is a Standard-SKU address the metadata service can return an empty value, in which case the image falls back to the VM's private address. If the file shows a private IP, browse to your VM's public IP instead — the dashboard itself is unaffected.

Step 4 — Confirm the services are running

Three units make up the appliance. All three should report active:

systemctl is-active komari.service komari-agent.service nginx.service

Check the server's own status and version:

systemctl status komari.service --no-pager | head -12

Komari, agent and nginx services active on the VM

Confirm the dashboard answers through nginx, and that the server itself is bound only to loopback:

curl -s -o /dev/null -w 'dashboard HTTP %{http_code}\n' http://127.0.0.1/
ss -tln | grep -E ':25774|:80 '

25774 must appear only as 127.0.0.1:25774. The Komari server is never exposed directly; nginx on port 80 is the only public listener.

Step 5 — Sign in to the web dashboard

Browse to http://<vm-public-ip>/ and select Login in the top-right. Sign in with the username and password from /root/komari-credentials.txt.

The dashboard immediately shows this host as a monitored node, because the preinstalled agent was registered during first boot:

Komari dashboard showing the monitored host with live CPU, memory and disk metrics

Select the node to open its detail view — full hardware inventory at the top, and live CPU, memory, disk and network charts below:

Komari server detail view with CPU, memory, disk and network charts drawing live data

You can confirm the same data from the command line. The public node endpoint reports the live inventory:

curl -s -m 10 http://127.0.0.1/api/nodes | jq '.data[0] | {name, os, cpu_name, mem_total}'

And the administrator credential round-trips against the API:

curl -s -m 20 -H 'Content-Type: application/json' \
  -d '{"username":"<KOMARI_ADMIN_USER>","password":"<KOMARI_ADMIN_PASSWORD>","2fa_code":""}' \
  http://127.0.0.1/api/login

A successful sign-in returns a session_token.

Komari health check and authenticated API round trip

Change the administrator password from Account in the admin panel, or from the command line if you ever lose it:

sudo systemctl stop komari
sudo -u komari /opt/komari/komari chpasswd -d /var/lib/komari/data/komari.db -p '<new-password>'
sudo systemctl start komari

Step 6 — Add more servers

Open the admin panel from the top-right menu and choose Server. The node list shows every monitored machine, its address and its agent version:

Komari admin node list showing the registered host and agent version

Select Add to create a node. Komari issues a token for it. On the machine you want to monitor, download the agent and run it against this server with that token:

curl -fsSL -o /usr/local/bin/komari-agent \
  https://github.com/komari-monitor/komari-agent/releases/download/1.2.60/komari-agent-linux-amd64
chmod +x /usr/local/bin/komari-agent

/usr/local/bin/komari-agent \
  -e http://<vm-public-ip> \
  -t <the-token-shown-in-the-dashboard> \
  --disable-web-ssh --disable-auto-update

Each agent needs outbound access to this server on port 80 (or 443 with TLS). Tokens are per-node — never reuse one across machines, and treat a token as a secret.

Step 7 — Choose a public or a private status page

By default Komari's landing page is a public status page: anyone who can reach the VM on port 80 sees the node list and its metrics without signing in. Administration always requires the password, but the metrics themselves are visible. That is Komari's intended design and it is what makes it useful as a shareable status page.

If you would rather keep the metrics private, restrict it in the admin panel under Settings, and pair that with an NSG rule that allows port 80 only from the networks you trust. Decide this before you attach the VM to a public IP — the safest default is to restrict the NSG first and open it up once you have chosen.

Step 8 — Remote-control posture

Komari can run commands on monitored machines through its agent (the Remote Exec section of the admin panel). This image deliberately ships its preinstalled local agent with that capability switched off, along with agent auto-update:

systemctl show -p ExecStart --value komari-agent.service | tr ' ' '\n' | grep -- '--disable'

Both --disable-web-ssh (which disables remote shell and remote command execution) and --disable-auto-update are set. With them in place, a remote-exec request against this host is refused by the agent.

Komari security posture: loopback binding, agent remote control disabled, no swap

Leave these flags in place unless you have a specific, considered need for remote shell access, and apply the same flags to the agents you install on other machines. Komari is a monitoring and control tool; an agent with remote execution enabled is a powerful foothold, and its upstream project documents real-world cases of the agent being abused for exactly that. Restrict who can reach the admin panel accordingly.

Enabling HTTPS

Serve the dashboard over TLS as soon as it has a DNS name. Over plain HTTP, Komari itself displays a banner warning that the connection is not encrypted — the warning is accurate, and browser sign-in over the public internet should not be done without TLS.

Point a DNS A record at the VM's public IP, allow 443/tcp in the NSG, then:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d komari.your-domain.com --redirect --agree-tos -m you@your-domain.com

Certbot edits the nginx site in place and installs a renewal timer. Keep the existing proxy_set_header Host $http_host; line: Komari compares the request Origin against the forwarded Host, and a proxy that drops the port from Host will make every sign-in fail. Update each agent's -e endpoint to the https:// URL afterwards.

Backup and maintenance

Everything stateful lives on the dedicated data disk at /var/lib/komari:

ls -la /var/lib/komari/data/

komari.db is the main SQLite database (accounts, nodes, tokens, settings) and metrics.db holds the metric history. Back them up with the service stopped so SQLite is quiescent:

sudo systemctl stop komari
sudo tar czf /root/komari-backup-$(date +%F).tar.gz -C /var/lib/komari data
sudo systemctl start komari

Snapshot the Azure data disk on a schedule for a point-in-time copy of the same content.

The OS applies security updates through unattended-upgrades. To move to a newer Komari release, replace the binary and restart:

sudo systemctl stop komari
sudo curl -fsSL -o /opt/komari/komari \
  https://github.com/komari-monitor/komari/releases/download/<version>/komari-linux-amd64
sudo chmod 755 /opt/komari/komari
sudo systemctl start komari

Take a backup first, and check the upstream release notes for migration steps. Logs are in the journal:

journalctl -u komari.service --no-pager | tail -20

Support

Every cloudimg image is backed by 24/7 support. Contact us at support@cloudimg.co.uk with your Azure subscription ID and VM name.

Komari is open-source software licensed under the MIT Licence. Upstream project documentation is at komari-document.pages.dev and the source is at github.com/komari-monitor/komari. cloudimg packages, hardens and supports the image; it is not affiliated with the Komari project.