Pulse on Ubuntu 24.04 on Azure User Guide

Overview

Pulse is an open-source, lightweight, real-time monitoring dashboard for Proxmox VE and Proxmox Backup Server, and for Docker hosts, Kubernetes, TrueNAS and vSphere. It gives you a single clean web view of your infrastructure: live node, VM and container metrics, storage and datastore capacity, backup and snapshot status, and smart threshold-based alerts, all updating in real time over a WebSocket connection.

Pulse is a single statically-linked Go binary that serves both the REST API and the web UI. The cloudimg image runs it behind nginx as a TLS-terminating reverse proxy: Pulse listens on 127.0.0.1:7655 and is reached through nginx on port 443 (HTTPS), with port 80 redirecting to 443. A local firewall (ufw) admits only SSH, HTTP and HTTPS, so the application port is never exposed directly.

On the first boot of every deployed VM, a one-shot service mints a unique administrator password and a per-VM self-signed TLS certificate, and writes the login to /root/pulse-credentials.txt with mode 0600. Pulse has no default administrator, refuses to start on an empty or example password, and ships with no configured targets and no stored API tokens — you add your own infrastructure on first use. No two deployments share a credential. Backed by 24/7 cloudimg support.

What is included:

• Pulse v6.1.2 (single Go binary at /opt/pulse/bin/pulse) behind an nginx TLS reverse proxy on :443 (Pulse bound to 127.0.0.1:7655)
• A per-VM administrator login and a per-VM TLS certificate generated at first boot, in a root-only file
• pulse.service + nginx.service as systemd units, enabled and active; ufw admitting only 22/tcp, 80/tcp and 443/tcp
• An empty, ready-to-configure data directory (/etc/pulse) — you connect your own Proxmox VE / PBS / Docker targets; nothing is baked into the image
• 24/7 cloudimg support

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; scale up when monitoring many nodes. NSG inbound: allow 22/tcp from your management network and 443/tcp (and 80/tcp for the HTTPS redirect) from the networks your users 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 Pulse 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 HTTPS (443). Then Review + create → Create.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name pulse \
  --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 pulse --port 443 --priority 1010

First-boot initialisation (secret + TLS certificate) takes under a minute after the VM reaches the Running state.

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, and read the per-VM login and service status:

ssh azureuser@<vm-public-ip>

sudo cat /root/pulse-credentials.txt
systemctl is-active pulse nginx pulse-firstboot

The credentials file is unique to this VM and readable only by root:

pulse.url=https://<vm-ip>/
pulse.admin.user=admin
pulse.admin.pass=<PULSE_ADMIN_PASSWORD>

All three services report active:

Step 4 — First sign-in

Open https://<vm-public-ip>/ in your browser. The image ships with a per-VM self-signed certificate, so your browser will warn on first visit — accept it to proceed, or install your own certificate (Step 8). Sign in with the username admin and the password from /root/pulse-credentials.txt.

Because Pulse issues a Secure session cookie, the dashboard is served over HTTPS only — the cloudimg image is configured for TLS out of the box so browser sign-in works immediately.

Once signed in, the dashboard shows your monitored infrastructure in real time — nodes, virtual machines, containers, storage and backups, with live CPU, memory, disk and network metrics:

Step 5 — Add your Proxmox VE / Proxmox Backup Server targets

Pulse ships with no configured targets. To monitor a Proxmox VE or Proxmox Backup Server node, open Settings in the web UI and add the node with a scoped API token:

1. In Proxmox, create a dedicated API token (Datacenter → Permissions → API Tokens) with read-only monitoring privileges.
2. In Pulse, go to Settings → Nodes → Add, enter the node URL (for example https://your-proxmox-host:8006) and paste the API token id and secret.
3. Save. Within a few seconds the node, its VMs/containers and its storage appear on the dashboard with live metrics.

Storing the token in Pulse is safe: the cloudimg image keeps the data directory (/etc/pulse) on the VM only, encrypts node credentials at rest, and never ships them in the image.

Step 6 — Monitor Docker hosts with the Pulse agent

For Docker, Kubernetes or bare host monitoring, install the lightweight Pulse agent on each machine you want to watch. In the web UI, open Settings → Install on a host to generate a ready-to-run install command that includes a scoped reporting token, for example:

curl -fsSL https://your-pulse-host/install.sh | \
  sudo bash -s -- --url https://your-pulse-host --token <api-token> --enable-docker

The agent reports host CPU, memory, disk and network metrics plus per-container statistics back to the dashboard. Docker images, networks and storage are shown with update and health status:

Step 7 — Alerts

Pulse evaluates threshold-based alerts on the metrics it collects (CPU, memory, disk, temperature, backup age and more). Configure alert rules and notification channels (email, webhooks, Discord and others) under Settings → Alerts. Active alerts surface on the Alerts tab and in your chosen notification channels.

Step 8 — Health checks and the REST API

Pulse exposes an open health endpoint for load-balancer probes and an authenticated REST API. Authentication uses a session cookie (browser) or an API token via the X-API-Token header.

curl -k https://127.0.0.1/api/health

{"status":"healthy","timestamp":1786220772,"uptime":1290.3,"dependencies":{"monitor":true,"scheduler":true,"websocket":true}}

curl -k https://127.0.0.1/api/version

{"version":"6.1.2","channel":"stable","deploymentType":"systemd","updateAvailable":false}

A wrong password is refused; the per-VM password issues a Secure, HttpOnly session cookie over TLS:

Once your targets are connected, the resource inventory is available programmatically as live JSON:

Step 9 — Replace the TLS certificate

The image generates a per-VM self-signed certificate at /etc/pulse/tls/. To serve a trusted certificate for your own domain, point DNS at the VM and issue a certificate — for example with certbot for your-domain, then update the nginx site to reference the new certificate and reload nginx:

sudo certbot --nginx -d your-domain
sudo systemctl reload nginx

Step 10 — Security posture

The cloudimg image is secure by default. A unique administrator password is minted per VM into a root-only file, the service refuses to start on a default or empty password, and ufw admits only SSH, HTTP and HTTPS — the application port 7655 is never public:

Backup and maintenance

• Configuration and metrics live under /etc/pulse (node credentials are encrypted at rest). Back up this directory to preserve your targets, alert rules and metrics history.
• OS updates: the base image is fully patched at build time with unattended security upgrades enabled, so security updates continue to apply automatically.
• Application updates: replace the /opt/pulse/bin/pulse binary with a newer release and restart pulse.service, or watch for new versions in Settings.
• Support: every cloudimg deployment is backed by 24/7 support.