# Docker Commander — Self-hosted Docker monitoring & control

> Self-hosted, open-source Docker monitoring and control panel. One Go binary, embedded web UI — multi-host, live logs, Compose, alerting, RBAC. MIT.

Source: https://docker-commander.app · Repository: https://github.com/koduj-dev/docker-commander · License: MIT
Latest release: v1.6.2 (18 Aug 2026) · 14 releases · last commit 18 Aug 2026

**Not a Docker, Inc. product.** Independent open-source project with no affiliation,
sponsorship or endorsement from Docker, Inc. It is a third-party client of the public
Docker Engine API. "Docker" is a trademark of Docker, Inc.

One binary. Every container. Full control.

- Single Go binary
- No external database
- No agents
- Linux · macOS · Windows
- MIT licensed

## What it actually saves you

### One binary, zero infrastructure

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.

### See it and fix it in the same place

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.

### Built to sit on a real server

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.

### Your hosts, your data

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.


## Why I built Docker Commander

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 Filip Majerík** — Software developer & university lecturer. https://github.com/malickyeu

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.


## Who it is for

### Homelab & self-hosters

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.

- Agentless SSH hosts
- Disable offline hosts
- Email & webhook alerts

### Small dev teams

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.

- Named roles, scoped per host
- Read-only accounts
- Audit log
- LDAP / AD login

### Ops & on-call

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.

- Aggregated logs + regex
- Historical charts
- Prometheus /metrics
- In-browser shell

### Teaching & labs

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.

- Real Docker objects, not abstractions
- Relationships visible in the topology graph
- Read-only accounts for lab hosts
- Complements the CLI — it does not replace it

### AI-assisted workflows

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.

- Off by default
- Bearer token or OAuth 2.1
- Tokens can only narrow rights
- Changes rate limited & audited


## Features

### Monitor

Live and historical, across every host you have added.

- Live CPU and memory graphs over WebSockets, plus historical charts (Redis or in-memory).
- A dashboard driven by the Docker events stream: host facts, disk usage, per-container share of host CPU and memory, host-wide network throughput, and a port scan that fingerprints what is actually listening.
- Per-container network throughput (derived rate, so a recreate reads as a gap rather than a spike), totals, packets, dropped and errors, plus endpoint totals on a network’s own detail page.
- Per-container log tail and a global aggregated stream with level detection, regex search and saved parsing rules that turn lines into structured columns.
- Events feed, container diff and top, disk usage, and raw JSON inspect for any object.
- Interactive containers-and-networks topology graph with search and compose-stack filtering, plus a compact list view.

### Control

Full lifecycle, not a read-only window.

- Create and run containers, start / stop / restart / pause / unpause / kill, rename, update limits and restart policy, commit to an image, and open an interactive shell (xterm.js). Kill goes through its own confirm — it is SIGKILL for a container that stopped responding to Stop.
- Bulk restart, stop, start and pull across several selected containers at once: a preview of exactly what is targeted, the same confirm dialog, bounded parallelism, and a per-container success/failure summary instead of one toast for the batch.
- File browser inside containers and volumes — list, download, upload, upload-and-extract a .zip / .tar / .tar.gz, delete, create folders.
- Images: pull with live progress, build (with build args), push, tag, save / load / import, history, prune, and vulnerability scanning via Trivy with a severity summary and CVE table.
- Volumes and networks: list, inspect, create, remove, prune — networks also connect and disconnect containers.

### Compose

Discovered stacks and managed projects, edited in place.

- Discover and manage stacks by label — including ones created from the CLI: start, stop, restart, remove, and now edit the compose file in place on the host and redeploy, kept in its original working directory so relative bind mounts and env_file paths still resolve.
- Managed project folders edited in a built-in CodeMirror editor with live inline validation: compose (anchor and ${VAR} aware), Dockerfile via docker build --check, YAML / JSON / .env.
- Resolved preview, services and ports summary, templates, schema-aware Compose autocomplete, and image or tag suggestions from local images, Docker Hub and your private registries.
- Deploy through the docker compose CLI with profiles and .zip import / export — to the local daemon or a remote host, where each bind mount inside the project folder is copied into a named volume on the target and mounts outside it are refused unless the project opts into host paths.
- Moving a project to another host offers to bring it down on the one it is leaving, so a redeploy never leaves two live copies running.

