Dockhand: a self-hosted Docker management UI built on SvelteKit and Bun

What Dockhand is for and who should run it

Dockhand is a web application that sits in front of the Docker API. The README describes it as a "modern, efficient Docker management application providing real-time container management, Compose stack orchestration, and multi-environment support." That sentence covers the whole product: it is not a Docker replacement, not a container runtime, and not an orchestrator. It is an interface to Docker daemons you already run.

The audience is narrow and identifiable. If you manage one Docker host on a laptop, the docker CLI is faster than any browser tab. Dockhand starts to pay off when you have several hosts, when you want a visual Compose editor that shows YAML next to environment variables, or when you want a Git repository to be the source of truth for a stack and have a webhook trigger the deploy. The README lists exactly these cases: multi-environment management, a visual editor for Compose deployments, and Git integration with webhooks and auto-sync.

The project is written in TypeScript and the repository layout confirms the stack: SvelteKit under src/, a Drizzle schema split between drizzle/ and drizzle-pg/, and a server.js entry point. The package.json version field reads 1.0.46 while the most recent release listed is v1.0.48, so the version string in the manifest lags the release tag. That is a small thing, but it means you should trust the release tag rather than the manifest when you are pinning an image.

How Dockhand talks to Docker: socket, agent or TCP

Dockhand does not proxy Docker traffic through its own daemon. The README states the Docker layer uses "direct docker API calls", and the screenshots describe three connection modes when adding an environment: socket, agent or direct TCP. The bundled docker-compose.yaml shows the socket path in practice, mounting /var/run/docker.sock into the container alongside a named volume at /app/data.

That mount is the single most important design decision in the deployment. Mounting the Docker socket gives the container effective root on the host, because anything that can talk to the socket can start a privileged container. Dockhand's own Dockerfile is security-minded in other respects: it builds an OS layer from Wolfi packages via apko, with every package declared explicitly, and the comment at the top explains the runtime choice. The image uses Node.js rather than Bun "to eliminate BoringSSL native memory leaks on mTLS connections", even though the application itself runs on Bun in development. That is a concrete, documented trade-off rather than a marketing claim.

State lives in SQLite or PostgreSQL through Drizzle ORM. The repository carries two migration directories, drizzle/ and drizzle-pg/, plus a separate docker-compose-postgresql.yaml for the Postgres path. If you care about audit history surviving a container rebuild, that choice matters more than the frontend framework.

Installing Dockhand with Docker Compose

The repository ships a compose file that is short enough to read in full. It pulls the published image, maps port 3000, mounts the Docker socket and a named volume for application data. Copy it or write the equivalent:

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:

Start it with the standard command:

docker compose up -d

After the container reports healthy, open http://localhost:3000 in a browser. According to the README, the first screen you land on is the environments overview, where you register a Docker host. For a single-host setup the socket mount above means the local daemon is already reachable; for a remote host you choose the agent or direct TCP option shown in the add-environment screenshot.

The README does not document a first-run setup wizard, an initial admin credential or a required environment variable. The documentation link points to https://dockhand.pro/manual, which is where the project says setup details live. Treat that manual as the authority for anything beyond the compose file, because the README stops at the feature list.

Compose stacks, Git deploys and the scheduler

The Compose side is where Dockhand differs from a plain container list. The README describes a visual editor that edits YAML side by side with environment variables, and a stack graph editor for services, networks and secrets. A separate screenshot covers deploying from Git: pull stacks from repositories with webhooks and auto-sync. In practice that means a stack can be defined in a Git repo, and a push can trigger a redeploy without anyone opening a terminal.

There is also a schedules screen, described as cron-style automation for prune, updates and cleanup. This is the feature most likely to cause damage if configured carelessly, because automated image pruning removes things you may still want. The README does not state what a prune schedule removes, whether dangling images and unused volumes are treated differently, or whether a schedule can be scoped to one environment. That gap is worth respecting: set schedules up on a host you can afford to lose images on before you point them at production.

The remaining features are the expected set for this category: interactive shell and log streaming, a container file browser, a volume browser, an image layer inspector, and vulnerability scanning that the README attributes to Grype and Trivy. Authentication covers local users, SSO via OIDC, and optional RBAC that the README marks as Enterprise. The activity log records actions across environments, which is the feature that makes the multi-host story coherent rather than a set of disconnected dashboards.

