Portainer abgelöst — fünf Tools, die meinen Homelab-Monitoring-Stack radikal vereinfacht haben

Irgendwann hatte ich auf meinen Docker-Hosts die vollständige Kombination laufen: Portainer für Container-Management, Prometheus als Metriken-Scraper, Grafana für Dashboards. Den Stack kennt fast jeder im Homelab-Umfeld — er ist gut dokumentiert, hat eine aktive Community und funktioniert.

Das Problem: Er funktioniert zu viel. Für ein paar Docker-Hosts, einen Proxmox-Cluster und eine Handvoll selbst-gehosteter Dienste ist das eine Menge Overhead, um die Frage zu beantworten: Läuft alles noch?

Ich habe diesen Stack schrittweise durch fünf deutlich schlankere Tools ersetzt. Keines davon ist ein Kompromiss — jedes macht genau eine Sache, und macht sie gut.

Was vorher da war — und warum es zu viel war

Portainer ist ein Container-Management-Frontend für Docker und Kubernetes. Es ist gut gemacht, hat eine saubere Oberfläche und macht viele Dinge möglich, die man sonst über CLI erledigen würde. Das Problem liegt nicht darin, was Portainer kann — sondern darin, was es kostet: eine eigene Datenbank, ein Agent-Prozess auf jedem überwachten Host, regelmäßige Updates die gerne etwas brechen, und eine Oberfläche, die mit jedem Release schwerer wird. Irgendwann habe ich gemerkt, dass ich mehr Zeit damit verbracht habe, Portainer am Laufen zu halten, als tatsächlich Container zu managen.

Was ich von Portainer wirklich gebraucht habe, lässt sich in zwei Teile aufteilen: Stack-Verwaltung (Compose-Stacks deployen, updaten, überwachen) und Logs sehen. Beides hat ein besseres Zuhause gefunden.

Grafana + Prometheus ist eine andere Geschichte. Das ist ein echtes Produktions-Monitoring-System — mit gutem Grund in unzähligen produktiven Umgebungen im Einsatz. Für das Homelab ist die Einstiegshürde aber hoch: Prometheus will konfiguriert werden (Scrape-Intervalle, Retention, Cardinality-Grenzen), Grafana braucht Dashboards (entweder selbst gebaut oder aus der Community importiert, die dann nicht mehr passen), und beides zusammen sind zwei weitere Container, die regelmäßig Updates brauchen.

In der Praxis war mein Grafana-Dashboard nach drei Monaten hoffnungslos veraltet und zeigte Metriken, die ich nie angeschaut habe. Meine Frage war immer nur: Wie viel RAM hat der Host noch frei? Läuft der Container noch? Wie lange schon?

Das kann ein viel einfacheres Tool beantworten.

Dockhand — Stack-Verwaltung ohne Portainer-Overhead

Dockhand ist ein modernes Docker-Management-Tool, das Compose-Stack-Verwaltung, Container-Lifecycle und Multi-Host-Unterstützung in einer schlanken Oberfläche kombiniert. Es macht das, wofür ich Portainer eigentlich eingesetzt hatte — aber ohne die Datenbankschicht, ohne den schweren Agent-Stack und ohne die akkumulierte Oberfläche, die Portainer über die Jahre angesammelt hat.

Was Dockhand besonders macht: Git-basiertes Stack-Deployment mit Webhook-Support. Statt Compose-Files manuell über ein Web-UI hochzuladen, zeigt Dockhand auf ein Git-Repository — Änderungen werden automatisch synchronisiert. Für ein Homelab, das ohnehin mit Git-basierten Configs arbeitet, ist das der natürlichere Workflow.

services:
  dockhand:
    image: ghcr.io/finsys/dockhand:latest
    container_name: dockhand
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data:/app/data
    environment:
      - DATABASE_URL=file:/app/data/dockhand.db

Die Oberfläche ist mit SvelteKit gebaut und fühlt sich entsprechend modern an — klar strukturiert, schnell, ohne unnötige UI-Schichten. Multi-Host-Umgebungen werden nativ unterstützt, OIDC-Login ist eingebaut.

Was ich weiterhin per CLI mache: Container neu bauen, Images pullen, einmalige docker exec-Befehle. Dockhand ist kein Ersatz für die CLI — es ist der Überblick, der mir sonst gefehlt hat.