### Multi-host

Agentless. Local, TCP+TLS or SSH.

- Manage local, TCP(+TLS) and SSH daemons — no agent to deploy, it speaks the Docker Engine API.
- SSH host keys are verified against known_hosts with trust-on-first-use; a changed key is refused as a possible MITM.
- Every view rebinds to the selected host and the alert engine watches all of them.
- A per-host detail panel shows hardware, OS and engine, and a host can be disabled to take it out of monitoring.
- Roles can be scoped to specific hosts, so “may restart containers” can mean “on staging, not production” — a host outside that scope is invisible, not just blocked.

### Alerting & integrations

Rules that reach you where you already look.

- Rules on state (die, kill, oom, unhealthy), resource thresholds sustained over N seconds, log patterns, and restart or crash-loop frequency.
- Editable severity and cooldown, targeting containers by name substring.
- Conditions have a lifetime — firing, escalated, eased, resolved — so overlapping thresholds produce one incident instead of one alert each.
- Notify via webhooks with Go-template bodies, email over SMTP with per-rule and per-account recipients, and an in-app feed with a toast on arrival.
- Every webhook call and e-mail send is recorded against its alert with the outcome, so a delivery failure shows instead of looking silently handled.
- The feed is paged, filtered and sorted server-side, with acknowledgement history. A Prometheus /metrics exporter includes live firing conditions, and alert rules import and export as a portable JSON bundle.

### Security & administration

Multi-user with real boundaries.

- Argon2id passwords with TOTP 2FA or passkeys (WebAuthn) — a verified passkey can sign in on its own, with the password kept as the recovery route. Rate limiting, strict headers and signed HttpOnly cookies.
- An account can hold several authenticators, named and listed with last use; TOTP codes and rate limiting on the 2FA step guard against replay and brute-force alike.
- Every account can see its own live sessions — device, address, last used — and end any of them, or all the others at once.
- Named RBAC roles bundle section grants (two ship built in, or duplicate and edit your own), and a role can be scoped to specific hosts. Read-only mode, global feature flags and an audit log sit alongside.
- Optional LDAP / Active Directory login with auto-provisioning; a directory group can grant a named role, not just raw sections, re-derived on every login.
- Registry, SMTP and LDAP secrets — and host TLS private keys — encrypted at rest with AES-256-GCM.
- dockercmd --backup / --restore snapshots the whole installation to one portable, optionally passphrase-encrypted file — and dockercmd --reset-password recovers a locked-out admin without stopping the server.

### AI tools over MCP

Opt-in, and narrower than your own account.

- An off-by-default Model Context Protocol server lets Claude Code, Claude Desktop and Cursor monitor and safely operate Docker as you.
- Around 25 read tools — including diagnostics that don’t need a shell (docker top / diff, cross-container log search) and the alerting surface (history, what’s firing now, rules, delivery) — plus safe control: start/stop/restart a container or a whole stack, deploy/down a project (including to a remote host), preview what a deploy would change, and a Trivy image scan.
- Bearer API tokens or OAuth 2.1 with PKCE and dynamic client registration; every call reuses the app’s RBAC and a token can only narrow your sections, hosts and rights.
- New tokens expire after 30 days by default (admin-configurable), and changes are rate limited per user so a stuck loop or a stolen token is bounded to a few containers rather than the whole estate.
- Deliberately no exec, image export, file read, prune or remove.

### Ops

Boring to run, on purpose.

- Single CGO-free binary with the UI embedded, a systemd unit, a config file, and a /healthz probe.
- Native HTTPS with a built-in --make-certs self-signed helper, or run it behind a proxy.
- Self-install as a service on Linux (systemd) and macOS (launchd); a PowerShell script covers Windows.
- One-tap in-app update and restart for admins, plus dockercmd --self-upgrade with SHA-256 verification and an atomic binary replace.
- A portable, encryptable backup/restore snapshot of the whole installation — database, projects and templates — safe to take while the server is running.


