Self-hosted network monitoring means running the software that watches your network on your own hardware, with the data staying on your LAN instead of a vendor's cloud. You get device discovery, uptime checks, and alerts from a box you control, with no external account and no telemetry leaving the building.
What does self-hosted network monitoring actually mean?
Two things separate it from a SaaS dashboard: the software runs on hardware you own, and the data never leaves your network. A cloud monitor pushes findings to someone else's servers; a self-hosted one keeps inventory, history, and alerts on a machine in your rack or on your desk. For a homelab or small office that means no per-device pricing, no account to lose access to, and nothing about your internal topology sitting in a third party's database.
You can assemble this from parts. nmap -sn 192.168.1.0/24 sweeps a subnet for live hosts. A cron job hitting ping or curl on critical boxes gives you crude uptime. Your router's DHCP lease table lists MAC addresses you can look up against the OUI registry to guess a vendor. It works, but you end up gluing scripts together and reading raw output.
What to monitor: uptime, discovery, and alerts
Three jobs cover most of what a homelab needs. Discovery answers "what is on my network right now": every device, its MAC/OUI vendor, hostname via DNS, mDNS or NetBIOS, an OS guess and a device type. Uptime answers "is it still reachable," ideally with history so you can see a pattern rather than a single failed ping. Alerts close the loop, so you know when something new joins the network or a known host drops without watching a screen.
DeviceShelf does all three from one local scan. It discovers and identifies each device, enumerates open ports and services, and runs continuous presence monitoring that fires a new-device alert the moment an unknown MAC appears. It also builds a prioritized security report flagging exposed services like Telnet or RDP and default-credential risks, which is the part hand-rolled scripts rarely cover.
How to run it 24/7 headless
Continuous monitoring only works if it is always on, which means a headless box rather than an app you open. The DeviceShelf server edition is built for that: it ships as a Docker image, a .deb package, or a Windows service, so you can run it on a NAS, a Raspberry Pi, a mini PC or a VM and leave it. Because it needs to see Layer 2 traffic for discovery, run the container with network_mode: host rather than a bridged network.
Set the scan interval to match your network's churn. A stable home LAN is fine every few minutes; a busier office might scan more often. Route alerts to ntfy, Gotify, a webhook or email so the box can tell you what changed while you were away.
If your current setup is Uptime Kuma and you want discovery and identification on top of the uptime checks, the Uptime Kuma alternative comparison lays out where the two overlap and where they differ.
Keeping the data on your own network
The point of self-hosting is control, so check what leaves the box. DeviceShelf is local-first: no account, no telemetry, and the license check works offline. Inventory, history and reports stay on the device. That matters when your network map is something you would rather not hand to a vendor, and it is often the deciding factor for regulated or air-gapped setups.
Querying your network with AI
If you want to ask questions instead of reading tables, the server edition can expose its live inventory to an AI assistant over MCP. The AI part is bring-your-own-key and entirely optional. Point it at Anthropic, OpenAI or a local Ollama model, or skip it. Nothing is sent anywhere unless you turn it on.
The server edition is young but usable, and it is included in the one-time €59 license rather than sold separately. If you want to try the always-on setup first, there is a free 7-day trial, no account needed.