Betreibe deinen eigenen Netzwerk-Monitoring-Server

Speicher das als docker-compose.yml und starte docker compose up -d. network_mode: host lässt es dein LAN sehen; die beiden Capabilities sind unten erklärt.

services:
  deviceshelf:
    image: ghcr.io/wealthwallet/deviceshelf-server:1.9.69
    network_mode: host
    cap_add:
      - NET_RAW              # ARP scan (raw sockets)
      - NET_BIND_SERVICE     # passive DHCP fingerprinting (UDP/67) → Fingerbank
    volumes:
      - ./data:/data         # chown 10001:10001 ./data
    restart: unless-stopped
    # optional: environment: { DEVICESHELF_FINGERBANK_KEY: "<free key from fingerbank.org>" }

Warum diese Capabilities? DeviceShelf Server identifiziert Geräte teils über ihren DHCP-Fingerprint und lauscht passiv auf UDP-Port 67. Weil der Container bewusst als nicht-privilegierter Nutzer läuft (uid 10001), braucht das Binden dieses Systemports das eng gefasste NET_BIND_SERVICE — kein root, kein NET_ADMIN, nur das Öffnen niedriger Ports. Ohne es startet der Server trotzdem normal, nur ohne DHCP-/Fingerbank-Identifikation. NET_RAW ist für den ARP-Scan.

Über das Terminal installieren — nicht doppelklicken. Unter Ubuntu 24.04 öffnet ein doppelgeklicktes .deb das App Center, das bei Drittanbieter-Paketen still fehlschlagen kann. Das Terminal löst Abhängigkeiten auf und startet den Dienst deviceshelf-server:

Download .deb — amd64 (Intel/AMD) Download .deb — arm64 (Raspberry Pi)

sudo apt install ./DeviceShelf-Server-*.deb

Auf ARM (Raspberry Pi, ARM-Server) nimm die -arm64.deb-Datei.

Lade das universelle Paket und öffne es. Es installiert den Server als Hintergrund-LaunchDaemon und hält ihn nach dem Login am Laufen. Das Dashboard ist auf Port 8088 erreichbar; Updates bewahren die Serverdaten und legen zuerst ein verifiziertes Backup an.

Für macOS laden (universal)

Lade die Zip-Datei, entpack sie und doppelklick install.bat — bestätige die Windows-Admin-Abfrage (UAC). Das installiert und startet den 24/7-Dienst, zeigt dann die Dashboard-URL und das Zugriffstoken und öffnet das Dashboard. Deinstallieren mit uninstall.bat.

Für Windows laden (amd64)

Der Windows-Build ist noch nicht code-signiert, daher warnt Windows womöglich: Bei SmartScreen klick Weitere Informationen → Trotzdem ausführen; wenn Smart App Control an ist, blockiert es unsignierte Apps komplett, bis wir einen signierten Build liefern. Vor dem Entpacken kannst du die Zip rechtsklicken → Eigenschaften → Zulassen ankreuzen. Alle Details stehen in der README in der Zip (7 Sprachen). Passives DHCP-Fingerprinting gibt es auf Windows nicht; alles andere — Scannen, Monitoring, SNMP, Alerts, Dashboard, API — ist dabei.

Beim ersten Start druckt der Server ein automatisch erzeugtes API-Token in sein Log. Schnapp es dir, öffne dann die Web-Oberfläche auf Port 8088 und füg es ein:

# .deb / systemd:
journalctl -u deviceshelf-server | grep -iA1 auto-generated

# Docker:
docker logs deviceshelf-server | grep -iA1 auto-generated

Öffne dann http://<host>:8088 im Browser und füg das Token ein.

Du musst nicht im Web-Dashboard arbeiten. Die Desktop-App für macOS, Windows und Linux und die Mobile-App lassen sich mit einem Server koppeln und zeigen seine Daten in ihrer eigenen Oberfläche. Am Desktop Remote-Server öffnen, Suchen drücken oder Host und Port eintragen, dann den API-Token von oben einfügen. Danach den Server in der Quellen-Auswahl über der Geräteliste wählen, allein oder zusammen mit dem lokalen Scan. Mit kommen: Geräte samt Verlauf, Alarme zum Quittieren, Checks, Monitoring, Health, Docker, Proxmox und Topologie.

Geräte, die ein Server meldet, sind in den Apps nur lesbar. Wecken, Portscan oder Verbinden liefen sonst von dem Gerät aus, das du in der Hand hast, nicht vom Server; diese Aktionen bleiben deshalb beim lokalen Scan. Soll nur der Server scannen, schalte in den Desktop-Einstellungen den Auto-Scan ab.

Füg in den Alert-Einstellungen des Dashboards dein eigenes Mail-Konto als Absender hinzu. Für gängige Anbieter — Gmail, Yahoo, Outlook/Hotmail, iCloud, GMX und andere — lass das SMTP-Server-Feld leer; DeviceShelf erkennt den richtigen Server automatisch. Wegen der Zwei-Faktor-Anmeldung brauchen Gmail, Yahoo und Outlook ein App-Passwort (in den Sicherheitseinstellungen deines Mail-Kontos erzeugt), nicht dein normales Passwort. Für jeden anderen oder selbstgehosteten Anbieter trägst du SMTP-Server, Port und Sicherheit ein. Alerts werden dann über dein Konto an die Empfänger gesendet, die du angibst.