Where Dockhand falls short

The licence is the first constraint, and it is easy to misread. Dockhand is under the Business Source License 1.1, not an OSI-approved open source licence. The README states it is free for personal use, internal business use, non-profits, education and evaluation, and that offering Dockhand as a commercial SaaS or hosted service is not allowed. It converts to Apache 2.0 on January 1, 2029. So "is Dockhand open source" has a two-part answer: the source is available and you can run it freely for internal work, but you cannot build a hosted product on it today. Anyone evaluating it for a managed-service business needs to read LICENSE.txt rather than the README summary.

The second gap is operational documentation. The README does not document rollback, does not describe how to upgrade between versions, and does not mention database migration steps for the SQLite or PostgreSQL backends. The repository has a VERSION file and a release cadence measured in days (v1.0.46 on 2026-09-02, v1.0.47 on 2026-09-12, v1.0.48 on 2026-09-14), which means you will upgrade often if you track releases. Pinning fnsys/dockhand:latest in production is therefore a decision you should make deliberately rather than by default.

Third, the socket mount is a real security boundary. Dockhand's own image is hardened, but that hardening does not extend to what the socket grants the running container. If your policy forbids socket mounts, the agent or TCP connection modes are the alternative, and the README does not detail what the agent runs or how it authenticates beyond naming it as an option.

Dockhand compared with Portainer

Portainer is the obvious comparison, and the search data suggests it is the comparison people actually make. Both are self-hosted web UIs over the Docker API, and both cover containers, stacks, images and volumes. The difference in approach is where the state and the licence sit. Dockhand keeps its data in SQLite or PostgreSQL that you supply, with the schema managed through Drizzle ORM and two separate migration trees in the repository. Portainer's model is a single product with its own database and a commercial edition gating features; Dockhand's gating is narrower and explicitly named in the README, which marks RBAC as Enterprise and leaves the rest of the feature list unqualified.

A second difference is the deployment surface. Dockhand's documented install is one compose file with one image and one volume, and the project builds its base OS from Wolfi packages declared in the Dockerfile. That is a supply-chain posture you can audit by reading the Dockerfile, which is not typical for this category. If your reason for choosing a Docker UI is that you want to read exactly what is in the image, Dockhand gives you that.

Where Portainer still wins is breadth of documentation. Dockhand's README is a feature list with screenshots; the manual at dockhand.pro/manual is where the operational detail lives, and the README does not preview it. If you need a written upgrade path, backup procedure and rollback plan before you deploy, verify those exist in the manual first.

Maintenance, upgrades and licence cost

The maintenance picture is straightforward from the repository data. The project is not archived, the last push was on 2026-09-20, and three releases landed in the two weeks before that. That is a fast cadence, and it cuts both ways: fixes arrive quickly, and so do changes you did not plan for.

Upgrade cost is mostly unquantified. The repository contains an updater/ directory and the package.json exposes a check script that runs svelte-kit sync and svelte-check, but the README does not describe what the updater does, whether it migrates the database, or whether a downgrade is possible. The two migration directories suggest schema changes are versioned, but the README does not say how they are applied on startup. If you run Dockhand against PostgreSQL, the separate docker-compose-postgresql.yaml exists, but the README does not compare the two backends or recommend one.

On licence cost, the practical reading is that internal use is free and stays free, and that the BSL only bites if you resell Dockhand as a hosted service. The conversion date of January 1, 2029 means the restriction is time-limited. This is not legal advice; the full terms are in LICENSE.txt, and the README's summary is a summary.

Editorial conclusion

Adopt Dockhand if you run several Docker hosts and want a browser UI for containers, Compose stacks and Git-based deploys without a commercial SaaS contract. Do not adopt it if you need an OSI-approved licence for redistribution, or if you need documented rollback and upgrade procedures, because the README does not describe either. Before committing, verify the licence text in LICENSE.txt against your own use case, confirm which features the README marks as Enterprise, and check that the Docker socket mount the compose file uses is acceptable in your security model.

Frequently asked questions

Official sources

1. Finsys/dockhand on GitHub
2. Issues
3. Project website
4. README
5. Releases