## Install

### Docker

Multi-arch (amd64/arm64), distroless, non-root, read-only root filesystem.

```bash
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:latest
```

On 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.

### Homebrew

macOS and Linux. Installs the signed release binary for your OS and architecture.

```bash
brew install koduj-dev/tap/dockercmd
dockercmd --version
```

### Binary

Grab 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.

```bash
chmod +x dockercmd-linux-amd64
./dockercmd-linux-amd64          # http://127.0.0.1:8470

sudo ./dockercmd-linux-amd64 --install-service   # optional: run it 24/7
```

On Windows, run dockercmd-windows-amd64.exe from a terminal.

### From source

Needs Go ≥ 1.25 and Node.js ≥ 18 to build the UI, plus a running Docker daemon.

```bash
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:8470
```

Or, without the UI build step: go install github.com/koduj-dev/docker-commander/cmd/dockercmd@latest

**Mounting the Docker socket grants host-root-equivalent access.** Whoever reaches the UI — or escapes the app — controls the daemon, and therefore the machine. That is true of every Docker management tool. Keep it on localhost or behind HTTPS with strong authentication; never expose it unauthenticated. The 2FA, per-section permissions and audit log govern access to Docker Commander itself — they cannot shrink the privileges the socket hands over.


## AI tools over MCP

An optional, off-by-default Model Context Protocol server exposes Docker Commander to Claude Code, Claude Desktop and Cursor. Around 25 read tools — including diagnostics that don't need a shell and the alerting surface — plus safe control (start/stop/restart a container or a whole stack, deploy/down a project including to a remote host, preview a deploy, scan an image). Bearer tokens or OAuth 2.1 with PKCE; every call reuses the app's RBAC and a token can only narrow the issuing account's sections, hosts and rights. New tokens expire after 30 days by default, and changes are rate limited per user. Deliberately no exec, image export, file reads, prune or remove.

Documentation: https://github.com/koduj-dev/docker-commander/blob/main/docs/mcp.md


## Security and supply chain

Every release ships SHA256SUMS, a keyless cosign signature bundle covering the binaries and an SPDX SBOM, plus per-binary SLSA build provenance. The container image is signed too.

### Checksums

Every release ships SHA256SUMS covering the binaries and the SPDX SBOM.

```bash
sha256sum -c SHA256SUMS --ignore-missing
```

### Keyless signature

A cosign bundle signs those checksums, tied to the release workflow identity. Needs cosign v3+.

```bash
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
```

### Build provenance

Each binary and the container image carry SLSA provenance attestations.

```bash
gh attestation verify dockercmd-linux-amd64 --repo koduj-dev/docker-commander
```

Once running: Argon2id passwords, TOTP 2FA or passkeys (WebAuthn), named RBAC roles scoped per host, read-only accounts, an audit log, AES-256-GCM encryption at rest for registry/SMTP/LDAP secrets and host TLS keys, an encrypted portable backup/restore, native HTTPS, and SSH host-key verification. Binds 127.0.0.1 by default.


## Releases

Read from the GitHub releases API and summarised automatically from the generated pull-request titles, minus dependency bumps and release chores. Nothing here is hand-written.

### v1.6.2 — 18 Aug 2026

- [Change] [docs] note the per-PR ChatGPT Codex review pass in testing.md
- [Change] [fix] self-update: allow the systemd unit to write /usr/local/bin

Notes: https://github.com/koduj-dev/docker-commander/releases/tag/v1.6.2

### v1.6.1 — 18 Aug 2026

- [Change] [docs] roadmap: backup/DR, drift detection, GitOps, federation, secrets
- [Change] [docs] release/vX.Y.Z branch holds the dev cycle, not main
- [Change] [docs] dependabot PRs stay targeted at main
- (+23 more changes)

