sebingel
71efcd0ba0
main() read the setting 'PIHOLEAPI_SSL_VERIFY', but config.json defines
the function VERIFY_SSL, so the real key is PIHOLEAPI_VERIFY_SSL.
get_setting_value() returns "" for a key nobody defined, so every Pi-hole
API request got verify="": certificate checks were always off and the
InsecureRequestWarning was suppressed, even when a user had turned on
"Verify SSL". The login request sends the Pi-hole web password to
api/auth. The plugin README and docs/PIHOLE_GUIDE.md used the wrong name
too. test_plugin_conventions.py did not catch it: it only looks at
get_setting_value("X") or <literal>, and this line had no fallback.
Changes:
- test/plugins/test_plugin_conventions.py: new
test_own_setting_keys_exist_in_config. Every literal
get_setting_value('<PREFIX>_X') in a plugin's scripts must name a
setting its own config.json defines; core settings and other plugins'
keys are not checked. Before the fix it fails for exactly one of the 54
plugins: pihole_api_scan.py, get_setting_value('PIHOLEAPI_SSL_VERIFY').
- New test/plugins/test_pihole_api_scan_verify_ssl.py: runs main() with
VERIFY_SSL true and false and checks the verify= value that reaches
requests.post() for api/auth. Only the HTTP call is mocked. It fails
before the fix (verify=None).
- server/plugins/pihole_api_scan/pihole_api_scan.py: main() reads
PIHOLEAPI_VERIFY_SSL.
- server/plugins/pihole_api_scan/README.md and docs/PIHOLE_GUIDE.md name
the setting PIHOLEAPI_VERIFY_SSL.
- docs/PLUGINS_DEV.md, Conventions Checklist: read a setting under the
exact key config.json defines; names the new check.
Impact:
"Verify SSL" now works. The default stays false, so default installs
behave as before. A user who turned it on while Pi-hole uses a
self-signed certificate will now see the login fail, as the setting
description says ("Disable if you are using a self-signed certificate").
Live check against Pi-hole v6.8 behind a proxy with an untrusted
certificate: with "Verify SSL" on the fixed code refused to log in, the
old code logged in and imported 33 entries.
NetAlertX - Network Visibility & Asset Intelligence Framework
NetAlertX is a network visibility and asset intelligence platform for homelabs, IT teams, MSPs, and distributed environments. It provides centralized network visibility and continuous asset discovery across remote sites, VLANs, branch offices, and segmented networks from a single interface.
NetAlertX gives you a real-time source of truth for connected devices, helps identify shadow IT and unauthorized hardware, supports compliance initiatives, and automates operational workflows across distributed customer environments.
Use NetAlertX to spot shadow IT, unauthorized hardware, IPAM drift, and other changes that matter to service teams. With multi-site sync, reporting, workflows, and webhooks, it helps MSPs stay ahead of problems without the overhead of a full NMS or SIEM.
Table of Contents
Quick Start
Warning
Important: If upgrading an older installation read the Migration guide for detailed instructions - it lists each migration scenario by version, so pick the one matching your installed version.
Start NetAlertX in seconds with Docker:
docker run -d \
--network=host \
--restart unless-stopped \
--cap-add=NET_RAW \
--cap-add=NET_ADMIN \
--cap-add=NET_BIND_SERVICE \
-v /local_data_dir:/data \
-v /etc/localtime:/etc/localtime:ro \
--tmpfs /tmp:uid=20211,gid=20211,mode=1700 \
-e PORT=20211 \
-e APP_CONF_OVERRIDE='{"GRAPHQL_PORT":"20214"}' \
ghcr.io/netalertx/netalertx:latest
Note: Your /local_data_dir should contain a config and db folder.
To deploy a containerized instance directly from the source repository, execute the following BASH sequence:
git clone https://github.com/netalertx/NetAlertX.git
cd NetAlertX
docker compose up --force-recreate --build
# To customize: edit docker-compose.yaml and run that last command again
Need help configuring it? Check the usage guide or full documentation.
For Home Assistant users: Click here to add NetAlertX
For other install methods, check the installation docs
|| Docker guide || Releases || Docs || Plugins || Website
Features
Discovery & Asset Intelligence
Continuous monitoring for unauthorized asset discovery, connection state changes, and IP address management (IPAM) drift. Discovery & scan methods include: arp-scan, Pi-hole - DB import, Pi-hole - DHCP leases import, Generic DHCP leases import, UNIFI controller import, SNMP-enabled router import. Check the Plugins docs for a full list of avaliable plugins.
Notification gateways
Send notifications to more than 80+ services, including Telegram via Apprise, or use native Pushsafer, Pushover, or NTFY publishers.
Integrations and Plugins
Feed your data and device changes into Home Assistant, read API endpoints, or use Webhooks to setup custom automation flows. You can also build your own scanners with the Plugin system in as little as 15 minutes.
Workflows
The workflows module automates IT governance by enforcing device categorization and cleanup policies. Whether you need to assign newly discovered devices to a specific Network Node, auto-group devices from a given vendor, unarchive a device if detected online, or automatically delete devices, this module provides the flexibility to tailor the automations to your needs.
MSP & Multi-Site Monitoring
NetAlertX enables centralized monitoring across remote sites and isolated environments through Sync Nodes for VLANs and branch offices, providing unified visibility of assets across multiple networks. It supports NOC-style wallboard dashboards, Prometheus metrics export, workflow automation for device governance, and distributed discovery with centralized alerting for scalable network operations.
Documentation
Explore all the documentation here or navigate to a specific installation option below.
Supported browsers: Chrome, Firefox
- [Installation] Docker
- [Installation] Home Assistant
- [Installation] Bare metal
- [Installation] Unraid App
- [Setup] Usage and Configuration
- [Development] API docs
- [Development] Custom Plugins
Security & Privacy
NetAlertX scans your local network and can store metadata about connected devices. By default, all data is stored locally. No information is sent to external services unless you explicitly configure notifications or integrations.
Compliance & Hardening:
- Run it behind a reverse proxy with authentication
- Use firewalls to restrict access to the web UI
- Regularly update to the latest version for security patches
- Role-Based Access Control (RBAC) via Reverse Proxy: Integrate with your existing SSO/Identity provider for secure dashboard access.
See Security Best Practices for more details.
Designed for MSPs, NOCs & Distributed Networks
NetAlertX supports centralized monitoring across VLANs, branch offices, customer environments, isolated networks, and remote sites.
Using Sync Nodes, distributed collectors securely send device inventory and network visibility data back to a central hub, enabling unified monitoring, alerting, and asset tracking across all locations.
This provides MSPs and NOCs with a single operational view of many independent networks, without requiring direct access or centralized scanning infrastructure.
Common deployments include MSP wallboards, NOC dashboards, multi-site inventory monitoring, and remote office discovery.
FAQ
Q: How do I monitor VLANs or remote subnets?
A: Ensure the container has proper network access (e.g., use --network host on Linux). Also check that your scan method is properly configured in the UI.
Q: What is the recommended deployment for high-availability? A: We recommend deploying via Docker with persistent volume mounts for database integrity and running behind a reverse proxy for secure access.
Q: Will this send any data to the internet? A: No. All scans and data remain local, unless you set up cloud-based notifications.
Q: Can I use this without Docker? A: You can install the application directly on your own hardware by following the bare metal installation guide.
Q: Where is the data stored?
A: In the /data/config and /data/db folders. Back up these folders regularly.
Troubleshooting Tips
- Some scanners (e.g. ARP) may not detect devices on different subnets. See the Remote networks guide for workarounds.
- Wi-Fi-only networks may require alternate scanners for accurate detection.
- Notification throttling may be needed for large networks to prevent spam.
- On some systems, elevated permissions (like
CAP_NET_RAW) may be needed for low-level scanning.
Check the GitHub Issues for the latest bug reports and solutions and consult the official documentation.
Everything else
Get notified what's new
Get notified about a new release, what new functionality you can use and about breaking changes.
Other Alternative Apps
- Fing - Network scanner app for your Internet security (Commercial, Phone App, Proprietary hardware)
- NetBox - The gold standard for Network Source of Truth (NSoT) and IPAM.
- Zabbix or Nagios - Strong focus on infrastructure monitoring.
- Domotz - Commercial network monitoring and remote management platform aimed at MSPs, IT teams, and multi-site environments.
- NetAlertX - The streamlined, discovery-focused choice for real-time asset intelligence and noise-free alerting.
🏗 Contributors
This project would be nothing without the amazing work of the community, with special thanks to:
pucherot/Pi.Alert (the original creator of PiAlert), leiweibau: Dark mode (and much more), Macleykun (Help with Dockerfile clean-up), vladaurosh for Alpine re-base help, Final-Hawk (Help with NTFY, styling and other fixes), TeroRERO (Spanish translations), Data-Monkey, (Split-up of the python.py file and more), cvc90 (Spanish translation and various UI work) to name a few. Check out all the amazing contributors.
Translations
Proudly using Weblate. Help out and suggest languages in the online portal of Weblate.
License
GPL 3.0 | Read more here | Source of the animated GIF (Loading Animation) | Source of the selfhosted Fonts
All product names, logos, and brands are property of their respective owners. All company, product and service names used in this website are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.