NetAlertX mit Docker Compose betreiben: unbekannte Geräte im Netzwerk erkennen

Die Frage, welche Geräte eigentlich im Firmennetz hängen, lässt sich in vielen kleinen Unternehmen nicht sicher beantworten. Auf dem Papier stehen zwölf Arbeitsplätze, ein Server und zwei Drucker. Tatsächlich hängen dort noch ein privates Tablet, ein vergessener Netzwerkschalter aus dem Lager, eine IP-Kamera vom Vorbesitzer der Räume und der Laptop eines Dienstleisters, der letzte Woche da war.

NetAlertX beantwortet diese Frage automatisch. Das Werkzeug durchsucht die konfigurierten Netzbereiche regelmäßig per ARP und weiteren Verfahren, führt eine Liste aller je gesehenen Geräte und meldet jedes neue Gerät. Diese Anleitung führt durch die vollständige Einrichtung per Docker Compose, und sie nennt die Stolpersteine, die im praktischen Testlauf für diesen Artikel tatsächlich aufgetreten sind.

Was NetAlertX leistet und wo die Grenzen liegen

NetAlertX, früher unter dem Namen PiAlert bekannt, ist eine Weboberfläche zur fortlaufenden Erfassung von Netzwerkgeräten. Es führt ARP-Scans durch, kann zusätzlich per nmap, nbtscan, Avahi und DNS-Abfragen Namen ermitteln, speichert jedes gefundene Gerät mit Adresse, Hardwareadresse und Hersteller und protokolliert, wann ein Gerät online und offline war. Neue Geräte lösen eine Meldung aus, wahlweise per E-Mail, Push-Dienst oder über weitere angebundene Kanäle.

Das Projekt wird unter github.com/netalertx/NetAlertX entwickelt und steht unter der GPL-3.0. Zum Abrufzeitpunkt am 13. September 2026 zählt das Repository 7.114 Sterne, der letzte Push stammt vom 11. September 2026, die aktuelle Veröffentlichung ist v26.9.0 vom 2. September 2026. Das Projekt ist damit aktiv gepflegt.

Die Grenzen sind klar zu benennen. NetAlertX ist kein Schwachstellenscanner und kein System zur Angriffserkennung. Es sagt, dass ein unbekanntes Gerät da ist, nicht, ob es gefährlich ist. Es erkennt nur Geräte in den Netzbereichen, die es selbst erreichen kann. Ein Gerät in einem anderen VLAN ohne Weiterleitung bleibt unsichtbar, sofern nicht eine zweite Instanz oder eine entsprechende Netzwerkanbindung eingerichtet wird. Und der Betrieb auf einem Windows-Host ist laut Projektdokumentation nicht unterstützt, weil der benötigte Netzwerkmodus dort fehlt.

Eine weitere Einschränkung betrifft moderne Endgeräte: Mobiltelefone und Tablets wechseln ihre Hardwareadresse aus Datenschutzgründen häufig. Solche Geräte tauchen deshalb regelmäßig als vermeintlich neue Geräte auf. Das ist kein Fehler, erfordert aber eine bewusste Konfiguration, sonst ertrinkt man in Meldungen.

Voraussetzungen und Ressourcen

• Ein Linux-Host mit Docker Engine und Compose-Plugin. Die Beispiele wurden mit Docker 29.1.3 und Compose 2.40.3 unter Ubuntu geprüft.
• Der Host muss im selben Netzsegment hängen wie die zu überwachenden Geräte. ARP-Anfragen werden nicht über Router weitergeleitet.
• Der Container braucht den Netzwerkmodus host. Ein Betrieb im normalen Bridge-Netzwerk funktioniert für den ARP-Scan nicht.
• Arbeitsspeicher: Das offizielle Compose-Beispiel setzt eine Obergrenze von 2 GB und eine weiche Grenze von 1 GB. Im Testlauf blieb der Verbrauch deutlich darunter, die Grenze fängt aber Ausreißer bei großen Netzen ab.
• Speicherplatz: Die Datenbank wuchs im Testlauf nach dem ersten vollständigen Scan auf rund 500 KB. Bei vielen Geräten und langer Ereignishistorie sind einige hundert Megabyte einzuplanen.
• Unterstützte Architekturen: Es gibt Abbilder für amd64 und arm64, der Betrieb auf einem Kleinrechner ist damit möglich.

