Install and first run
From a downloaded package to a first verified path. Nothing is installed on the machines you test.
Pick a package#
| Platform | File | How to run it |
|---|---|---|
| Windows | PathMRI-Setup-win-x64.exe |
Installs to Program Files, with a Start-Menu entry and an uninstaller. The usual choice. |
| Windows, portable | PathMRI-win-x64-portable.zip |
Unzip, run Start PathMRI.cmd. Nothing is written outside the folder and your data directory, and no administrator rights are needed. |
| Linux | PathMRI-linux-x64.tar.gz |
./pathmri.sh, or install the bundled pathmri.service systemd unit. |
| macOS | PathMRI-osx-x64.tar.gz, PathMRI-osx-arm64.tar.gz |
./pathmri.command. It clears the Gatekeeper quarantine flag, because the binaries are unsigned. |
| Docker | the container image | docker run -p 8080:8080 -e PATHMRI_MASTER_KEY=… -v pathmri-data:/data |
Every package is self-contained. There is no runtime to install first — the .NET runtime and the agent binaries for every platform are already inside.
Start it#
A package you launch yourself opens your browser at the right address once the server is listening.
That is suppressed automatically for a Windows service, a systemd unit, a container, or any process
with redirected input. Turn it off explicitly with --no-browser or PATHMRI_NO_BROWSER=1.
Where it listens. http://localhost:5180 natively, and http://0.0.0.0:8080 in the container and
under the shipped systemd unit. Change it with PATHMRI_URL; because the address is passed
explicitly, it overrides ASPNETCORE_URLS.
Where its data lives.
| Platform | Directory |
|---|---|
| Windows | %APPDATA%\PathMRI |
| Linux, systemd | /var/lib/pathmri |
| Container | /data |
| Anywhere | $PATHMRI_DATA_DIR, if you set it |
That directory holds the database, your settings, the data-protection keys, and — unless you supply
PATHMRI_MASTER_KEY yourself — the key that protects stored credentials.
Back up the key with the database. Without it, the credentials in that database cannot be decrypted, and there is no recovery path. This is the one irreversible mistake available here.
First login#
admin / admin, and the first thing it asks for is a new password.
The change is enforced by the server, not just by the screen: until it is done, the account can read
who it is, set a password, and sign out. Everything else answers 403, including the in-browser shell.
admin/admin stops working the moment a real password is set.
If you lock yourself out of the only administrator account, recover on the machine the controller runs on:
PathMRI.Api --reset-admin # back to admin/admin, with the forced change
PathMRI.Api --set-admin-password 'a new password'
Either one edits the database and exits. The server never starts, so neither can be used remotely.
Add the first host#
Hosts & Servers → + Add hosts takes five routes: type one in by hand, sweep a range, paste a list, import a CSV, or pull computer objects from Active Directory. For a first run, add one host by hand.
You need two things: an address the controller can reach it on, and a way in — SSH credentials, WinRM credentials, or nothing at all if you plan to deploy an agent later. See Reaching a host for which to choose and what each can measure.
Two columns on that screen answer different questions, and neither can be read off the other:
- Agent — whether a managed agent is installed and answering, with its version.
- Health — whether the machine itself is reachable, from a background check every 45 seconds.
A host with no agent can be perfectly healthy, and an installed agent can sit on a machine that is down.
The SSH key column shows the host key PathMRI has pinned. The first connection records whatever the host presents. If it ever presents a different one, the connection is refused before your credential is sent, and both fingerprints are shown so you can compare them against your own change record.
Run the first check#
Two ways, and the second is faster the first time.
From the Unified Map. Click a source, click a destination, add the ports, and run. There is no form to fill in and no syntax to remember, and firewalls appear on the map as things you can select rather than gaps between two hosts.
From Run Verification. The ad-hoc panel checks any two endpoints with no rule at all: add a port, pick TCP, UDP or ICMP, add as many as you need, and run them in order. The activity feed stays on screen after the run, because the steps it lists are the evidence for the verdict.
Open a finished row and you get the verdict, the round-trip time, and the path: source, the hops between, destination, with firewalls marked along it.
Turn it into something that repeats#
An ad-hoc answer is true for one minute. A connectivity rule is the same question written down — these sources should reach these destinations on these ports — and it is what scheduled runs re-execute and what drift is measured against. Any result worth keeping can become a rule from the result itself.
Where to go next#
- Reaching a host — agent, agentless or ephemeral, and what each needs.
- Firewalls and cloud policy — connect your firewalls so a blocked port names the rule that stopped it.
- Security and operations — roles, backup, and where every secret is kept.