von Wer seit Jahren einen Homelab betreibt, kennt das Ritual: Alle paar Monate taucht eine neue Docker-Management-Oberfläche auf, wird kurz gehypt, und drei Wochen später ist das Repo wieder still. Portainer bleibt, weil es funktioniert – auch wenn die Community-Edition sich seit Jahren anfühlt, als würde jedes interessante Feature hinter der Business-Lizenz verschwinden.
Dockhand ist der erste Kandidat seit langem, bei dem ich das Gefühl habe, dass da jemand ernsthaft dranbleibt. Rund 5.000 Stars, 23 Releases, aktuelle Version 1.0.36 von Ende Juni 2026. Entwickelt von Jarek Krochmalski unter dem Label Finsys. Zeit für einen genaueren Blick.
Was Dockhand ist
Dockhand ist eine Web-UI für Docker – Container-Lifecycle, Compose-Stacks, mehrere Hosts, alles aus einer Oberfläche. So weit, so bekannt. Interessant wird es beim Unterbau.
Der Tech-Stack:
| Ebene | Technologie |
|---|---|
| Frontend | SvelteKit 2, Svelte 5, shadcn-svelte, TailwindCSS |
| Backend | Bun-Runtime mit SvelteKit API-Routes |
| Datenbank | SQLite oder PostgreSQL via Drizzle ORM |
| Base-Image | Eigener OS-Layer aus Wolfi-Packages, gebaut mit apko |
| Docker-Zugriff | Direkte Calls gegen die Engine-API |
Zwei Punkte sind hier bemerkenswert. Erstens: Das Base-Image wird nicht aus einem FROM debian:bookworm zusammengeschraubt, sondern aus Wolfi-Packages via apko gebaut, jedes Paket explizit im Dockerfile deklariert. Das ist der Chainguard-Ansatz – minimale Angriffsfläche, nachvollziehbare Herkunft jedes Bestandteils. Für ein Homelab-Tool ist das ungewöhnlich sorgfältig, für den Einsatz beim Kunden ist es genau das Argument, das man in der Security-Abnahme braucht.
Zweitens: kein Docker-CLI-Wrapper, sondern direkte API-Calls. Das merkt man an der Reaktionsgeschwindigkeit.
Der Funktionsumfang
Die Basics sind da und funktionieren, wie man es erwartet: Container starten, stoppen, neu starten, Live-Metriken, Port-Mappings, Log-Streaming, Shell direkt in den Container. Interessanter ist, was darüber hinausgeht:
Compose-Stacks mit Graph-Editor. Neben dem klassischen YAML-Editor gibt es einen visuellen Editor, der Services, Netzwerke und Secrets als Graph darstellt. Dazu ein Netzwerk-Graph, der zeigt, welche Services über Stack-Grenzen hinweg miteinander reden. Bei siebzig Containern über mehrere Hosts ist das kein Spielzeug, sondern der schnellste Weg herauszufinden, warum ein Container plötzlich nicht mehr erreichbar ist.
Git-Deployment. Stacks direkt aus einem Repository ausrollen, per Webhook oder per Sync-Intervall. SSH- und HTTPS-Auth, mehrere Repos parallel. Für alle, die ihre Compose-Files ohnehin schon versioniert haben, ist das der Schritt zu GitOps ohne zusätzliches Werkzeug.
Vulnerability-Scanning. Grype und Trivy sind integriert, CVE-Ergebnisse pro Image direkt in der UI. Kein separater Scanner-Container, keine Pipeline-Bastelei.
Datei- und Volume-Browser. Dateien in Containern und in Volumes durchsuchen, bearbeiten, hoch- und runterladen. Das klingt banal, spart aber genau die docker cp-Orgien, die man sonst zwei Mal die Woche macht.
Schedules. Cron-artige Automatisierung für Prune, Image-Updates und Cleanup.
Activity Log. Jede Aktion über alle Umgebungen hinweg protokolliert. Wer nicht allein am System arbeitet, weiß, warum das wichtig ist.
Backups (Beta). Auf Basis von restic: verschlüsselt, dedupliziert, mit Retention-Policies. Zielt auf S3, Backblaze, Azure, Google Cloud oder einen REST-Server. Gesichert werden Volumes, Bind-Mounts und Stack-Files. Das Feature ist als Beta markiert – wer bereits eine funktionierende Backup-Strategie hat, sollte sie vorerst behalten.
Authentifizierung: OIDC ist an Bord
Lokale Benutzer und SSO über OIDC. Wer Authentik, Keycloak oder Zitadel betreibt, hängt Dockhand also ohne Umwege in die bestehende Identity-Landschaft. RBAC – also feingranulare Rollen – ist der Enterprise-Variante vorbehalten.
Wichtig zu verstehen: Enterprise ist keine separate Codebase. Es ist derselbe Code, per Lizenzschlüssel freigeschaltet. Das ist ehrlicher als das übliche Modell, bei dem die Community-Edition eine bewusst kastrierte Parallelentwicklung ist.
Hawser: der Agent für alles hinter NAT
Der interessanteste Teil des Projekts ist der Agent. Hawser ist ein schlanker Go-Binary und kennt zwei Betriebsarten:
Standard Mode – der Agent lauscht auf einem Port (Default 2376) und wartet auf Verbindungen vom Dockhand-Server. Sinnvoll im LAN mit statischen IPs. Bindet man auf eine Nicht-Loopback-Adresse, ist ein Token zwingend; ohne Token verweigert Hawser den Start, um nicht versehentlich eine ungeschützte Docker-API ins Netz zu hängen. Eine Designentscheidung, die ich ausdrücklich lobe – zu viele Projekte machen es genau andersherum und bauen die Warnung nur in die Doku. TLS ist über TLS_CERT und TLS_KEY optional zuschaltbar; für den Produktivbetrieb ist die Kombination aus TLS und Token die richtige Wahl.
Edge Mode – der Agent baut eine ausgehende WebSocket-Verbindung zum Dockhand-Server auf, gegen wss://<host>/api/hawser/connect. Damit lassen sich Hosts hinter NAT, mit dynamischer IP oder auf einem VPS ohne eingehende Portfreigabe einbinden. Genau das Szenario, an dem Portainer Edge Agents traditionell wehtun.
Der Edge Mode ist der eigentliche Verkaufsargument des Projekts. Ein Jetson im Heimnetz, ein VPS bei Hetzner, ein Raspberry Pi beim Kunden – alle melden sich von selbst am zentralen Dockhand an, ohne dass irgendwo eine Firewall-Regel aufgeht.
Praxis-Hinweis: Wer den Dockhand-Server hinter einem Reverse Proxy betreibt, muss sicherstellen, dass der WebSocket-Upgrade auf
/api/hawser/connectsauber durchgereicht wird. Nicht jeder Proxy tut das in der Default-Konfiguration, und HTTP/2 in Kombination mit WebSocket-Upgrades ist eine klassische Fehlerquelle. Dazu kommt beim Hinzufügen eines Hosts über HTTPS ein bekannter Mixed-Content-Stolperstein, wenn der Agent-Endpunkt selbst nicht TLS-terminiert ist.
Die Lizenz – bitte einmal genau lesen
Dockhand steht unter der Business Source License 1.1. Das ist keine Open-Source-Lizenz im Sinne der OSI, auch wenn der komplette Quellcode öffentlich einsehbar ist.
Erlaubt: Privatnutzung, interne betriebliche Nutzung, Non-Profits, Bildungseinrichtungen, Evaluation.
Nicht erlaubt: Dockhand als kommerziellen SaaS- oder Hosting-Dienst anbieten.
Ab 01.01.2029: Automatische Umwandlung in Apache 2.0.
Für den Homelab-Betrieb und für den Einsatz in der eigenen Firma ist das völlig unproblematisch. Relevant wird es für Dienstleister: Dockhand beim Kunden on-premise installieren und im Rahmen eines Beratungsmandats einrichten fällt unter interne betriebliche Nutzung des Kunden. Dockhand als gehostete Managed-Plattform für mehrere Kunden betreiben und dafür abrechnen – das ist genau der Fall, den die BSL ausschließt. Wer in diese Richtung denkt, klärt das vorher mit dem Hersteller.
Einordnung: Wo steht Dockhand gegenüber der Konkurrenz?
Gegen Portainer CE: Dockhand bietet in der freien Variante mehr – Git-Deployment, CVE-Scanning, Volume-Browser, Backups sind bei Portainer teils Business-Features oder fehlen ganz. Portainer punktet mit Reife, Swarm- und Kubernetes-Support und einer sehr viel größeren Installationsbasis. Wer Kubernetes managen will, ist bei Dockhand falsch.
Gegen Komodo: Ähnliche Zielgruppe, ähnlicher GitOps-Ansatz. Komodo ist in Rust geschrieben und stärker auf Build-Pipelines ausgerichtet. Dockhand hat die deutlich ausgereiftere Oberfläche.
Gegen Dockge: Andere Liga. Dockge ist bewusst minimal und macht Compose-Stacks auf einem Host. Dockhand ist ein Multi-Host-Werkzeug mit Anspruch auf den Enterprise-Einsatz.
Fazit
Dockhand ist das erste Tool seit langem, bei dem ich ernsthaft überlege, Portainer abzulösen. Der Wolfi-basierte Unterbau, die direkte API-Anbindung, OIDC ab Werk und vor allem der Hawser Edge Mode adressieren genau die Punkte, an denen ich mich in den letzten Jahren regelmäßig gestoßen habe.
Die Einschränkungen sollte man kennen: kein Kubernetes, kein Swarm, das Backup-Feature noch in Beta, und eine Lizenz, die zwar den Quellcode offenlegt, aber keine Open-Source-Lizenz ist. Für den Homelab und für den internen Betrieb ist nichts davon ein Hindernis.
Wer testen will: Die Dokumentation liegt unter dockhand.pro/manual, das Repository unter github.com/Finsys/dockhand, der Agent unter github.com/Finsys/hawser.
Offenlegung: Dieser Artikel entstand auf Basis eines eigenen Testbetriebs im Homelab. Es besteht keine Verbindung zum Hersteller.