Notes: https://github.com/koduj-dev/docker-commander/releases/tag/v1.6.1

### v1.6.0 — 7 Aug 2026

- [New] projects: Ship bind-mounted files on a remote deploy
- [New] projects: Close out the remote-projects follow-ups
- [New] security: Named RBAC roles (phase 1)
- (+82 more changes)

Notes: https://github.com/koduj-dev/docker-commander/releases/tag/v1.6.0

### v1.5.1 — 30 Jul 2026

- [Docs] Bring README features + NEXT.md roadmap up to v1.5
- [Docs] release: Cut 1.5.1
- (+3 more changes)

Notes: https://github.com/koduj-dev/docker-commander/releases/tag/v1.5.1

### v1.5.0 — 16 Jun 2026

- [New] tls: Built-in self-signed cert generator (--make-certs)
- [New] alerts: Import/export alert rules as a portable JSON bundle
- [New] update: One-tap in-app update & restart for admins
- (+10 more changes)

Notes: https://github.com/koduj-dev/docker-commander/releases/tag/v1.5.0


## Comparison

Checked against each project's public documentation in August 2026. A cross means "not documented as a built-in feature" in the source listed below — several of these projects cover the same ground through plugins, agents or a paid edition.

| 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 control (Start/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 | Yes (Agentless — TCP+TLS or SSH) | Yes (Via an agent per host) | Yes (Via an agent per host) | Not built in (Local daemon only) |
| Two-factor / passwordless login | Yes (TOTP or WebAuthn passkeys, enforced by default) | Not built in (Password (+ LDAP/OAuth) — no 2FA documented) | Not built in (Login itself is optional and off by default; no 2FA) | Not built in (No login — local socket only, no network auth) |
| Aggregated logs across containers | Yes (Level detection, regex, parse rules) | Not built in (Per container) | Yes (Its whole purpose) | Not built in (Per container) |
| Built-in alert rules → webhook / email | Yes (State, resource, log-pattern, crash-loop → webhook & e-mail) | Not built in | Partial (Log, 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 | Yes (Validated editor + templates) | Partial (Stack definitions) | Not built in | Not built in |
| MCP server for AI assistants | Yes (Off by default, RBAC-scoped, read + safe control) | Not built in | Partial (Off by default, read-only (no control tools)) | Not built in |
| Image vulnerability scanning | Yes (Trivy, in-app) | Not built in | Not built in | Not built in |

Sources: Docker Commander — https://github.com/koduj-dev/docker-commander/blob/main/README.md · Portainer CE — https://docs.portainer.io/ · Dozzle — https://dozzle.dev/ · Lazydocker — https://github.com/jesseduffield/lazydocker


## Roadmap

Ideas, not promises — none of these has a date.

- **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

### Do I need a database or an agent?

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.

### Is it safe to expose on the internet?

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.

### What does mounting the Docker socket actually give away?

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.

### Is this affiliated with Docker, Inc.?

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.

### How much of it was written by AI?

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.

### Does it phone home?

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.

### Will it fight with my existing setup?

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.

### Where does my data live, and how do I back it up?

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.

### How do I upgrade?

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.

### Which platforms are supported?

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.

### Which Docker version do I need?

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.

### What is the license?

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.


## AI disclosure

Roughly 95% of the code, tests and documentation was produced with Claude Code, under human direction and review. This is stated up front because the software takes control of a Docker daemon.

That does not mean unreviewed output: every change 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. No independent third-party audit or penetration test has been performed.


## More

- Documentation index: https://raw.githubusercontent.com/koduj-dev/docker-commander/main/docs/README.md
- README: https://raw.githubusercontent.com/koduj-dev/docker-commander/main/README.md
- Changelog: https://raw.githubusercontent.com/koduj-dev/docker-commander/main/CHANGELOG.md
- Roadmap notes: https://raw.githubusercontent.com/koduj-dev/docker-commander/main/NEXT.md
- Releases: https://github.com/koduj-dev/docker-commander/releases
- Machine-readable map: https://docker-commander.app/llms.txt