Installation mit Docker Compose

Zuerst das Verzeichnis anlegen:

sudo mkdir -p /opt/netalertx
cd /opt/netalertx

Dann die Datei compose.yaml erstellen. Sie folgt dem offiziellen Beispiel aus der Projektdokumentation, mit fester Version statt latest:

services:
  netalertx:
    image: ghcr.io/netalertx/netalertx:26.9.0
    container_name: netalertx
    network_mode: host
    read_only: true
    cap_drop:
      - ALL
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - NET_BIND_SERVICE
      - CHOWN
      - SETUID
      - SETGID
    sysctls:
      net.ipv4.conf.all.arp_ignore: 1
      net.ipv4.conf.all.arp_announce: 2
    volumes:
      - netalertx_data:/data
      - /etc/localtime:/etc/localtime:ro
    tmpfs:
      - "/tmp:mode=1700,uid=0,gid=0,rw,noexec,nosuid,nodev"
    environment:
      PORT: "20211"
      GRAPHQL_PORT: "20212"
      TZ: Europe/Berlin
    mem_limit: 2048m
    mem_reservation: 1024m
    pids_limit: 512
    restart: unless-stopped
    logging:
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  netalertx_data:

Die wichtigsten Angaben im Einzelnen:

• network_mode: host ist zwingend. Der Container nutzt die Netzwerkschnittstellen des Hosts direkt, weil ARP-Scans auf der zweiten Netzwerkschicht arbeiten und ein Bridge-Netzwerk das verhindert.
• read_only: true macht das Dateisystem des Containers schreibgeschützt. Alles Veränderliche liegt im Volume unter /data und im Arbeitsspeicher unter /tmp.
• cap_drop: ALL entzieht dem Container zunächst alle Sonderrechte, danach werden nur die nötigen einzeln zurückgegeben. Das ist deutlich sicherer als der Betrieb mit vollen Rechten.
• NET_ADMIN und NET_RAW werden für die Rohsockets von arp-scan, nmap und nbtscan gebraucht.
• NET_BIND_SERVICE erlaubt das Belegen privilegierter Ports, was nbtscan benötigt.
• CHOWN, SETUID und SETGID braucht der Startvorgang, um die Rechte im Datenverzeichnis zu setzen und anschließend auf einen unprivilegierten Benutzer zu wechseln.
• Die beiden sysctls mindern das sogenannte ARP-Flux, also mehrdeutige ARP-Antworten bei mehreren Schnittstellen im selben Netz. Wenn die Umgebung das Setzen von sysctls unterbindet, kann der Block entfallen und die Werte werden stattdessen auf dem Host gesetzt.
• Das tmpfs für /tmp ist wegen des schreibgeschützten Dateisystems nötig. Dort liegen Protokolle und Zwischenstände, die einen Neustart nicht überleben müssen.

Dann starten:

sudo docker compose up -d

Funktionsprüfung

Die folgenden Prüfungen wurden für diese Anleitung tatsächlich durchgeführt.

Zustand des Containers:

sudo docker compose ps

Ergebnis aus dem Testlauf:

NAME        IMAGE                                SERVICE     STATUS
netalertx   ghcr.io/netalertx/netalertx:26.9.0   netalertx   Up 29 seconds (healthy)

Da der Container im Host-Netzwerkmodus läuft, zeigt die Spalte für die Ports nichts an. Das ist normal und kein Fehler.

Erreichbarkeit der Oberfläche prüfen:

curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" -L http://127.0.0.1:20211/

Im Testlauf antwortete der Server mit einer Weiterleitung und lieferte am Ziel den Code 200 für die Geräteübersicht. Ein direkter Aufruf der Wurzeladresse gibt den Code 302 zurück, auch das ist erwartetes Verhalten.

Der Protokollauszug beim Start zeigt die geladenen Erweiterungen:

sudo docker logs netalertx --tail 50

Im Testlauf erschien unter anderem die Zeile mit der Liste der zu ladenden Erweiterungen, darunter ARPSCAN für den Netzwerkscan, NSLOOKUP und DIGSCAN für die Namensauflösung, CSVBCKP für die Sicherung der Geräteliste und NTFPRCS für die Verarbeitung von Benachrichtigungen. Außerdem meldete der Start die erfolgreiche Aktualisierung der Herstellerdatenbank mit 115.864 Einträgen.