Lizenz-Hinweis: Dockhand steht unter der Business Source License 1.1 — ähnlich wie damals HashiCorp oder Grafana. Für privates Selfhosting und interne Nutzung ist das unproblematisch, für kommerzielle Hosting-Dienste nicht. Die Lizenz konvertiert 2029 zu Apache 2.0. Das ist es wert, im Hinterkopf zu behalten — ich beobachte das Changelog.

Beszel — Metriken ohne Konfigurationsaufwand

Beszel ist ein leichtes Server-Monitoring-Tool, das sowohl Host-Metriken (CPU, RAM, Netzwerk, Festplatte) als auch Docker-Container-Metriken in einer einzigen Oberfläche zeigt. Keine Prometheus-Config, keine Grafana-Dashboards, keine Scrape-Jobs.

Die Architektur ist simpel: ein zentraler Hub (ein einzelner Docker-Container) und ein Agent je überwachtem Host. Der Agent läuft als einzelner Prozess, braucht keine Root-Rechte und kommuniziert verschlüsselt mit dem Hub. Der Hub speichert alles in einer lokalen SQLite-Datenbank.

# Hub (auf dem zentralen Host)
services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel
    restart: unless-stopped
    ports:
      - "8090:8090"
    volumes:
      - ./data:/beszel_data

# Agent (auf jedem überwachten Host)
services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - PORT=45876
      - KEY=<PUBLIC-KEY-AUS-HUB>

Den Public Key für den Agent bekommt man aus dem Hub-Interface direkt beim Anlegen eines neuen Systems. Fertig.

Was mich überzeugt hat: Beszel zeigt genau das, was ich täglich brauche — CPU-Auslastung, RAM, Netzwerk-Throughput, Festplattenauslastung und den Status aller laufenden Container — ohne dass ich einen einzigen Scrape-Job konfigurieren muss. Die Retention ist einstellbar, die Oberfläche ist schnell und die Ressourcen sind fast nicht messbar. Der Agent braucht im Ruhebetrieb etwa 10 MB RAM.

Was Beszel nicht kann: Es ist kein Ersatz für Prometheus wenn man custom Metriken braucht, spezifische Alerts mit komplexen Bedingungen, oder Metriken aus der Applikation selbst (z.B. Stalwart-interne Statistiken). Für das Homelab sind diese Anforderungen selten. Für produktive Infrastruktur beim Kunden bleibt Prometheus.

Dozzle — Docker-Logs ohne Portainer

Dozzle macht eine einzige Sache: Docker-Logs in Echtzeit im Browser anzeigen. Kein Container-Management, keine Restart-Buttons, keine Image-Verwaltung. Nur Logs.

Das klingt nach wenig — ist aber genau das, wofür ich Portainer zu 80 Prozent genutzt habe. Wenn ein Dienst sich seltsam verhält, will ich die Logs sehen. Dozzle gibt mir eine saubere, durchsuchbare Echtzeit-Ansicht aller Container auf allen meinen Hosts, mit Syntax-Highlighting für JSON-Logs.

services:
  dozzle:
    image: amir20/dozzle:latest
    container_name: dozzle
    restart: unless-stopped
    ports:
      - "9999:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - DOZZLE_REMOTE_AGENT=host2:7007,host3:7007

Für mehrere Hosts läuft ein Agent-Prozess je Host — ähnlich wie bei Beszel. Die Kommunikation ist verschlüsselt, der Ressourcenbedarf ist minimal.

Was ich an Dozzle besonders schätze: JSON-Logs werden automatisch erkannt und formatiert. Stalwart und Headscale schreiben strukturierte JSON-Logs — in Dozzle kann ich direkt in den strukturierten Feldern suchen, ohne jq in der CLI zu bemühen.

Uptime Kuma — das fehlende Stück

Beszel und Dozzle decken die Fragen ab, die man stellt, wenn man bereits weiß, dass etwas nicht stimmt. Was mir noch gefehlt hat: ein Tool, das mich informiert, wenn etwas nicht stimmt — bevor ich es manuell bemerke.

Uptime Kuma ist ein selbst-gehostetes Uptime-Monitoring-Tool. Es überprüft in konfigurierbaren Intervallen ob Services erreichbar sind — per HTTP(S), TCP, DNS, Ping, Docker-Container-Status oder sogar SMTP — und sendet Alerts wenn ein Service ausfällt oder sich erholt.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data

