Homelab & Containers

Dockhand: A Free, Modern Docker Management Dashboard

Getting it installed, the one setting to fix immediately, and how its Hawser agent handles hosts you can't reach directly.

My Docker setup guide points people toward Portainer for a web UI, since it's the default most community install scripts offer. Dockhand is worth knowing about as an alternative: it covers the same day-to-day container and Compose management, but bundles in things Portainer keeps behind a paywall, free OIDC/SSO and built-in vulnerability scanning among them, and it deploys as a single container just as easily.

Getting It Running

Dockhand ships as one Docker image, so it drops into whatever's already running your other containers, no dedicated VM or LXC required the way a Python app like PegaProx needs. It defaults to SQLite with zero configuration, and only needs the Docker socket mounted in to manage the host it's running on:

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

Or the same thing as a Compose file, if that's how you manage everything else already. Either way it comes up on port 3000, needs Docker Engine 20.10+ (API 1.41+), and is comfortable in 512MB of RAM. If you'd rather point it at an existing PostgreSQL server instead of SQLite, set a DATABASE_URL environment variable and it uses that instead, no other config required.

First Login: Fix This Before Anything Else

Here's the one thing worth knowing before you even start the container: a fresh Dockhand instance ships with authentication disabled by default. Open http://localhost:3000 and you're straight into a fully functional dashboard, no login screen, no setup wizard forcing you to create an account first.

That's a reasonable default for a five-minute local test, but it means anyone who can reach that port has full control over every container on the host the moment it's up. Go to Settings → Authentication and create an admin account before doing anything else with it, before you even add your first Compose stack. This matters more than it sounds like it should if the container's port ever ends up exposed past your own machine, whether through a reverse proxy, a Tailscale node, or a port forward you forgot about.

Managing More Than One Host

My own cluster is three Proxmox nodes on the same LAN, so for me the simplest option covers it: mount the Docker socket on each host's own Dockhand-adjacent container, or point Dockhand at a second host's Docker API directly over TCP if it's already reachable on the network. Neither needs anything extra installed.

Where it gets more interesting is Hawser, Dockhand's own lightweight agent for hosts you can't reach directly, a VPS behind NAT, a box with a dynamic IP, or anything on a network you don't control the firewall for. Instead of Dockhand connecting in, Hawser connects out: it opens an outbound, TLS-encrypted WebSocket connection back to your Dockhand instance, so there's no port to forward and no inbound firewall rule to remember on the remote end. It's not something a single-LAN homelab like mine needs today, but it's exactly the feature that makes Dockhand worth a second look if you ever end up managing a box at a friend's place or a cheap VPS alongside your own cluster.

What You Actually Get

Beyond the basic start/stop/restart container management every Docker UI offers, the features that actually differentiate Dockhand:

Vulnerability Scanning

Built-in Grype and Trivy scans on your images, with safe-pull protection that checks an update before it replaces a running container, free on every tier rather than gated behind a paid plan.

GitOps & Compose

A visual Compose editor plus Git webhook auto-sync, so a stack can redeploy itself the moment you push a change to the repo it's tracking.

Auth & Access

Free OIDC/SSO and TOTP multi-factor authentication on every tier; role-based access control and LDAP/AD integration are reserved for the paid Enterprise tier.

Monitoring & Secrets

A Prometheus metrics endpoint, a browser-based terminal and file browser, and integrations for pulling secrets from 1Password, Vault, Infisical, Doppler, Bitwarden, or KeePassXC instead of hardcoding them into a compose file.

A Few Things I'd Get Right From the Start

1. Set up authentication before touching anything else

Worth repeating: the default is wide open. Settings → Authentication, first thing, every time, on every new instance.

2. Don't expose port 3000 straight to the internet

Put it behind a reverse proxy with real TLS, or keep it on a VPN/Tailscale-only network, the same rule that applies to any container-management UI with this much reach into your infrastructure.

3. Stick with SQLite unless you have a specific reason not to

It's plenty for a homelab, and it's one less service to keep patched and backed up. Only reach for the DATABASE_URL Postgres option if you're already centralizing other services' databases there.

4. Reach for Hawser only when you actually need it

A direct socket mount or TCP connection is simpler for anything already on your LAN. Hawser earns its keep specifically for hosts behind NAT, a dynamic IP, or a firewall you don't control.

5. Turn on vulnerability scanning from day one

It's free on every tier, so there's no reason to leave it off. Catching an image with a known CVE before you deploy it is a lot less work than tracing back through logs after the fact.

Frequently Asked Questions

Is Dockhand free to use?

Yes, for personal and homelab use. It's source-available under the Business Source License 1.1 (which converts to Apache 2.0 in 2029), and the free tier already includes container and Compose stack management, Git integration, OIDC/SSO, MFA, and vulnerability scanning. The paid SMB and Enterprise tiers add things aimed at companies: a commercial license, LDAP/AD integration, environment-scoped RBAC, and audit logging.

Is it safe to leave Dockhand running with its default settings?

No, and this is the one thing to fix before doing anything else. A fresh Dockhand instance ships with authentication turned off, so anyone who can reach port 3000 has full control over every container on that host. Go to Settings, then Authentication, and create an admin account before you do anything else with it, especially if it's reachable from more than just your own machine.

Can Dockhand fully replace Portainer?

For a Docker-only homelab or small team, yes, and it does a few things Portainer only offers on a paid tier, like free OIDC/SSO and built-in vulnerability scanning. Where Portainer still wins is broader orchestration support, since it also manages Kubernetes and Swarm clusters. If Docker is the only thing you're running, Dockhand is worth switching to; if you also manage Kubernetes, Portainer's wider platform support still matters.

Does Dockhand work on Synology, QNAP, or Unraid?

Yes. Since it ships as a single Docker image, it runs anywhere Docker does, and the project lists native support for Synology, QNAP, and Unraid alongside a plain Linux host. The install is the same regardless of platform: pull the image, mount the Docker socket, and give it a data volume.

How does Dockhand manage more than one Docker host?

Three ways: mounting the local Docker socket for the host Dockhand itself runs on, connecting to a remote host's Docker API directly over TCP, or installing the Hawser agent on a remote host that isn't directly reachable. Hawser is the one built for hosts behind NAT or a firewall: it opens an outbound WebSocket connection back to Dockhand, so there's nothing to port-forward on the remote side.

Should I use SQLite or PostgreSQL for Dockhand's database?

SQLite is the default and it's plenty for a single homelab instance; it's created automatically with zero setup. PostgreSQL is worth switching to only if you're already running a Postgres server for other services and would rather centralize backups there, or if you're running Dockhand at a scale where SQLite's single-writer model starts to matter, which isn't a homelab-sized problem.