Docker Commander is a self-hosted monitoring and control panel for Docker — live stats and logs, Compose, alerting and per-user permissions across every host you run. No external database, no agents, no cloud account.
brew install koduj-dev/tap/dockercmd
dockercmdPrefer Docker, a raw binary or go install? All four are below.
Why bother
There is no shortage of Docker dashboards. These are the four things that tend to decide it.
Download one CGO-free executable with the web UI compiled into it and run it. No database server to provision, no agent to install on each host, no reverse-proxy prerequisite. State goes in an embedded SQLite file inside the data directory. It listens on 127.0.0.1:8470 and that is the whole install.
Most dashboards stop at read-only. Here the container that just spiked is one click from its logs, a shell, its files, its limits and a restart — so diagnosing and acting are not two different tools.
Argon2id passwords, TOTP 2FA or passkeys, named roles that can be scoped to specific hosts, read-only accounts, an audit log, secrets encrypted at rest and native HTTPS. Local-only by default, so exposing it is a deliberate step you take.
Self-hosted and MIT licensed. No account, no cloud tenant, no telemetry: the only request it makes on its own is the update check against GitHub Releases. Everything else it talks to is something you configured.
Author’s note
Docker Commander grew out of two very practical needs.
First, I wanted a simpler way to keep my own Docker hosts under control. When something went wrong, I was tired of jumping between SSH sessions, docker stats, logs, Compose files and several tools that each solved only one part of the problem. I wanted one place where I could see what was happening, investigate it and act immediately.
The second reason came from teaching. At the university, students need to work with real containers, images, networks, volumes and Compose projects — but too much of the lesson can easily disappear into fighting the command line, permissions and configuration details instead of understanding how Docker actually works.
The goal was never to hide Docker behind a simplified toy interface. Docker Commander exposes the real objects and operations, but makes them easier to discover, inspect and control. Students can see how the pieces fit together, while experienced users can still reach the logs, shell, files, raw configuration and lifecycle controls they need.
What began as a small helper for my own servers and university classes gradually became a broader open-source project. The original principle has remained the same: infrastructure tooling should remove unnecessary complexity, not introduce another stack that needs to be maintained.
Built by
Software developer & university lecturer
Filip Majerík is a software developer, university lecturer and long-time builder of web-based systems. Docker Commander is developed under his direction, shaped by practical infrastructure work, classroom experience and an unreasonable number of occasions spent explaining bind mounts.
He reviews the architecture, behavior and security-sensitive parts of the project, while using AI-assisted development extensively for implementation, testing and documentation.
How much of this was written with AI, and what that does and does not mean, is spelled out further down — and every line of it is public in the repository.
Who it is for
The same binary serves a single NAS and a small fleet — what changes is which half of the feature set you end up living in.
A dozen containers on a NAS or a mini-PC, plus a laptop that is offline half the time. Add hosts over SSH, disable the ones that sleep, and get an email when something crash-loops.
Staging and production on a few VPS boxes, with people who need different amounts of access. Give reviewers read-only, scope an operator to staging only, and keep an audit trail of who did what.
When something is on fire at 03:00 you want aggregated logs with regex, live CPU and memory history, and a shell — from a phone-friendly UI rather than three SSH sessions.
Students meet real containers, images, networks, volumes and Compose projects through an interface that shows the Docker model rather than hiding it — so a lesson is spent on how Docker works, not on shell quoting and file permissions.
Let Claude Code, Claude Desktop or Cursor read your container state and perform safe restarts and deploys through an opt-in MCP server that reuses your own permissions.
Features
Eight areas, all in the same binary. Nothing here is reserved for a paid tier — there isn't one.
Live and historical, across every host you have added.
Full lifecycle, not a read-only window.
Discovered stacks and managed projects, edited in place.
Agentless. Local, TCP+TLS or SSH.
Rules that reach you where you already look.
Multi-user with real boundaries.
Opt-in, and narrower than your own account.
Boring to run, on purpose.
A per-feature user manual — one page per screen — lives in the docs folder.
Screenshots
All 23 screens are captures of the running app. Filter by area, or click any one to enlarge.
Install
Pick a route. All four end at http://127.0.0.1:8470, where you create the admin account and scan a QR code for 2FA. Needs Docker Engine 24 or newer (API 1.43+).
Multi-arch (amd64/arm64), distroless, non-root, read-only root filesystem.
docker run -d --name dockercmd \
-p 127.0.0.1:8470:8470 \
--group-add "$(stat -c '%g' /var/run/docker.sock)" \
--read-only --tmpfs /tmp \
--security-opt no-new-privileges \
--cap-drop ALL \
-v /var/run/docker.sock:/var/run/docker.sock \
-v dockercmd-data:/data \
ghcr.io/koduj-dev/docker-commander:latestOn rootless Docker or Docker Desktop the socket is owned by your user — drop the --group-add line. In production, pin an immutable @sha256 digest instead of :latest.
macOS and Linux. Installs the signed release binary for your OS and architecture.
brew install koduj-dev/tap/dockercmd
dockercmd --versionGrab your OS and architecture from the Releases page. Debian/Ubuntu and Fedora users can take a .deb or .rpm, which sets up the systemd service.
chmod +x dockercmd-linux-amd64
./dockercmd-linux-amd64 # http://127.0.0.1:8470
sudo ./dockercmd-linux-amd64 --install-service # optional: run it 24/7On Windows, run dockercmd-windows-amd64.exe from a terminal.
Needs Go ≥ 1.25 and Node.js ≥ 18 to build the UI, plus a running Docker daemon.
git clone https://github.com/koduj-dev/docker-commander.git
cd docker-commander
make build # builds the UI, then embeds it in the binary
./dockercmd # http://127.0.0.1:8470Or, without the UI build step: go install github.com/koduj-dev/docker-commander/cmd/dockercmd@latest
Compatibility
Most tools just claim a version floor. A nightly job instead points the whole Docker integration suite at a pinned build of each Engine major below and reports what actually happens — so this list is a live result, not a guess.
Minimum Engine API 1.43 (Engine 24) · docker compose plugin v2 or newer — legacy docker-compose v1 is not supported · the client SDK negotiates down to whatever your daemon speaks, so a newer build talks to an older one without any configuration.
See tonight's runAI tools over MCP
An optional Model Context Protocol server exposes Docker Commander to Claude Code, Claude Desktop and Cursor. It was designed around what an AI agent should not be able to do.
Off unless you turn it on
The server is not mounted at all without DC_MCP_ENABLED — the routes return a bare 404. Nothing to opt out of.
Two ways to authenticate
A bearer API token from a self-service page, or OAuth 2.1 with PKCE and dynamic client registration for Claude Desktop and Cursor.
A token can only narrow your rights
Every call reuses the app’s RBAC. A token may be restricted to a subset of sections, a subset of hosts, and made read-only — it can never widen what your account can do.
Dangerous verbs are simply absent
No exec or shell, no image export, no file reads, no prune, no remove. Not gated behind a flag — not implemented in the MCP surface.
A ceiling on how fast it can act
Changes are capped per user per minute, so a model stuck in a loop — or a stolen token — is bounded to a few containers rather than your whole estate. Reads are not throttled; only writes are.
Around 25 read tools — including diagnostics and the alerting surface — plus safe control: start, stop, restart a container or a whole stack, deploy or down a project, and a Trivy scan. With MCP resources and prompts. Point Claude Code at it:
# on the server
dockercmd -mcp-enabled -mcp-public-url https://docker.example.com
# on your machine
claude mcp add --transport http docker-commander \
https://docker.example.com/mcp \
--header "Authorization: Bearer <your-token>"
The OAuth server is self-contained (RFC 8414 / 7591 / 8707, PKCE S256, audience-bound and client-bound JWTs, rotating refresh — revoking a client takes effect immediately, not at token expiry) and was exercised with adversarial security tests — alg=none, code and refresh replay, redirect smuggling, CSRF, IDOR.
Security & supply chain
Two separate questions: can you trust the binary you downloaded, and can you trust it once it is running. Both have concrete answers — but neither changes what mounting the Docker socket grants, which is a deployment decision rather than an application one.
Every release ships checksums, a keyless cosign signature bundle covering the binaries and an SPDX SBOM, plus per-binary build provenance. The container image is signed and carries SLSA provenance as well. Three commands prove the artifact came from the release workflow in this repository and nowhere else.
Checksums
Every release ships SHA256SUMS covering the binaries and the SPDX SBOM.
Keyless signature
A cosign bundle signs those checksums, tied to the release workflow identity. Needs cosign v3+.
Build provenance
Each binary and the container image carry SLSA provenance attestations.
# 1. Checksums
sha256sum -c SHA256SUMS --ignore-missing
# 2. Keyless signature
cosign verify-blob --bundle SHA256SUMS.bundle \
--certificate-identity-regexp '^https://github\.com/koduj-dev/docker-commander/\.github/workflows/release\.yml@refs/tags/v' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com SHA256SUMS
# 3. Build provenance
gh attestation verify dockercmd-linux-amd64 --repo koduj-dev/docker-commanderReleases
Read straight from the repository's releases API, then summarised automatically: each entry keeps the pull-request titles GitHub generated, minus the dependency bumps and release chores. Nothing here is hand-written — for the full text, follow through to the release notes.
Built from the koduj-dev/docker-commander releases API
All releasesPrefer the long form? The changelog follows Keep a Changelog, and the roadmap records what is shipped versus merely intended.
Comparison
All four are good tools and several of them overlap — this is where Docker Commander is deliberately different. Compiled from each project's public documentation in August 2026.
| Capability | Docker Commander | Portainer CE | Dozzle | Lazydocker |
|---|---|---|---|---|
| Interface | Web UI | Web UI | Web UI | Terminal UI |
| Scope | Monitor + full control | Monitor + full control | Monitor + optional controlStart/stop/restart/update are opt-in and role-gated, off by default | Monitor + control |
| Runtime dependencies | One binary, embedded SQLite | Container with embedded DB | One binary | One CLI binary |
| Multi-host | YesAgentless — TCP+TLS or SSH | YesVia an agent per host | YesVia an agent per host | Not built inLocal daemon only |
| Two-factor / passwordless login | YesTOTP or WebAuthn passkeys, enforced by default | Not built inPassword (+ LDAP/OAuth) — no 2FA documented | Not built inLogin itself is optional and off by default; no 2FA | Not built inNo login — local socket only, no network auth |
| Aggregated logs across containers | YesLevel detection, regex, parse rules | Not built inPer container | YesIts whole purpose | Not built inPer container |
| Built-in alert rules → webhook / email | YesState, resource, log-pattern, crash-loop → webhook & e-mail | Not built in | PartiallyLog, metric & event alerts → webhook/Slack/Discord/ntfy, no e-mail | Not built in |
| Prometheus exporter | Yes | Not built in | Not built in | Not built in |
| Compose editing in the UI | YesValidated editor + templates | PartiallyStack definitions | Not built in | Not built in |
| MCP server for AI assistants | YesOff by default, RBAC-scoped, read + safe control | Not built in | PartiallyOff by default, read-only (no control tools) | Not built in |
| Image vulnerability scanning | YesTrivy, in-app | Not built in | Not built in | Not built in |
A cross has one meaning here: not documented as a built-in feature in the source above. Several of these projects cover the same ground through plugins, agents or a paid edition.
Roadmap
Ideas, not promises — none of these has a date. The project's notes are deliberate about separating what shipped from what is merely intended.
Deployment revisions and rollback
An immutable history of every deploy — compose file, resolved config, image digests, who and why — with diff, preview and restore. The highest-value item on the list: today you can change a deployment, but not undo one.
Maintenance windows and silences
Suppress notifications during planned work without turning monitoring off, scoped by host, stack, container, rule or severity — the alert is still recorded, just not paged.
Policy checks before deploy
Refuse or warn on privileged containers, host network or PID, a mounted Docker socket, :latest in production, or missing resource limits and healthchecks — tying validation, linting and scanning that already exist to an actual decision.
OIDC / SSO
Google, Azure and Okta login. LDAP — including group → role mapping — was step one.
ACME / Let’s Encrypt
Self-signed certificates ship today; still open is automatic issuance and renewal for a public hostname.
Windows native service
The binary installs itself as a systemd unit on Linux and a launchd agent on macOS; Windows currently goes through a Scheduled Task script rather than a real SCM-managed service.
FAQ
Including the awkward ones.
Neither. State lives in an embedded SQLite file (pure Go, no CGO) inside the data directory, and remote hosts are reached over the Docker Engine API via TCP+TLS or SSH — there is nothing to install on them. Redis is optional, and only to keep metric history across restarts; without it history sits in an in-memory ring.
Treat it as you would any panel that can control your host. It binds to 127.0.0.1:8470 by default; TOTP 2FA or a passkey is enforced unless an admin turns on the localhost exemption — which only ever applies to an actual direct loopback connection, never one arriving through a reverse proxy, however it presents itself. There are named roles that can be scoped to specific hosts, read-only accounts, rate limiting, an audit log, and your own live sessions are visible and revocable from your profile. If you publish it, terminate TLS at a reverse proxy or use the built-in HTTPS, and keep that localhost exemption off.
Host-root-equivalent access. Anyone who reaches the UI — or escapes the app — controls the daemon, and therefore the machine. That is true of every Docker management tool, so the honest advice is: keep it on localhost or behind HTTPS with strong auth, and never expose it unauthenticated.
No. It is an independent open-source project with no affiliation, sponsorship or endorsement from Docker, Inc. It talks to the Docker Engine API like any other client. "Docker" is a trademark of Docker, Inc.
Roughly 95% — code, tests and docs — using Claude Code, under human direction and review. Every release goes through CI on top of roughly 600 Go unit tests, 147 frontend tests and 115 adversarial "pentest" cases that assert attacks are rejected (token forgery, CSRF, IDOR, path traversal, per-host scope bypass), plus integration and multi-daemon tests against real Docker hosts. The tree is also periodically swept by an independent adversarial review on Claude Fable 5 — not an independent third-party audit or penetration test.
No telemetry, no analytics. The only automatic outbound request is the update check against GitHub Releases, which is what puts the "update available" banner in front of an admin; and otherwise only talks to whatever you configure yourself — your Docker hosts, your SMTP server, your webhooks, your registries.
No. It reads and writes through the Docker API like the CLI does, so containers and stacks you created elsewhere show up and stay manageable — compose stacks are discovered by label whether they came from this UI or from docker compose in a terminal. Stop using it and nothing needs unwinding.
Everything is in one data directory: the SQLite database plus the signing and at-rest encryption keys, generated on first run. It defaults to the OS config dir and moves with -data-dir / DC_DATA_DIR; under Docker it is the /data volume. dockercmd --backup <file> writes a complete, portable snapshot — the database plus your projects and templates — through a live connection, so it is safe to run while the server is up; --restore <file> puts it back, and --passphrase encrypts the archive. Treat a backup as secret: it holds the key that decrypts your registry, SMTP and LDAP credentials, and losing an unencrypted copy makes them recoverable by whoever has it.
An admin sees an "update available" banner and can apply it in place — one tap to update and restart. From a shell it is dockercmd --self-upgrade, which verifies the SHA-256 and swaps the binary atomically. Running the container image, pull the new tag instead; installed from a .deb or .rpm, use your package manager. The data directory is untouched either way, so an upgrade is not a migration.
Release binaries cover linux/amd64, linux/arm64, darwin/amd64, darwin/arm64, windows/amd64 and windows/arm64, plus .deb and .rpm packages and a multi-arch container image. The binary can install itself as a systemd unit on Linux or a launchd agent on macOS.
Engine API 1.43 or newer — that is Docker Engine 24 and up — and the docker compose CLI plugin v2 or newer (the legacy docker-compose v1 is not supported). The client SDK negotiates down to whatever your daemon speaks, so a newer build talks to an older engine without any configuration. This is not a guess: a nightly workflow runs the full Docker integration suite against Engine 24 through 28 and reports the result, so the floor is measured rather than remembered.
MIT. Use it commercially, fork it, ship it inside something else — no feature is held back for a paid tier, because there is no paid tier.
Something not answered here? Ask in the issue tracker — questions are welcome, not just bug reports.
Docker Commander is an independent open-source project, developed with no affiliation to Docker, Inc. — no support, no sponsorship, no endorsement. It is not part of Docker Desktop, Docker Hub or any commercial Docker offering, and no one at Docker, Inc. reviews or approves it.
It is a third-party client of the public Docker Engine API — the same interface the docker CLI uses. “Docker” and the Docker logo are trademarks or registered trademarks of Docker, Inc., used here only to describe what this software works with.
If you represent Docker, Inc. and consider any use of the marks on this page or in the project inappropriate, please open an issue and it will be corrected.
Code, tests and documentation were largely produced with Claude Code, under human direction and review. This is stated up front because you are about to give this software control of your Docker daemon, and that is a decision you should make knowingly.
What that does not mean is unreviewed output. Every change goes through CI on top of roughly 600 Go unit tests and 147 frontend tests, 115 adversarial "pentest" cases that assert attacks are rejected, and integration tests against a real daemon. The tree is also periodically swept by an independent adversarial review on Claude Fable 5.
Docker Commander is provided under the MIT license, “as is”, without warranty of any kind. You are responsible for how you deploy it and for what it is allowed to reach — see the note about the Docker socket in the install section.
Support the project
Docker Commander is MIT licensed with no paid tier and nothing held back. If it saves you time, there are three ways to help — two of them free.
Costs nothing and is the signal other people actually use when deciding whether a self-hosted tool is alive.
Star on GitHubA precise bug report is worth more than most patches. Feature requests and pull requests are read and answered.
Open an issueThrough GitHub Sponsors, one-off or monthly. It covers the domain, the signing infrastructure and the hours — it does not buy the software, which is free either way.
Sponsor on GitHubSponsoring buys nothing, because there is nothing to buy: Docker Commander is MIT licensed, every feature ships in the public release, and no capability will ever sit behind a paywall. A sponsorship supports the person maintaining it — it carries no support commitment, no priority and no influence over the roadmap, and it is not a tax-deductible donation.
It is one binary and a named volume. If you do not like it, delete both — nothing on your Docker hosts was changed to accommodate it.
docker run -d --name dockercmd \
-p 127.0.0.1:8470:8470 \
--group-add "$(stat -c '%g' /var/run/docker.sock)" \
--read-only --tmpfs /tmp \
--security-opt no-new-privileges \
--cap-drop ALL \
-v /var/run/docker.sock:/var/run/docker.sock \
-v dockercmd-data:/data \
ghcr.io/koduj-dev/docker-commander:latestRead-only root filesystem, no added capabilities, no privilege escalation, bound to localhost. On rootless Docker or Docker Desktop, drop the --group-add line.
docker run -d --name dockercmd -p 127.0.0.1:8470:8470 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v dockercmd-data:/data \
ghcr.io/koduj-dev/docker-commander:latestFewer flags, and correspondingly fewer guardrails. Fine for a throwaway look on a machine you do not mind losing; the hardened form above is what belongs on anything you keep.
MIT licensed · no account · no telemetry · Linux, macOS and Windows