Komari

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a 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.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network. Also allow 80/tcp (plus 443/tcp once you enable TLS) from the networks your users and agents use to reach the dashboard.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Komari by SecureAnyCloud, and select Create.

On the Basics tab, 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 select Review + create and Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:komari-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name komari \
  --image sac1647283583153:komari-ubuntu-24-04:default:latest \
  --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. This is the guard described in the Overview, not a fault.

Step 3 - Connect and retrieve the administrator login

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

ssh azureuser@<vm-public-ip>

On first boot, the per-VM administrator password is written to a root-only file. Read it:

cat /root/komari-credentials.txt

The file shows the dashboard URL, the administrator username and the generated password. Confirm that only root can read it:

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

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

Note on the dashboard URL. The URL in the credentials file is resolved at first boot from the Azure instance metadata service. When the VM's public IP is a Standard-SKU address, the metadata service can return an empty value. In that 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 systemd units make up the appliance. Check that all three report active:

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

Check the server's status and version:

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

Confirm that the dashboard answers through nginx and that the server 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 '

Port 25774 must appear only as 127.0.0.1:25774. The Komari server is never exposed directly, and 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 corner. 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.

Select the node to open its detail view. The full hardware inventory is at the top, with live CPU, memory, disk and network charts below it.

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}'

Then confirm that the administrator credential works 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.

Change the administrator password from Account in the admin panel. If you ever lose the password, reset it from the command line:

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.

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, so never reuse one across machines. Treat every 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. This is Komari's intended design, and it is what makes it useful as a shareable status page.

To keep the metrics private, restrict access in the admin panel under Settings. 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 - Review the 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. Verify it:

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, the agent refuses any remote-exec request against this host.

Leave these flags in place unless you have a specific, considered need for remote shell access. 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 the upstream project documents real-world cases of agents 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 displays a banner warning that the connection is not encrypted. The warning is accurate: do not sign in over the public internet without TLS.

Point a DNS A record at the VM's public IP and allow 443/tcp in the NSG. Then run:

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 makes every sign-in fail. Afterwards, update each agent's -e endpoint to the https:// URL.

Backup and maintenance

All state 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. Stop the service before you back them up, so that 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

You can also 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 the service:

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 systemd journal:

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

Support

Every SecureAnyCloud image comes with 24/7 support. Contact us at sales@secureanycloud.com and include your Azure subscription ID and VM name.

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

Deploy on Azure

Launch Komari on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com