From nothing to monitoring, in about a minute.

First run

1. Run the binary. On Windows a console window opens; on Linux it runs in the foreground. On Linux, an ordinary account needs to be allowed to write /var/lib/netriva first; the download page has the line for it.
2. The interface is at http://localhost:8080. It opens automatically on Windows.
3. Sign in with admin / admin. You'll be asked to choose a new password, and nothing else works until you do. Do it straight away: until then, anyone who can reach the port can sign in with the default.
4. Go to Discover, confirm the subnet it suggests, and let it sweep.
5. Tick the devices worth watching and add them. That's it — polling starts immediately.

Where things are kept

Credentials live in a separate file from the config on purpose: it means the config can be copied, diffed, version-controlled or attached to a support ticket without dragging secrets along with it. The diagnostic bundle never reads the credentials file at all.

Command-line options

netriva -listen :8080      override the listen address from config
netriva -config PATH       use a different config.yaml (nothing else moves)
netriva -open=false        don't open a browser on start
netriva -version           print the version and exit

There is no -data flag, and -config only moves config.yaml. The data directory is fixed for the operating system (the table above), so credentials.yaml, the licence, the syslog archive and the instance ID are always read from there. A second copy started with a different -config shares all of them, so it is not an isolated instance.

Adding devices

Three ways, all equivalent — they end up in the same list:

• Discover sweeps a subnet and identifies what it finds by ARP, reverse DNS and MAC vendor lookup. Fastest for a network you've just walked into.
• Add manually when you know exactly what you want and don't want to wait for a sweep.
• Edit config.yaml if you'd rather do it in bulk. The file is re-read without a restart.

Per device you can override the SNMP community and port, the vendor, the SSH user, and which metrics to collect. Overrides apply live.

Which equipment

Anything that answers ping is monitored, and anything that speaks SNMP (v1, v2c or v3) gets interface, CPU and memory figures. With an SSH login saved, NetRiva also works out the make, OS and model, backs up the configuration, and gives the AI assistant a read-only command pack for: Cisco IOS and IOS XE, Arista EOS, Dell OS6 and OS10, Huawei VRP, Extreme ExtremeXOS, MikroTik RouterOS 7, Ubiquiti EdgeSwitch and UniFi switches, TP-Link JetStream, NETGEAR, D-Link, Zyxel, and the pfSense® and OPNsense® firewalls. Mercusys switches have no command line and are monitored by ping and SNMP only. Restoring a configuration is offered for Cisco IOS / IOS XE and Arista EOS.

SNMP

ICMP tells you a device is alive. SNMP tells you what it's doing — interface status, error counters, bandwidth, CPU, memory, disk. It's read-only and worth the five minutes it takes to switch on.

Set a community string in Settings, or per device if they differ. The Help section in the app has the exact enable commands per vendor. A quick check from the monitoring machine:

snmpwalk -v2c -c public 192.0.2.10 sysDescr

If that returns nothing, the device isn't listening, the community is wrong, or a firewall is in the way — in that order of likelihood.

Using Ubiquiti UniFi? See Monitoring UniFi switches and access points.

Syslog

The built-in receiver accepts RFC3164 and RFC5424 on UDP 5514 by default, stores messages with a retention window you set, and gives you search and filtering by host, severity, facility and time.

The receiver is off until you turn it on in Settings. Point your devices at the monitoring machine's IP on port 5514. On Windows, the app offers to open the firewall port for you rather than making you find the right netsh incantation.

5514 needs no special permission. The standard syslog port, 514, is privileged on Linux, so if your devices cannot be told to use another port, set syslog: listen: 0.0.0.0:514 and grant CAP_NET_BIND_SERVICE. Under systemd, add it to the AmbientCapabilities line of the unit below. When you run the binary by hand instead, use:

sudo setcap cap_net_bind_service+ep /usr/local/bin/netriva

Running as a service

Linux — .deb and .rpm packages