Scan-Bereiche konfigurieren

NetAlertX ermittelt beim ersten Start selbst, welche Netzbereiche an den Schnittstellen des Hosts hängen, und trägt sie in die Konfiguration ein. Der Eintrag lässt sich einsehen:

sudo docker exec netalertx grep SCAN_SUBNETS /data/config/app.conf

Die automatische Erkennung ist bequem, aber sie ist auch die häufigste Ursache für Probleme. Im Testlauf trug NetAlertX neben dem eigentlichen Netz auch zwei interne Docker-Bridge-Netze mit der Präfixlänge 16 ein. Ein Netzbereich dieser Größe umfasst 65.534 mögliche Adressen. Der ARP-Scan lief daraufhin in seine Zeitbegrenzung:

[ARPSCAN] arp-scan timed out after 300s

Der Scan lieferte danach trotzdem die 36 Geräte aus dem realen Netz, aber erst nach fünf Minuten statt nach wenigen Sekunden. Die Lösung besteht darin, die Netzbereiche von Hand auf das zu setzen, was wirklich überwacht werden soll. Das geschieht entweder in der Weboberfläche unter den Einstellungen oder direkt in der Konfigurationsdatei:

SCAN_SUBNETS=['192.168.10.0/24 --interface=eth0']

Mehrere Netze werden als weitere Einträge in der Liste ergänzt, jeweils mit der passenden Schnittstelle. Die Schnittstellenbezeichnung findet sich mit:

ip -br addr

Nach einer Änderung an der Konfigurationsdatei den Container neu starten:

sudo docker compose restart

Erster Scan und Ergebnis

NetAlertX startet den ersten Scan nicht sofort, sondern nach dem eingestellten Zeitplan. Im Testlauf vergingen zwischen dem Start und dem ersten ausgeführten ARP-Scan rund drei Minuten. Vorher meldete der Ablaufplaner mehrfach, dass der Scan noch nicht ausgeführt wird. Das ist erwartetes Verhalten und kein Fehler, führt aber leicht zu dem Eindruck, das Werkzeug funktioniere nicht.

Nach dem ersten vollständigen Durchlauf meldete das Protokoll im Testlauf:

[ARPSCAN] Found: Devices without duplicates  36
[Plugins] SUCCESS for ARPSCAN received 36 entries
[Scan Stats] Devices Detected.......: 38
[Scan Stats] New Devices............: 38
[Process Scan] Creating new devices

Die Zahlen unterscheiden sich, weil neben dem ARP-Scan weitere Quellen einfließen. Die Prüfung in der Datenbank bestätigte 38 angelegte Geräte mit Adresse, Hardwareadresse und aufgelöstem Hersteller. Die Herstellererkennung funktionierte dabei zuverlässig und ordnete gefundene Geräte unter anderem Netzwerk-, Speicher- und Druckerherstellern zu.

Die Abfrage der Datenbank direkt im Container:

sudo docker exec netalertx python3 -c "
import sqlite3
c = sqlite3.connect('/data/db/app.db')
print('Geraete:', list(c.execute('select count(*) from Devices'))[0][0])
"

Benachrichtigungen einrichten

Der eigentliche Nutzen entsteht erst mit einer Meldung bei neuen Geräten. In der Standardkonfiguration sind alle Kanäle deaktiviert. Die Konfigurationsdatei zeigt das für den Push-Dienst ntfy beispielhaft:

NTFY_RUN='disabled'  # use 'on_notification' to enable
NTFY_HOST='https://ntfy.sh'
NTFY_TOPIC='replace_my_secure_topicname_91h889f28'

Für die Einrichtung gilt: Die Werte über die Weboberfläche unter den Einstellungen setzen, nicht in der Datei, weil die Oberfläche zusätzlich die Gültigkeit prüft und der Dienst die Datei bei eigenen Änderungen neu schreibt. Wer einen eigenen ntfy-Server betreibt, trägt dessen Adresse statt des öffentlichen Dienstes ein und wählt ein Thema, das nicht erratbar ist.

Ein Hinweis zur Praxis: Vor dem Aktivieren der Benachrichtigungen sollte der erste vollständige Scan abgeschlossen und die gefundenen Geräte einmal durchgesehen und als bekannt markiert worden sein. Sonst kommt beim Einschalten eine Meldung für jedes bereits vorhandene Gerät.

