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.
- Schlagworte
- #Dockhand #Docker #Docker-Compose #Tailscale #Gitops #Sveltekit #Bun
- Kategorien
- Dev Docker Self-Hosting
- veröffentlicht
- Lesezeit
- 4 Minuten
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:
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
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“.