The easiest way. The package installs /usr/bin/netriva and the systemd unit below, creates the netriva account and a private /var/lib/netriva, and starts the service, which also starts at boot. On arm64, use the _arm64 file.

Ubuntu, Debian:

curl -LO https://dl.net-riva.com/1.0.5/netriva_1.0.5_linux_amd64.deb
sudo apt install ./netriva_1.0.5_linux_amd64.deb

RHEL, AlmaLinux, Rocky, Fedora:

curl -LO https://dl.net-riva.com/1.0.5/netriva_1.0.5_linux_amd64.rpm
sudo rpm -Uvh netriva_1.0.5_linux_amd64.rpm

To upgrade, run the same two lines with the new release: the service restarts on the new version and keeps your data. Then put the service on your network and sign in, as described under systemd below (the listen line and admin / admin).

Removing the package stops the service and keeps your configuration and data in /var/lib/netriva:

sudo apt remove netriva

sudo rpm -e netriva

To remove the data and the netriva account too, on Ubuntu or Debian:

sudo apt purge netriva

and on RHEL-family systems, after removing the package:

sudo rm -rf /var/lib/netriva
sudo userdel netriva

Linux — systemd

[Unit]
Description=AI NetRiva network monitoring
Documentation=https://net-riva.com/docs/
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=netriva
Group=netriva
ExecStart=/usr/local/bin/netriva -open=false
Restart=always
RestartSec=5
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ProtectKernelTunables=true
ProtectControlGroups=true
RestrictSUIDSGID=true
ReadWritePaths=/var/lib/netriva
AmbientCapabilities=CAP_NET_RAW
CapabilityBoundingSet=CAP_NET_RAW

[Install]
WantedBy=multi-user.target

Save as /etc/systemd/system/netriva.service, then:

sudo install -m 0755 netriva /usr/local/bin/netriva
id netriva >/dev/null 2>&1 || sudo useradd --system --no-create-home --shell /usr/sbin/nologin netriva
sudo install -d -m 0700 -o netriva -g netriva /var/lib/netriva
sudo chown -R netriva:netriva /var/lib/netriva
sudo systemctl daemon-reload
sudo systemctl enable --now netriva

Run these in the folder you unpacked. The first line copies the binary to where the unit expects it. install also gives it the right owner and permissions, and on SELinux systems (RHEL, Alma, Rocky, Fedora) the right label, which mv from your home folder would not. chown -R hands over anything you created by running NetRiva by hand first, so your devices and password carry over.

The service listens on 127.0.0.1:8080, which only this machine can reach. On a server you will usually want it on the network. NetRiva writes /var/lib/netriva/config.yaml on its first start. Change its listen line and restart:

sudo sed -i 's/^listen: 127.0.0.1:8080/listen: 0.0.0.0:8080/' /var/lib/netriva/config.yaml
sudo systemctl restart netriva

Then open http://<server address>:8080 from your PC and sign in with admin / admin. Choose a new password straight away, because the interface is now open to your network. If the server runs a firewall, open TCP 8080 (for example sudo ufw allow 8080/tcp or sudo firewall-cmd --permanent --add-port=8080/tcp && sudo firewall-cmd --reload). Logs: journalctl -u netriva.

Note -open=false. Without it the service tries to launch a browser on a machine that may not have one.

The unit gives NetRiva one capability, CAP_NET_RAW, and nothing else. NetRiva pings with the unprivileged ICMP sockets Linux allows to the groups in net.ipv4.ping_group_range. Ubuntu and Debian switch those off (Ubuntu 24.04 and Debian 12 ship 1 0), and there NetRiva falls back to a raw ICMP socket, which needs that capability. If you remove it on such a machine, every device shows as down, and NetRiva says so in the event log with this fix:

echo 'net.ipv4.ping_group_range = 0 2147483647' | sudo tee /etc/sysctl.d/60-netriva-ping.conf
sudo sysctl --system