Jeder Alarm von DeviceShelf läuft auf deinem eigenen Rechner — deshalb erreicht dich keiner davon, wenn genau dieser Rechner das Problem ist: Stromausfall, Absturz, tote Leitung. Der Wächter deckt diesen Fall ab. Unter Einstellungen → Externer Wächter trägst du die Heartbeat-URL eines Überwachungsdienstes ein; DeviceShelf pingt sie alle 60 Sekunden an, und wenn die Pings ausbleiben, meldet sich der Dienst bei dir. Nimm Healthchecks.io, UptimeRobot (Heartbeat-Monitor), Better Stack, Cronitor oder einen eigenen Empfänger — alle haben einen kostenlosen Tarif, der für ein Heimnetz reicht. Stell die Karenzzeit dort auf etwa das Dreifache des Ping-Intervalls und drück einmal auf Test-Ping senden, um die Verbindung zu bestätigen.

Diesen Dienst betreiben wir bewusst nicht selbst. Ein Wächter muss verfügbarer sein als das, was er überwacht, und er muss außerhalb deines Netzes stehen — das Gegenteil dessen, wofür DeviceShelf gebaut ist.

Der Server kann dein Inventar über das Model Context Protocol an einen KI-Assistenten geben. Du fragst „Was ist gerade online?“, „Warum komme ich nicht aufs NAS?“ oder „Wie riskant ist dieses Netz?“ und bekommst Antworten aus deinen eigenen Daten, 37 Werkzeuge insgesamt. Das ist strikt lokal: Der Endpunkt läuft in deinem Server, hinter demselben Token, nur im eigenen LAN erreichbar. Einen DeviceShelf-Cloud-Connector gibt es nicht. Standardmäßig aus, nur lesend, in deiner Lizenz enthalten (auch in der Testphase).

# enable it in the dashboard: Settings → AI assistant → tick "Serve the MCP endpoint"
#   (takes effect at once, no restart; a second box allows actions)
# or pin it from /etc/deviceshelf/server.env (or your Docker env), which needs a restart:
DEVICESHELF_MCP_ENABLE=true

# then point Claude Desktop at it via the mcp-remote bridge:
#   http://<host>:8088/mcp   (Authorization: Bearer <your-token>)

Die Ankündigung beschreibt die Einrichtung, der Beitrag zu 1.9.14 die Werkzeuge für Fehlersuche, Verlauf und Wake-on-LAN. Aktionen (Gerät umbenennen, Alarm bestätigen, Scan auslösen, Host anpingen oder wecken) bleiben aus, bis du sie ausdrücklich einschaltest, und sie verlassen nie dein eigenes Subnetz.

Aktivier zuerst MCP (oben), richte dann deinen KI-Client auf den /mcp-Endpoint des Servers mit deinem API-Token. Ersetz unten <host> und <token>. Die meisten Clients sprechen Streamable HTTP nativ:

Claude Code

claude mcp add --transport http deviceshelf http://<host>:8088/mcp \
  --header "Authorization: Bearer <token>"

Cursor — ~/.cursor/mcp.json

{ "mcpServers": { "deviceshelf": {
  "url": "http://<host>:8088/mcp",
  "headers": { "Authorization": "Bearer <token>" }
} } }

VS Code (Copilot agent) — .vscode/mcp.json

{ "servers": { "deviceshelf": {
  "type": "http",
  "url": "http://<host>:8088/mcp",
  "headers": { "Authorization": "Bearer <token>" }
} } }

Windsurf — ~/.codeium/windsurf/mcp_config.json (note: serverUrl)

{ "mcpServers": { "deviceshelf": {
  "serverUrl": "http://<host>:8088/mcp",
  "headers": { "Authorization": "Bearer <token>" }
} } }

Cline — cline_mcp_settings.json ("type": "streamableHttp" is required, else it falls back to SSE and fails)

{ "mcpServers": { "deviceshelf": {
  "type": "streamableHttp",
  "url": "http://<host>:8088/mcp",
  "headers": { "Authorization": "Bearer <token>" }
} } }

Gemini CLI — ~/.gemini/settings.json (note: httpUrl)

{ "mcpServers": { "deviceshelf": {
  "httpUrl": "http://<host>:8088/mcp",
  "headers": { "Authorization": "Bearer <token>" }
} } }

Claude Desktop — claude_desktop_config.json. It has no native static-token remote support, so bridge it with mcp-remote (keep --allow-http for plain http; the token goes in an env var to avoid a Windows arg-quoting bug). Fully quit and relaunch after saving.

{ "mcpServers": { "deviceshelf": {
  "command": "npx",
  "args": ["-y", "mcp-remote", "http://<host>:8088/mcp",
           "--transport", "http-only", "--allow-http",
           "--header", "Authorization:${AUTH}"],
  "env": { "AUTH": "Bearer <token>" }
} } }

ChatGPT-Connectors laufen in OpenAIs Cloud und können einen LAN-Server nicht direkt erreichen. Um sie zu nutzen, stell den Server hinter einen öffentlichen HTTPS-Tunnel (OpenAIs Secure MCP Tunnel, ngrok oder Cloudflare Tunnel), damit er eine https://…/mcp-Adresse hat. Für ein streng lokales Setup nimm lieber einen der Clients oben.

Die Server-Edition ist jetzt Teil der regulären DeviceShelf-Produktlinie. Sie bewegt sich noch schnell, aber die Positionierung ist einfach: durchgehend betreiben, deine Daten lokal halten und denselben Lizenzschlüssel wie die Desktop- und Mobile-Apps nutzen. Was sich in diesem Build geändert hat, steht in den Release-Notes.

Für den größeren Zusammenhang: Selbst gehostetes Netzwerk-Monitoring zeigt, was dir die Überwachung auf eigener Hardware gegenüber einem Cloud-Dashboard bringt.