Guide

Installing the agent

One command on the server. It opens no listening port, runs without root, and reports within a minute of starting.

Step by step

In the portal, go to Settings → Groups and press Enrol a host. While nothing is monitored yet, the same command is on the first card of Incidents, Hosts and Panel.
Copy the line. It carries a token of its own, it works once, and it is shown once.
Run it on the server. Below is the command as it is published; the portal hands you the same line with the token already in place.
Wait a minute and look under Hosts. The server is there, with its disks, memory, services, containers and certificates already found and already carrying sensible rules.
If it is not there, the installer said why on the terminal it ran on. The two usual answers are a machine with no curl and a token that was already spent.

The command

Add your first server

A minimal Debian or Ubuntu image ships no curl, so install it first: apt-get install -y curl

curl -fsSL https://hopmango.com/install.sh | sh -s -- --token <enrollment token>

The line ends in a placeholder, <enrollment token>: the portal hands you this same line with your own token already in it, on the first screen after you sign up. So do the API and an assistant.

Or fetch the installer with wget, and install nothing at all:

wget -qO- https://hopmango.com/install.sh | sh -s -- --token <enrollment token>

What it will not do

The agent opens no listening port on any code path, so there is nothing new to expose on your firewall. It runs without root. The private key it generates on the host never travels in any request. And nothing in HopMango — no screen, no API call, at any permission — can make it run a program for us.

Each of those is a test that blocks our own releases, not a promise in a brochure. The whole list, in plain words.

Checks you write yourself

Discovery finds what is obvious. The rest goes in the server’s own file, /etc/hopmango/hopmango.conf, which the agent never rewrites: hopmango validate checks it and hopmango reload applies it. An HTTP endpoint, a file, a directory and a PostgreSQL instance are one line each.

check http site with url https://example.com/healthz
check file appconf with path /etc/app/app.conf
check directory spool with path /var/spool/app
check postgres wal with url postgres:///?user=hopmango_agent

Add #match= and a regular expression to the URL — https://example.com/healthz#match=ok — and the body is tested against it. A fragment is the one part of a URL that never reaches the server, so the pattern stays on your machine.

PostgreSQL is the one that needs a hand. The check logs in as the role its target names, not as the user the agent runs as, so it gets a role of its own with nothing but the right to look — three lines somebody with rights on the database runs once:

CREATE ROLE hopmango_agent LOGIN;
GRANT pg_monitor TO hopmango_agent;
-- and in pg_ident.conf, map the agent's OS user to that role (peer, map=)

Program checks — a check that runs a binary — are not available in this version: the agent ships no collector for them, and validation refuses one even on a host whose file enables execution.

The one thing people get wrong

Reusing the same line on a second server. The token works once and is shown once, so the second paste fails with an enrolment error that reads like a broken installer. Take a fresh command from Enrol a host for every machine — and if a paste half-worked, take a fresh one rather than retrying the old.

Where to go next

Then what the agent found, and the wait that keeps it quiet.