If you moved syslog to port 514, add CAP_NET_BIND_SERVICE to both capability lines. NoNewPrivileges=true makes Linux ignore capabilities stored on the binary, so a setcap does nothing under this unit. netriva service unit prints this unit with the path to your copy of the binary.

Uninstall. Stop the service and remove it and the binary:

sudo systemctl disable --now netriva
sudo rm -f /etc/systemd/system/netriva.service /usr/local/bin/netriva
sudo systemctl daemon-reload

This leaves your configuration and data in /var/lib/netriva, and the netriva account, so a later install picks up where you left off. To remove those too:

sudo rm -rf /var/lib/netriva
sudo userdel netriva

Windows

The installer does this for you. Leave Run AI NetRiva as a Windows service ticked (it is by default). It registers a service called NetRiva, starts it, and sets it to start at boot and restart after a failure. You do not need a separate service wrapper.

The service runs as LocalSystem, which can write to %ProgramData%\NetRiva\ and needs no password prompt during install. Its log is service.log in that folder. It is capped at 10 MB: the older part moves to service.log.1 (up to service.log.4), so the log never takes more than 50 MB.

The portable zip cannot be a service (it refuses, because a service runs as LocalSystem from wherever the exe is, and that folder may be writable by anyone). If you installed without the service, run these from an elevated prompt:

netriva service install
netriva service start
netriva service status
netriva service stop
netriva service uninstall

status works without elevation. uninstall leaves your configuration and data alone.

The AI assistant

Off until you add an API key. Pick a provider in Settings, paste your key, and ask questions in the search bar at the top of any page — “which devices are flapping”, “what changed on the core switch this week”.

The key is stored in the credentials file, not the config. Requests go straight from your machine to the provider; they don't pass through us. If you'd rather nothing left the building, point it at a local Ollama instance instead. See Privacy for exactly what's sent where.

There's an optional propose-then-approve mode where the assistant can suggest configuration changes that a human must explicitly apply. It's off by default and should stay off unless you've decided otherwise on purpose.

When something doesn't work

Windows says "Unknown Publisher" or "Windows protected your PC"

Expected: NetRiva is not code-signed yet. A code signing certificate costs money every year, and as a small new product we chose to buy one once NetRiva has its first customers rather than before. Check the download's SHA-256 with Get-FileHash, then click More info and Run anyway. If the box says "SmartScreen can't be reached right now", Windows could not reach Microsoft to look the file up; check the checksum and click Run. The download page walks through every step.

A device shows as down but you can ping it

ICMP is usually the cause. On Linux, check that cat /proc/sys/net/ipv4/ping_group_range is not 1 0 (see Running as a service); on Windows, check that the host firewall isn't blocking outbound echo requests. Some devices also rate-limit ICMP and will drop a fast poll — raise the interval for that device.

SNMP says "does not implement"

That message means the device answered but doesn't expose the OID being asked for, which is normal for consumer kit and some embedded devices. It's different from a timeout, and the app distinguishes the two.

Nothing arrives in syslog

Check in this order: is the firewall open on UDP 5514 (or the port you chose), is the device pointed at the right IP, and is it configured to send at a severity that isn't being filtered out. The in-app troubleshooting tools include a port check that answers the first question in a click.

The interface is slow or freezes

Browsers allow only about six connections per origin, and each open tab holds one for live updates. Close spare tabs. If it persists, send us a diagnostic bundle — Help → Report a bug builds a redacted one and shows you exactly what's in it first.

Upgrading

Stop the app, replace the binary, start it again. Configuration and data are untouched. The app tells you when a new release exists but never installs anything on its own — a monitor that restarts itself mid-show is worse than one that's slightly out of date.

On Linux under the systemd unit, unpack the new release and run this in its folder. The in-app update is switched off there, and says so: the unit makes /usr/local/bin read-only to NetRiva on purpose, because a monitor that can rewrite its own program can make a break-in permanent.

sudo systemctl stop netriva
sudo install -m 0755 netriva /usr/local/bin/netriva
sudo systemctl start netriva