Der Aufbewahrungszeitraum für Ereignisse steht standardmäßig auf 90 Tage:

DAYS_TO_KEEP_EVENTS=90

Absicherung und Netzwerkfreigabe

Die Weboberfläche hat nach der Installation keine Anmeldung. Da sie eine vollständige Karte des Netzwerks mit allen Geräten und Herstellern zeigt, ist das eine ernstzunehmende Informationsquelle für Angreifer. Die Oberfläche gehört deshalb unter keinen Umständen ungeschützt ins Internet.

Wegen des Host-Netzwerkmodus lässt sich der Dienst nicht wie üblich über die Portangabe an 127.0.0.1 binden. Stattdessen gibt es die Variable für die Bindeadresse:

    environment:
      LISTEN_ADDR: "127.0.0.1"
      PORT: "20211"

Damit ist der Dienst nur noch lokal erreichbar, und der Zugriff läuft über einen SSH-Tunnel oder einen Reverse Proxy auf demselben Host. Eine Beispielkonfiguration für Caddy mit Anmeldung:

netz.example.de {
    basic_auth {
        admin $2a$14$HierDenErzeugtenHashEinsetzen
    }
    reverse_proxy 127.0.0.1:20211
}

Den benötigten Hash erzeugt Caddy selbst:

caddy hash-password --plaintext 'IhrPasswort'

Zusätzlich bringt NetAlertX eine eigene Passwortfunktion mit, die in der Weboberfläche unter den Einstellungen aktiviert wird. Beide Wege lassen sich kombinieren. Wer eine zentrale Anmeldung betreibt, findet in der Projektdokumentation außerdem eine Anleitung für die Anbindung an Authelia.

Die Firewall sollte den Port zusätzlich absichern. Bei Host-Netzwerkmodus greifen Regeln der Host-Firewall im Gegensatz zu veröffentlichten Container-Ports normal:

sudo ufw deny 20211/tcp
sudo ufw deny 20212/tcp

Persistente Daten und Rechte

Alle dauerhaften Daten liegen im Volume unter /data, aufgeteilt auf zwei Verzeichnisse. Der Inhalt nach dem Testlauf:

sudo docker exec netalertx ls -la /data/db /data/config

Ergebnis aus dem realen Lauf, gekürzt:

/data/config:
-rw-r--r-- 1 netalertx netalertx 4457 app.conf
-rw------- 1 netalertx netalertx 4450 app.conf_old_setting_names_20260913052659.bak

/data/db:
-rw-r--r-- 1 netalertx netalertx  532480 app.db
-rw-r--r-- 1 netalertx netalertx   32768 app.db-shm
-rw-r--r-- 1 netalertx netalertx 4124152 app.db-wal

Die Sicherungsdatei mit dem Zeitstempel legt NetAlertX selbst an, wenn es beim Start alte Einstellungsnamen auf neue übersetzt. Das ist ein Zeichen dafür, dass die Migration gelaufen ist.

Die Dateien mit den Endungen -shm und -wal gehören zur Schreibprotokollierung der Datenbank und müssen bei einer Sicherung mitgenommen werden. Der Dienst läuft im Container unter einem eigenen unprivilegierten Benutzer mit der Kennung 20211. Wer statt des benannten Volumes ein Hostverzeichnis einbindet, muss die Rechte entsprechend setzen:

sudo mkdir -p /opt/netalertx/data
sudo chown -R 20211:20211 /opt/netalertx/data

Backup und Wiederherstellung

Die Projektdokumentation nennt vier wichtige Bestandteile: die Datenbank unter /data/db/app.db, die Konfiguration unter /data/config/app.conf, die Geräteliste als CSV-Datei und die Datei mit den Arbeitsabläufen. Sie weist zusätzlich darauf hin, dass sich Datenbankdefinitionen zwischen Versionen ändern können und eine Sicherung deshalb am sichersten mit derselben Version zurückgespielt wird, mit der sie erstellt wurde.

Für die Praxis genügt die Sicherung des gesamten Volumes. Der folgende Befehl wurde im Testlauf ausgeführt und erzeugte ein Archiv von rund 202 KB:

sudo docker run --rm \
  -v netalertx_netalertx_data:/data \
  -v /var/backups:/backup \
  alpine tar czf /backup/netalertx-$(date +%F).tgz -C /data .