Was mich überzeugt hat, ist der Notification-Stack. Uptime Kuma unterstützt über 90 Benachrichtigungskanäle — darunter Matrix. Da ich Matrix ohnehin für verschlüsselte Kommunikation nutze, war die Einrichtung trivial: Bot-Account erstellen, Room-ID angeben, fertig. Wenn Stalwart oder mein Headscale-Server nicht erreichbar ist, bekomme ich innerhalb von 60 Sekunden eine Nachricht im Matrix-Client.

Was ich überwache:

Die Keyword-Prüfung bei Nextcloud ist besonders praktisch: Uptime Kuma lädt die Startseite und prüft ob ein bestimmter String im HTML vorkommt. Damit erkennt man auch Zustände, in denen der Webserver antwortet, die App aber einen Fehler wirft.

Eine Status-Page lässt sich mit wenigen Klicks öffentlich erreichbar machen — für mich selbst anonym, ohne dass der Betrieb einzelner Dienste nach außen sichtbar ist.

Ehrliche Einschränkung: Uptime Kuma prüft die externe Erreichbarkeit — es testet nicht ob Stalwart intern funktioniert, nur ob Port 25 TCP antwortet. Für tiefgehendere End-to-End-Tests (Test-Mail senden und empfangen) braucht man ein anderes Tool. Für das Homelab reicht die TCP-Prüfung.

Glance — der Überblick

Glance ist eine selbst-gehostete Start-Page, die Widgets für verschiedene Datenquellen aggregiert: RSS-Feeds, GitHub-Releases, Docker-Container-Status, Wetter, Kalender und mehr.

In meinem Fall ist Glance das erste Tab, das beim Öffnen des Browser auf dem Homelab-PC sichtbar ist. Keine Verbindung nach außen, keine Accounts, keine Cloud. Ich sehe auf einen Blick: welche Dienste laufen (via Docker-Widget), aktuelle Uptime-Status von Uptime Kuma, neue Releases meiner genutzten Software und den Kalender des Tages.

# glance.yml
pages:
  - name: Homelab
    columns:
      - size: small
        widgets:
          - type: clock
            hour-format: 24h
          - type: weather
            location: Berlin, Germany
      - size: full
        widgets:
          - type: docker-containers
            title: Container
            socket: /var/run/docker.sock
          - type: releases
            title: Updates
            repositories:
              - henrygd/beszel
              - louislam/uptime-kuma
              - stalwartlabs/stalwart
              - glanceapp/glance

# docker-compose.yml
services:
  glance:
    image: glanceapp/glance:latest
    container_name: glance
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./glance.yml:/app/glance.yml
      - /var/run/docker.sock:/var/run/docker.sock:ro

Was ich an Glance besonders schätze: der Release-Tracker. Ich betreibe viele selbst-gehostete Dienste und will wissen, wenn eine neue Version erscheint — ohne GitHub-Benachrichtigungen im E-Mail-Postfach oder regelmäßige manuelle Checks. Glance zeigt neue Releases direkt auf der Startseite an.

Ressourcenvergleich

Was der Wechsel konkret gebracht hat:

                    Vorher              Nachher
Portainer + Agent   ~120 MB RAM         —
Prometheus          ~200 MB RAM         —
Grafana             ~150 MB RAM         —
                                        Dockhand            ~40 MB RAM
                                        Beszel Hub + Agent  ~25 MB RAM
                                        Dozzle              ~15 MB RAM
                                        Uptime Kuma         ~50 MB RAM
                                        Glance              ~20 MB RAM

Gesamt              ~470 MB RAM         ~150 MB RAM
Container           5–7                 5

Die Zahlen sind Richtwerte aus meinem Setup — abhängig von Anzahl der überwachten Hosts und Services. Aber die Größenordnung stimmt.

Was bleibt

Prometheus und Grafana habe ich nicht aus meinem Leben entfernt — sie laufen weiterhin in produktiven Setups, wo ich applikationsspezifische Metriken, Custom-Dashboards für Kunden oder komplexe Alerting-Regeln brauche. Stalwart stellt einen Prometheus-Endpunkt bereit, den ich nutze, wenn ich tiefer analysieren will.

Für den täglichen Homelab-Betrieb ist der neue Stack aber klar besser: weniger Overhead, weniger Pflegeaufwand, und ich bekomme alle Informationen, die ich tatsächlich brauche. Vier Container statt sieben. Kein kaputtes Grafana-Dashboard nach dem nächsten Update.

Das Muster ist immer dasselbe: Tools wählen, die eine Sache gut machen, statt Tools wählen, die alles können — und dann hauptsächlich durch ihr eigenes Gewicht auffallen.