More than 80 notification services sit behind device discovery
NetAlertX can send notifications through more than 80 services via Apprise, yet its core job is simpler: find devices, keep an inventory, and report meaningful changes. Scanner plugins can read ARP results, DHCP leases, Pi-hole databases, UniFi controllers, and SNMP-enabled routers. Device history can expose an unfamiliar phone or an address change without agents on every client.
Two synchronization modes extend that inventory beyond one broadcast domain. Remote nodes either push their findings to a hub or let the hub pull them, with push recommended where customer sites block inbound connections. The central instance can filter by site, expose Prometheus metrics, and apply workflows that categorize, unarchive, update, or delete devices. Each isolated network still needs a reachable collector and a deliberate ownership model for synchronized records.
What happened when we ran it
Our sandbox installed 110 Python packages in 53 seconds and used 116 MB on disk. The build completed in another 11 seconds. We tested commit a686a01 in a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. The 49 MB repository had 1,237 files, roughly 157,478 source lines, 8 CI workflow files, a Dockerfile, a Compose file, and a tests directory.
Pytest failed after 55 seconds. It reported 549 passed, 63 failed, 3 skipped, and 118 collection or setup errors out of 730, plus 10 passing subtests. Several workflow cases could not find /data/config/app.conf; three cascade-prevention cases could not import get_array_from_sql_rows from database; a database-cleanup case expected /app/server/plugins/db_cleanup/script.py. One assertion received a MagicMock instead of an empty list. The log names those failures but does not prove why the environment reached them.
Pip-audit also reported 16 known vulnerabilities. The supplied measurement does not list packages, advisory identifiers, or severities, so a buyer should inspect the full audit before deciding whether those findings reach the deployed path. A successful 53-second install and 11-second build show that the source can be assembled in the stated container. They do not cancel the failed backend suite.
Three Linux capabilities are in the default Docker command
The documented container command adds 3 capabilities: NET_RAW, NET_ADMIN, and NET_BIND_SERVICE. It also uses host networking, mounts local time, creates a tmpfs owned by service UID 20211, and persists /data. The data directory must contain separate config and db folders with permissions matched to the runtime user. These are understandable requirements for low-level discovery, but they deserve a stricter threat review than an ordinary web dashboard.
Ports 20211 and 20212 cover the web interface and backend API by default. The README says data stays local unless the operator configures an external notification or integration, while its security section recommends firewall restrictions and an authenticated reverse proxy. That proxy is doing important work because authentication and RBAC are described as external integrations. The Docker guide also warns that initial discovery can take 5 to 10 minutes, so an empty first screen is not necessarily a failed scanner.
Release v26.9.0 moves custom plugin mappings
Release v26.9.0 was published on September 2, 2026 with a breaking directory change: custom plugin mounts must move from /front/plugins to /server/plugins. The release also says old API endpoints are due for removal in the following release and directs users to the newer API. New work included multi-instance Pi-hole monitoring, AdGuard DHCP import changes, UniFi site details, scan pause controls, and revised network-map connections. Those are useful additions, but the upgrade notes need to be part of deployment planning.
The same v26.9.0 release contains fixes for notification time handling, HTML escaping, device-parent status, SMTP recipients, and theme initialization. A frequent release line can reduce exposure to known bugs only when operators read the breaking changes and rebuild promptly. Pinning latest without reviewing a changed Compose file or plugin path is risky here. Keep the persistent config and db directories backed up, pin a tested tag, and rehearse the documented migration before replacing a remote node or central hub.
Nineteen open issues accompany current release activity
The last push and v26.9.0 release both landed on September 2, 2026. GitHub showed 19 open issues and 2 open pull requests when checked. Recent reports included notification-window sizing, an edge case in device naming, and exit-126 container starts on two ARM64-oriented systems. Those issue titles show active user testing across UI, discovery, and deployment paths; they do not establish that every report shares one cause.
GitHub also recorded 7,023 stars, which says less about operational fit than the 730-case test result. The project has current commits, a same-day release, documentation for several deployment types, and an issue queue that is being updated. Community health looks good. Release maturity is more mixed because custom paths moved in v26.9.0, the old API is approaching removal, and our clean-container suite did not pass.
A 116 MB dependency tree buys inventory, not full monitoring
The 116 MB installed footprint buys device discovery, presence history, alerting, workflows, and distributed inventory. It does not replace the metrics depth of Zabbix, the source-of-truth modeling of NetBox, or the traffic analysis of ntopng. NetAlertX is easiest to justify when the question is "what joined or left this network?" and existing monitoring does not answer it cleanly. It can feed a wider stack through webhooks, APIs, Home Assistant, or Prometheus instead of owning every monitoring job.
Our run makes a cautious trial more sensible than an immediate rollout. The install and build succeeded in 64 seconds combined, while pytest finished with 63 failures and 118 errors and the audit found 16 vulnerabilities. Put a pilot on one controlled segment, protect the UI, confirm that its scanner sees the expected VLAN, and test notification noise before adding Sync Nodes. If those checks pass, NetAlertX can fill the asset-awareness gap without pretending to be a SIEM.