Für eine konsistente Sicherung ist es sauberer, den Container vorher kurz anzuhalten, weil die Datenbank sonst in einem nicht abgeschlossenen Zustand gesichert werden kann. Die Projektdokumentation weist ausdrücklich auf dieses Risiko hin:

cd /opt/netalertx
sudo docker compose stop
sudo docker run --rm \
  -v netalertx_netalertx_data:/data \
  -v /var/backups:/backup \
  alpine tar czf /backup/netalertx-$(date +%F).tgz -C /data .
sudo docker compose start

Die Wiederherstellung läuft in umgekehrter Reihenfolge:

cd /opt/netalertx
sudo docker compose down
sudo docker volume rm netalertx_netalertx_data
sudo docker volume create netalertx_netalertx_data
sudo docker run --rm \
  -v netalertx_netalertx_data:/data \
  -v /var/backups:/backup \
  alpine tar xzf /backup/netalertx-2026-09-13.tgz -C /data
sudo docker compose up -d

Nach dem Start prüfen, ob die Geräteanzahl der Sicherung entspricht. Wichtig: Die Version im Abbild muss zu der Version passen, mit der gesichert wurde. Ein Rückspielen einer alten Sicherung in eine deutlich neuere Version kann an geänderten Datenbankdefinitionen scheitern.

Ergänzend legt die eingebaute CSV-Sicherung eine Datei mit allen Geräten unter /data/config ab. Diese Datei ist auch ohne NetAlertX lesbar und eignet sich als zusätzliche, formatunabhängige Sicherung der Gerätezuordnung. Sie enthält allerdings keine historischen Daten.

Updates und Rollback

Der Ablauf für ein Update:

cd /opt/netalertx
sudo docker compose stop
# Sicherung wie oben anlegen
# image-Zeile in compose.yaml auf die neue Version aendern
sudo docker compose pull
sudo docker compose up -d
sudo docker logs -f netalertx --tail 50

Beim ersten Start nach einem Update übersetzt NetAlertX gegebenenfalls alte Einstellungsnamen auf neue und legt dabei eine Sicherungskopie der alten Konfiguration mit Zeitstempel an. Dieses Verhalten war im Testlauf direkt zu beobachten.

Die Grenze beim Rollback liegt bei den Datenbankdefinitionen. Wurde die Datenbank durch die neue Version umgestellt, kann die alte Version sie unter Umständen nicht mehr lesen. Der zuverlässige Rückweg ist deshalb nicht das Zurücksetzen des Abbilds allein, sondern das Zurückspielen der vor dem Update erstellten Sicherung zusammen mit dem alten Abbild. Über mehrere Hauptversionen hinweg empfiehlt die Projektdokumentation ein schrittweises Vorgehen entlang der Migrationsanleitung statt eines Sprungs.

Typische Fehler und Lösungen

Der Start scheitert mit einer Meldung, die Abbildkennung sei nicht auffindbar. Genau dieser Fehler trat im Testlauf auf. Ursache war ein Versionskennzeichen mit vorangestelltem Buchstaben. Die Veröffentlichungen auf GitHub tragen den Namen v26.9.0, die Abbilder in der Registrierung heißen aber 26.9.0 ohne den Buchstaben. Die verfügbaren Kennzeichen lassen sich vorab prüfen, statt sie aus der Versionsnummer abzuleiten.

Es werden keine Geräte gefunden. Erste Prüfung: Läuft der Container wirklich im Host-Netzwerkmodus? Im Bridge-Netzwerk kann der ARP-Scan nicht funktionieren. Zweite Prüfung: Sind die Sonderrechte NET_ADMIN und NET_RAW vergeben? Dritte Prüfung: Steht in den Scan-Bereichen das richtige Netz mit der richtigen Schnittstelle?

Nach dem Start passiert minutenlang nichts. Das ist normal. Der Ablaufplaner startet den ersten Scan erst nach dem eingestellten Intervall. Im Testlauf dauerte es etwa drei Minuten bis zum ersten Durchlauf. Im Protokoll erkennbar an den Zeilen des Ablaufplaners, die den Scan zunächst ablehnen und dann ausführen.

