InfraNestInfraNest
Metrics & alerts

Install the server agent, step by step

This walks through installing the InfraNest agent on one server, from getting a token to seeing the numbers arrive. It takes about two minutes per server.

Updated October 21, 20267 min read

Install the InfraNest agent on a server to start collecting memory, disk space and load readings. It takes about two minutes per server, and this article walks through the whole thing — written for anyone with administrator access to the machine, not just engineers.

#Overview

  • The agent runs on your server and sends InfraNest the numbers behind the graphs and alerts.
  • Installing takes one copy-pasted command and a token created for that one server.
  • It only needs to reach InfraNest on port 443, outbound — nothing has to be opened to the server, and no firewall rule changes.
  • If you'd rather understand why you'd install it before doing so, read "Get memory, disk space and load with the agent" first.

#Before you start

Make sure you have:

  1. A server already added in InfraNest. If not, add it under Infrastructure → Servers.
  2. Administrator access to that server — sudo on Linux, an Administrator PowerShell on Windows. You only need this once, to install; the agent does not keep running as an administrator afterwards.
  3. Outbound internet access on port 443 from the server. Nothing needs to be opened to the server.

#Get the install command

  1. Choose Install the agent. You'll find this on the server's row under Servers, in the server's actions menu, or next to any alert rule that's greyed out because it needs the agent. All three open the same window.
  2. You won't be asked for anything — a token is created immediately. Afterwards, each token in the list shows who added it, when, and when it was last used.
  3. The token is shown once, with a ready-made install command underneath that already has the token filled in.
  4. Pick the tab for your system and copy the command.
Install the server agent, step by step

WarningKeep one token to one server. If two machines share a token, their readings blend into a single set of graphs, nothing warns you, and the "server has gone quiet" alert can never fire — whichever machine is still running keeps checking in for both.

#Run the install command

#Ubuntu and Debian

Paste the copied command into a terminal on that server. It looks like this:

curl -fsSL https://get.infranest.io/agent.sh | sudo sh -s -- --token sat_YOUR_TOKEN

Tested on Ubuntu 20.04, 22.04, 24.04, and Debian 11 and 12.

#RHEL, Rocky, AlmaLinux, CentOS Stream, Fedora

Use the exact same command. The installer downloads a single file and sets up a service for it, so it doesn't matter which of these you're running. If curl is missing, install it first with sudo dnf install curl.

#Windows Server

Open PowerShell as Administrator and run:

irm https://get.infranest.io/agent.ps1 -OutFile install.ps1
.\install.ps1 -Token sat_YOUR_TOKEN

Tested on Windows Server 2019 and 2022. It installs to C:\Program Files\InfraNest and runs as a scheduled task named InfraNest agent.

#A server without systemd

Alpine, Gentoo, Artix and Void are set up automatically on agent version 0.14 or newer — the installer adds a service that starts at boot and restarts if it stops.

On anything else, such as a container, the installer places the files but can't set up a service itself. You'll need to run infranest-agent run under whatever supervisor your system uses, keeping it running continuously rather than as a scheduled job.

#Check it worked

In InfraNest: wait about a minute, then reload the server's page. Memory, disk space and load average start filling in, the coverage badge changes to Agent, and any alert rules that needed the agent become available.

On the server, if you'd rather check locally:

sudo infranest-agent status
& "C:\Program Files\InfraNest\infranest-agent.exe" status

This tells you whether readings are being delivered, and if not, why — without contacting InfraNest.

Notesudo is required because the config file holds a credential and only the agent's own user can read it. Without it, you'll see an error about a missing token rather than about permissions.

#Review the script before running it

If you'd rather not pipe a script straight into a shell, download it first, check it, and run it separately:

curl -fsSL -o install.sh https://get.infranest.io/agent.sh
sha256sum install.sh        # compare with the checksum shown in InfraNest
less install.sh             # about 200 lines
sudo sh install.sh --token sat_YOUR_TOKEN

The checksum shown next to the command in InfraNest matches the one published with the release, so comparing them is a genuine check. The script itself isn't the agent — it downloads a versioned file and verifies that against its own published checksum before installing it.

#Checking who built it

A checksum proves the download arrived intact, but not that it came from InfraNest. Every release also carries a signed build record. If the server has the GitHub CLI (gh) or cosign installed, the installer checks this automatically, printing built by …/release.yml when it matches, and refusing to install anything that doesn't. If neither tool is present, it says so and carries on.

To check by hand, with no account needed:

V=$(curl -fsSL https://get.infranest.io/releases/latest)
curl -fsSLO https://get.infranest.io/releases/download/$V/infranest-agent_linux_amd64
curl -fsSLO https://get.infranest.io/releases/download/$V/infranest-agent.sigstore.json
gh attestation verify infranest-agent_linux_amd64 \
  --repo InfraNest-Infrastructure-Organized/infranest-agent \
  --signer-workflow InfraNest-Infrastructure-Organized/infranest-agent/.github/workflows/release.yml \
  --bundle infranest-agent.sigstore.json

Change linux_amd64 to match your server (linux_arm64 for ARM). Releases from before this was added don't include the signed record file.

#Keep the token out of your shell history

A command line ends up in ~/.bash_history and is visible while it runs. On a shared machine, use a file instead:

printf '%s' 'sat_YOUR_TOKEN' | sudo tee /root/token >/dev/null
sudo sh install.sh --token-file /root/token && sudo shred -u /root/token

#Update the agent

InfraNest tells you when an update is available: the server's System card shows the agent version, and the fleet table marks older servers with an update badge. Clicking either shows the command to run, ready to copy.

On Linux:

curl -fsSL https://get.infranest.io/agent.sh | sudo sh -s -- --upgrade

On Windows, in an Administrator PowerShell:

irm https://get.infranest.io/agent.ps1 -OutFile install.ps1
.\install.ps1 -Upgrade

This downloads the new version, checks it, and restarts the agent without a token, leaving your settings exactly as they were.

A badge that says security instead of update means the version is older than the oldest one still supported — do it soon.

WarningDon't update by running your original install command again. That performs a fresh install, which needs the token again and resets the agent's settings to their defaults.

#Remove the agent

sudo sh install.sh --uninstall
.\install.ps1 -Uninstall

This removes the service, the user, the file, the config, and the stored readings. Deleting the token in InfraNest on its own does not uninstall anything — it only stops the readings being accepted, while the agent keeps running and retrying until it's removed from the machine.

#Troubleshooting

What you see What it means
curl: (60) SSL certificate problem The server's security certificates are out of date. Install ca-certificates and retry.
Install finishes, nothing appears in InfraNest Wait 90 seconds, then run sudo infranest-agent status — it names the reason.
status says the token was rejected The token was deleted in InfraNest, or copied from a different server. Create a new one on the right server and reinstall.
status says monitoring is switched off Monitoring is deactivated for that server in InfraNest. Turn it back on there.
status says the clock is off The server's time is wrong, so readings are refused. Turn on automatic time sync on the server.
Memory and disk arrive, processes do not Process reporting is off by default on purpose, since command lines can contain passwords. See the Processes & services tab on the server to turn it on.
Nothing at all, and status can't read the config Run it with sudo — the config is only readable by the agent's own user.

If none of those fit, run sudo infranest-agent flare. It prints everything needed for a support conversation — version, configuration, state, what couldn't be read — with the token removed. Paste that into a ticket rather than your config file.

If the agent was working and has since gone quiet, see the article on a server that stopped reporting.

Related articles

Try this in your own account

Connect one provider and work through these steps against your own infrastructure.

Free plan · No credit card required · Set up in minutes