MantisOps · Installation Guide

Installing a Network Probe

Last updated October 2026 · Applies to Mantis360 and MantisNMS

The network probe is the component you install once per site to discover, scan and monitor the devices on that network, with no agent on each device. This guide covers installing it, enrolling it, keeping it updated and removing it.

Overview

One probe serves two products at once:

• Mantis360: network discovery, port and vulnerability scanning, and the other scan jobs you run from the Mantis360 console.
• MantisNMS: the monitoring collector that polls your sensors (SNMP, ping, HTTP and so on) and receives syslog, traps and flows.

The probe runs as a service and connects outbound to MantisOps. It registers under the host's machine name the first time it connects, then shows up in the Customer Portal (Agents & Probes → Deployed devices), in Mantis360 (Settings → Admin → Probes & Updates) and in MantisNMS (Manage → Probes).

Requirements

The probe's main connection is a long-lived WebSocket over port 443. If a proxy or TLS-inspecting firewall sits in the way, exempt these hosts from inspection and allow WebSocket upgrades.

Npcap (Windows, optional)

Windows probes don't need Npcap or any other driver. Without it, port scans use TCP connect scanning. If Npcap is already installed on the probe host, the probe detects it and uses faster SYN scanning instead. The probe never installs Npcap itself. Linux probes use SYN scanning where the system allows it.

Probe Enrollment Code

Probes enroll with the Probe installs enrollment code. The probe install commands in the Customer Portal (Agents & Probes → Network Probe), in Mantis360 (Settings → Admin → Sites → select a site → Probes → Show Install Instructions) and in MantisNMS (Manage → Probes → + Install a probe) already contain it. Account admins and owners can reveal and copy it; see Enrollment Codes for who can see codes and how to rotate or revoke them.

• A probe installed with an enrollment code is approved automatically, in both Mantis360 and MantisNMS. There's no approval queue.
• The probe keeps its code in config.json for good. The probe code can only enroll probes, so a code copied from a probe host can't be used to install agents.
• Your account's default code also works for probes, but use the probe code: it's the one that can't install agents if it's ever copied from a probe host.
• Rotating or revoking the code doesn't disconnect probes that are already installed; it only stops new installs.
• For a probe that belongs to one company, use Portal → Companies → Install → 360 Probe. That command uses the company's probe code, so the probe is tied to that company when it first connects.

In the commands below, replace <YOUR-PROBE-ENROLLMENT-CODE> with your probe code, or copy the ready-made command from the Portal.

Install on Windows

Open PowerShell as Administrator on the probe host and run:

This downloads the signed probe to C:\Program Files\MantisOps\Probe\mantisprobe.exe, writes its config.json, and registers the Windows service MantisProbe ("Mantis Unified Probe"), set to start automatically. The configuration files are locked to SYSTEM and Administrators.

Success looks like:

The probe appears in your probe lists within about a minute.

Prefer to do it by hand? Download https://api.360.mantisops.net/probe/download/mantis-probe-setup.exe, save it as mantisprobe.exe, put a config.json next to it (as in the command above) and run mantisprobe.exe install from an elevated prompt. The install step copies the probe and its config.json to C:\Program Files\MantisOps\Probe.

Install on Linux

Run as root (for example after sudo -i). The first line picks the amd64 or arm64 build automatically.

This installs the probe to /usr/local/bin/mantis-probe, its configuration to /etc/mantis-probe/config.json, and a systemd service mantis-probe that starts at boot and restarts if it stops. Check it with:

config.json

The probe reads config.json from its own folder, or from the path in the MANTIS_CONFIG environment variable (the Linux service sets this to /etc/mantis-probe/config.json). Only serverUrl and token are required; the probe fills in the rest.

The probe's device key is kept separately in identity.json, in the same folder as config.json. Both files hold credentials and are restricted to SYSTEM and Administrators (Windows) or root (Linux). Restart the probe service after editing config.json.

Multiple Probes & Sites

• Install one probe per site, or per routed network segment it can't reach from elsewhere. A probe can scan and poll everything it can reach on its network.
• Each probe registers separately under its host's name. Use the same command at every site; for per-company probes, use each company's command from Portal → Companies → Install.
• In Mantis360, assign probes to sites under Settings → Admin → Sites → select the site → Probes → Assign Existing. In MantisNMS, assign a probe to a site or company to give it that site's default SNMP credentials, and you can set a probe as an HA standby for another: it takes over the primary's sensors if the primary stops checking in.