Der Scan läuft in eine Zeitbegrenzung. Die Meldung lautet, arp-scan sei nach 300 Sekunden abgelaufen. Häufigste Ursache ist ein zu großer automatisch erkannter Netzbereich, etwa ein Docker-Bridge-Netz mit Präfixlänge 16. Die Scan-Bereiche von Hand auf die tatsächlich benötigten Netze eingrenzen.

Erweiterungen zur Namensauflösung melden Zeitüberschreitungen. Im Testlauf meldeten die Erweiterungen für Avahi, nbtscan, nslookup und dig jeweils eine Zeitüberschreitung. Das blockiert den Betrieb nicht, es fehlen dann lediglich die aufgelösten Namen, die Geräte selbst werden trotzdem erfasst. Abhilfe schaffen ein längerer Zeitwert für diese Erweiterungen, ein größerer Abstand zwischen den Scans oder das Abschalten der Erweiterungen, die in der eigenen Umgebung ohnehin nichts liefern.

Jedes Mobiltelefon erscheint ständig als neues Gerät. Ursache sind wechselnde Hardwareadressen, die moderne Betriebssysteme aus Datenschutzgründen verwenden. Entweder auf den Geräten die feste Hardwareadresse für das Firmennetz aktivieren oder diese Geräteklasse von den Meldungen ausnehmen.

Der Port ist bereits belegt. Im Host-Netzwerkmodus gibt es keine Portumsetzung. Der Port wird deshalb über die Umgebungsvariable geändert, nicht über einen Eintrag unter ports.

Saubere Deinstallation

Container stoppen und entfernen, Daten bleiben erhalten:

cd /opt/netalertx
sudo docker compose down

Achtung: Der folgende Befehl löscht die vollständige Gerätehistorie, alle Einstellungen und alle Ereignisse unwiderruflich. Legen Sie vorher eine Sicherung an, wenn die Netzwerkdokumentation noch gebraucht wird.

sudo docker compose down -v

Anschließend das Abbild und das Verzeichnis entfernen:

sudo docker image rm ghcr.io/netalertx/netalertx:26.9.0
sudo rm -rf /opt/netalertx

Wurden die Werte für die ARP-Flux-Minderung auf dem Host gesetzt statt im Container, sollten sie ebenfalls zurückgenommen werden, sofern kein anderer Dienst sie braucht.

Was tatsächlich geprüft wurde

Für diese Anleitung wurden in einer isolierten Testumgebung mit Docker 29.1.3 und Compose 2.40.3 tatsächlich ausgeführt: Start des Stacks nach Korrektur des Abbildkennzeichens, Zustandsprüfung des Containers als gesund, Aufruf der Weboberfläche mit Weiterleitung auf die Geräteübersicht, Auswertung des Startprotokolls mit den geladenen Erweiterungen, ein vollständiger ARP-Scan mit 36 gefundenen und 38 in der Datenbank angelegten Geräten samt Herstellerzuordnung, die Beobachtung der Zeitüberschreitung bei zu großem Netzbereich, das Auslesen der Konfigurationsdatei und die Sicherung des Volumes in ein Archiv.

Nicht selbst ausgeführt, sondern der offiziellen Dokumentation entnommen wurden: das Zurückspielen einer Sicherung in eine laufende Instanz, die Einrichtung der Benachrichtigungen über einen Push-Dienst, der Betrieb hinter einem Reverse Proxy mit Anmeldung, die Anbindung an eine zentrale Authentifizierung und das Verhalten bei Versionssprüngen über mehrere Hauptversionen. Diese Angaben stammen aus der Projektdokumentation und der Konfigurationsdatei, die im Testlauf eingesehen wurde.

Passende Anleitungen auf S-EDV

• NetBox für IP-Adressverwaltung und Netzwerkdokumentation ergänzt die automatische Erfassung um die gepflegte Solldokumentation.
• ntfy selbst hosten für Push-Benachrichtigungen beschreibt den Meldekanal, den NetAlertX ansprechen kann.
• Docker Compose unter Linux als Grundlage für Selfhosting erklärt die verwendeten Bausteine.

Quellen

• Projekt-Repository netalertx/NetAlertX auf GitHub, Kennzahlen abgerufen am 13. September 2026
• NetAlertX-Dokumentation, insbesondere die Abschnitte zu Docker Compose und Sicherungen
• NetAlertX: Veröffentlichungen, Version v26.9.0 vom 2. September 2026