dockman manages Compose files without taking them over

The premise is that the Compose files stay yours

Dockman describes itself as a Docker management tool for users who want unfiltered access to their Docker Compose files, and the project tagline in the README is that it is yet another Docker Compose manager for homelabs.

That framing is the whole pitch. A number of container management interfaces treat your deployment as their own state: you import or paste a stack into the tool, the tool stores it, and the tool decides how it is applied. Dockman is positioned against that, on the side of the files staying where they are and staying plain.

The audience is stated as homelabs, and the feature set follows from that. A homelab is a handful of stacks on one machine, usually with a domain in front of them, often without a budget for a platform product, and usually run by one person who wants a dashboard rather than a terminal. The documentation site is dockman.radn.dev, with an install category and an introduction page, and the project also runs a website directory in the repository alongside the core, pkg, ui and spec directories.

The repository layout is worth reading as a description of the architecture. core/ is the Go or TypeScript backend, ui/ the frontend, pkg/ the packaging including a Dockerfile, spec/ the specification of the behaviour, and website/ the documentation site itself, with a Caddyfile at the root and a Taskfile.yml for the build tasks.

The quick start command and the warning attached to it

The install documentation leads with a single container, and it is worth reading the warning that comes with it.

docker run --rm -p 8866:8866 -e DOCKMAN_LOG_AUTH_WARNING=false -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/ra341/dockman:latest

The warning is explicit: this quick-start command will delete all Dockman data when the container stops, and it should be used only for testing. The persistent alternative is the Compose setup.

The command itself shows the three moving parts. The port mapping publishes 8866, which is the port the README says to access at http://localhost:8866. The volume mounts the Docker socket, which is how the tool reaches the daemon. And the environment variable sets DOCKMAN_LOG_AUTH_WARNING to false, which is the tool warning that it is running without authentication.

That last flag is the most consequential thing in the line, and it is worth pausing on. A web interface with the Docker socket mounted is effectively root on the host, and Dockman tells you so at startup unless you tell it not to. Turning the warning off is exactly the kind of switch that gets set once in a hurry and forgotten. The Compose example that follows does not set it.

The compose path, and the rule about three identical paths

The recommended setup is a Compose file of its own, and the documentation puts an important note at the top of it: the stacks directory path must be absolute and identical in all three locations.

services:
  dockman:
    container_name: dockman
    image: ghcr.io/ra341/dockman:latest
    environment:
      - DOCKMAN_COMPOSE_ROOT=/path/to/stacks
    volumes:
      - /path/to/stacks:/path/to/stacks
      - /path/to/dockman/config:/config
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - "8866:8866"
    restart: always

The three locations are the environment variable DOCKMAN_COMPOSE_ROOT, the host side of the stacks volume, and the container side of that same volume. The documentation says this path consistency is essential for Dockman to locate and manage your compose files properly.

Two details beyond the path rule are visible in the file. The config is on a separate volume at /path/to/dockman/config, mounted at /config, which is where the persistent state lives as opposed to the stacks, and the service has restart: always, which is what makes the setup survive a reboot.

The point of the rule is that Dockman resolves the stacks directory on the host and then sees the same directory inside the container. If the two differ, the tool looks for files in a place that does not contain them, and the symptom is an empty interface rather than an error message.

The authentication options in the configuration

The development Compose file in the repository shows the authentication settings that the tool understands, and they are worth reading because they tell you what a deployment can be made to look like.

The variables are DOCKMAN_AUTH_ENABLE and DOCKMAN_AUTH_OIDC_ENABLE, then the OpenID Connect settings: DOCKMAN_AUTH_OIDC_ISSUER, DOCKMAN_AUTH_OIDC_CLIENT_ID, DOCKMAN_AUTH_OIDC_CLIENT_SECRET and DOCKMAN_AUTH_OIDC_REDIRECT_URL. The redirect URL in the example points at http://localhost:8866/api/auth/login/oidc/callback, so the OIDC callback is handled by the Dockman server itself rather than by a proxy.

So there are two layers to switch on, a general authentication flag and an OIDC flag, and the OIDC route expects an external identity provider. That is enough for a homelab that already runs an identity service, and it is where the development file gets its own.

The file also shows how the pieces are meant to fit together in a real deployment. The Dockman service depends_on a service called pocket-id, which is an instance of ghcr.io/pocket-id/pocket-id:latest, and a Caddy container sits in front with ports 80 and 443, a mounted Caddyfile and its own data and config volumes, all three services joined on a network called pocket-id-net. The Caddyfile at the repository root is the configuration for that reverse proxy.

The file also carries a note at the top: it is a development Compose file used to test Dockman with various services and it is not the recommended way to set it up.

AGPL-3.0, a security policy, and a busy release line

The licence is the GNU Affero General Public License v3.0, with the LICENSE file at the repository root. For a self hosted tool that most people run on their own hardware, the AGPL is a reasonable choice, but it is worth knowing that it is a copyleft licence with network use provisions, which matters if you plan to modify it and offer the modified version as a service.

The repository also carries a SECURITY.md, so vulnerabilities have a defined reporting path, and a CONTRIBUTING.md that the README points to for the contribution process.

The release history is steady and the version numbers suggest a project that has been through a couple of structural changes recently. The recent tags are v3.2.0 on 2026-02-13, v3.1.0 on 2026-01-12 and v3.0.0 on 2026-01-02, so the 3.x line arrived at the start of 2026 and has been adding minor versions since. The repository is not archived and the last push was on 2026-09-24, so work is continuing after the last release.

The build tooling is a Taskfile.yml for the task runner, a .releaserc.json for the release configuration, a .nvmrc pinning the Node version for the frontend work, and a docker-compose.yml that, as noted, doubles as a development harness rather than a deployment template. The Docker image is published to GitHub Container Registry as ghcr.io/ra341/dockman.

The alternative, and what the socket mount commits you to

The alternative to a Compose manager of this kind is the plain Docker Compose command line, with a text editor, a version-controlled stacks directory and a make target that runs compose up. That approach has no web interface, no dashboard and no log view, and it is the approach that scales with one operator who already knows the commands.

The difference in approach is where the state lives. A tool that stores its own project database can present a rich interface but becomes the source of truth, and the files on disk become an export. Dockman is built the other way round, so the Compose files remain the source of truth and the interface is a view onto them.

The cost is the one the documentation keeps pointing at. Mounting /var/run/docker.sock gives the container, and therefore anyone who can reach the web interface, the ability to control the Docker daemon on the host, which is close to root. A tool that only ran Compose commands as a limited user would not have that property.

So the decision is a package: a web interface over your own files, in exchange for a socket mount and an exposed port. The mitigation is the one the project provides, which is the authentication flags and the OIDC integration, and the reasonable approach is to put the interface behind a reverse proxy such as the Caddy in the development file, and to set the authentication environment variables rather than switching the warning off.

Editorial conclusion

dockman fits a homelab operator who keeps stacks as plain Compose files on disk and wants a web interface to start, stop and edit them without converting the files into a database owned by the tool. It does not fit a team that wants a hosted, supported platform with role based access, since the authentication options in the configuration are basic and the licence is AGPL. Before deploying it, read the three place path rule, because a mismatched stacks path is the documented cause of Dockman not finding your files, and decide how you will handle the Docker socket mount and the port, which is exposed on 8866.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. RA341/dockman on GitHub
4. README
5. Releases