Approval for Legacy Tenant-ID Probes

Probes installed with an enrollment code don't need approval. Since October 1, 2026 a new probe that uses your tenant ID as its token is refused. A probe that registered with the tenant ID before then and hasn't been approved shows Waiting for approval. It stays connected but receives no scan or deployment jobs, sensors or saved credentials until an admin approves it.

Approve (or reject) it in:

• Customer Portal → Agents & Probes → Deployed devices, Identity column (account admins and owners), or Mantis360 → Settings → Admin → Probes & Updates, for Mantis360 scanning;
• MantisNMS → Probes, for MantisNMS monitoring. MantisNMS approves its collector separately.

Approve only probes you or your team installed, and reject any you don't recognize: an approved probe receives the credentials its jobs use. To avoid approvals altogether, reinstall with the probe enrollment code. New tenant-ID probe installs have been refused since October 1, 2026; probes that are already installed aren't affected.

Updates

• Windows probes update themselves. The service regularly checks for the probe version MantisOps has published, waits until no jobs are running, then installs it and restarts, so an update never cuts a scan short. Auto-update is on by default and can be turned off per probe in Portal → Agents & Probes → Deployed devices (Auto-update column).
• Any probe, including Linux, can be updated on demand: Update next to the probe in the Portal's Deployed devices, or Update all in MantisNMS → Probes when probes are out of date.
• The probe installs signed releases only. It checks each release's signed manifest against MantisOps signing keys built into the probe, and the downloaded file against the manifest, before replacing anything. Unsigned or mismatched files are refused.

Reinstall & Uninstall

Reinstalling

• Windows: remove the service first, then run the install command again. Without this step, install stops with service "MantisProbe" already exists — run 'uninstall' first.
  & "C:\Program Files\MantisOps\Probe\mantisprobe.exe" uninstall
• Linux: stop the service (systemctl stop mantis-probe), then run the install command again.
• The install command writes a fresh config.json, so a reinstalled probe registers as a new probe with a new ID: approved at once with an enrollment code (a reinstall that uses the tenant ID is refused). The old entry stops checking in; delete it from your probe list once the new one is online.

Uninstalling

• From the console: Portal → Agents & Probes → Deployed devices → Uninstall on the probe. This stops and removes the probe service and deletes the probe record. If the host is offline, the uninstall runs when it reconnects. The old install can't register again; a fresh install can.
• On Windows: run the uninstall command above from an elevated PowerShell. It stops and removes the service.
• On Linux: systemctl disable --now mantis-probe, delete /etc/systemd/system/mantis-probe.service, then run systemctl daemon-reload.

Uninstalling removes the service, not the files. To remove everything, delete C:\Program Files\MantisOps\Probe on Windows, or /usr/local/bin/mantis-probe, /usr/local/bin/probe-debug.log* and /etc/mantis-probe on Linux. Delete in the Portal only removes the record: a probe that is still running registers again.

Device Key and Reset Key

Like the agent, each probe gets its own secret key automatically after it has been connected steadily for about 10 minutes (an unapproved probe gets none until it's approved). From then on, a connection as that probe must present the key. The probe list shows Secured, Key pending, Not yet secured or Key mismatch, as described in the agent guide.

Key mismatch means a connection as this probe was refused because it didn't have the key, for example after the host was restored from a backup or image, or its identity.json was lost. If you know why, click Reset key: in the Portal (Deployed devices, Identity column) or on the probe in Mantis360. The probe gets a new key once it reconnects. If you don't know why it happened, check the host first.

MantisNMS keeps a separate collector key for each probe. If MantisNMS → Probes shows a key warning on a probe that was reinstalled or had its configuration reset, use Reset key there. If a probe moves to a new network (new office, ISP or connection), MantisNMS shows New network — credentials withheld: its sensors keep running, but device credentials are held back until you click Trust this network.

Troubleshooting

Logs

The probe writes probe-debug.log next to its program file. It rotates at 10 MB, keeping one older copy as probe-debug.log.1. Set "log": true (and "logLevel": "debug") in config.json for more detail, then restart the service.