Dockhand: Docker-Management im Homelab, ohne CLI-Gymnastik

Dockhand ist eine moderne Docker-Management-GUI mit Compose-Stacks, Git-Deployments und Multi-Environment-Support. Dieser Beitrag zeigt, wie es sich im Homelab schlägt – inklusive Remote-Hosts per Tailscale und einer pragmatischen Security-Checkliste.

Du willst „mal eben“ einen Container neu starten, Logs checken, kurz in die Shell – und plötzlich bist du wieder im CLI-Loop aus docker ps, docker logs -f und „Wo liegt eigentlich das Compose-File von diesem Stack?“?

Genau da fühlt sich Dockhand im Homelab ziemlich gut an: eine moderne Web-GUI für Docker, die Compose-Stacks ernst nimmt, mehrere Hosts sauber verwaltet und dir ein bisschen Alltagsschmerz abnimmt, ohne gleich zur „Plattform“ zu werden.

Repo: https://github.com/Finsys/dockhand Manual: https://dockhand.pro/manual/

Was Dockhand kann (Homelab-relevant, nicht Marketing-Bingo)

Compose-Stacks als First-Class-Citizen

Dockhand ist stark, wenn du viel über Compose machst:

  • Stacks importieren (auch bestehende Ordner-Strukturen)
  • Stacks starten/stoppen/redeployen
  • Variables/Secrets handhaben (ohne dass du dir direkt alles ins Repo leaken musst)
  • relative Pfade & Volumes weniger „überraschend“

Kurz: weniger „ich muss kurz ins Verzeichnis wechseln“, mehr „mach’s einfach“.

Git-Deployments + Webhooks (GitOps light)

Wenn deine Compose-Stacks eh schon in Git liegen, kannst du sie in Dockhand direkt anbinden:

  • Repo + Branch auswählen
  • Compose-Datei/-Pfad definieren
  • optional Auto-Sync / Webhook-triggered Updates

Im Homelab ist das der Sweet Spot zwischen „alles manuell“ und „ich baue mir jetzt ArgoCD für zwei Services“.

Multi-Environment: mehrere Docker-Hosts ohne Chaos

Dockhand kann mehrere Docker-Hosts/Environments verwalten. Das ist besonders nice, wenn du sowas hast wie:

  • NAS im LAN
  • Mini-PC im Büro
  • VPS irgendwo draußen
  • Raspi im Keller (natürlich)

Und du willst nicht jedes Mal das Tool wechseln oder Kontext-Knoten im Kopf halten.

Remote-Hosts via Tailscale: passt ziemlich gut zusammen

Du hast geschrieben, dass deine externen Docker-Installationen über Tailscale angebunden sind. Das ist im Homelab eigentlich die entspannteste Variante, weil du:

  • keine Ports ins Internet öffnest
  • stabile Hostnamen/IPs im Tailnet bekommst
  • Zugriffe sauber über ACLs einschränken kannst

Was ich dabei als Setup-Pattern sinnvoll finde

Dockhand läuft auf einem „Hub“-Host (z.B. NAS oder Mini-Server) im Tailnet.

Für die Remote-Hosts hast du dann zwei Optionen:

  1. Dockhand → Docker API des Remote-Hosts über Tailscale

    • funktioniert, aber du musst die Docker API remote verfügbar machen (und absichern)
    • das ist der Punkt, wo man schnell in „sollte ich das wirklich?“ landet
  2. Hawser-Agent auf den Remote-Hosts (Outbound-Verbindung)

    • elegant, wenn du gar keine Docker API exponieren willst
    • besonders angenehm, wenn Hosts hinter NAT/wechselnden Netzen hängen
    • und: über Tailscale kannst du den Agent/Dockhand-Traffic zusätzlich logisch abschotten

Im Homelab würde ich (wenn du mehrere externe Hosts hast) eher Richtung Hawser + Tailscale tendieren: Tailscale fürs sichere Netz/Identity-Layer, Hawser für die „Remote-Steuerung ohne Docker-API-Freigabe“-Story.

Side comment: Es ist irgendwie beruhigend, wenn „Docker remote“ nicht bedeutet, dass irgendwo ein Socket ins Internet lächelt.

Quickstart: Dockhand lokal am Docker-Socket

Docker Run

docker run -d \
  --name dockhand \
  --restart unless-stopped \
  -p 3000:3000 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v dockhand_data:/app/data \
  fnsys/dockhand:latest

Dann: http://localhost:3000

Compose

services:
  dockhand:
    image: fnsys/dockhand:latest
    container_name: dockhand
    restart: unless-stopped
    ports:
      - '3000:3000'
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - dockhand_data:/app/data

volumes:
  dockhand_data:

Direkt danach: Auth aktivieren

Beim ersten Start ist Auth standardmäßig aus. In der UI unter Settings → Authentication aktivieren und den ersten Admin anlegen (steht so auch im Manual).

Security-Checkliste für Homelab (pragmatisch, nicht paranoid)

Dockhand greift typischerweise auf den Docker-Socket zu. Das ist bequem – aber der Socket ist mächtig. Ein paar praktische Leitplanken:

  • Dockhand nicht offen ins Internet hängen. Im Homelab: nur LAN / Tailnet / Reverse Proxy mit Auth davor.
  • Auth in Dockhand aktivieren (ja, auch im Homelab).
  • Wenn du einen Reverse Proxy hast: Basic Auth/SSO davor (Defense in depth).
  • Wenn du’s „sauberer“ willst: Docker Socket Proxy statt direktem Socket-Mount. Dann kann die UI nur die API-Teile nutzen, die du erlaubst.
  • Tailscale-Seite: ACLs so setzen, dass nicht jedes Gerät im Tailnet überallhin darf (gerade wenn du „Freunde/Familie im Tailnet“ hast).

Das Ziel ist nicht „perfekt“, sondern: keine unnötigen offenen Flanken, ohne dass es nervt.

Lizenz: kurz wissen, dann weiter basteln

Dockhand nutzt die Business Source License 1.1 (BSL 1.1). Für Homelab ist das in der Regel unkritisch: privat/intern ist ok, als kommerziellen Hosted Service anbieten ist nicht erlaubt, und später gibt’s eine Umstellung auf Apache 2.0 (Stichtag ist im Repo/Manual genannt).

Fazit

Dockhand passt im Homelab besonders gut, wenn du:

  • Compose-Stacks ernsthaft nutzt (mehr als „zwei Container“)
  • mehrere Hosts verwalten willst
  • Git als Quelle der Wahrheit magst
  • Remote-Zugriff sauber lösen willst (bei dir: Tailscale – sehr nice)

Es ist genau die Sorte Tool, die den Alltag spürbar glättet: weniger Kontextwechsel, weniger „Wo war das nochmal?“, mehr „klick, läuft“.