WDM Docker Manager is the tool I wanted every time I provisioned another small self-hosted stack and caught myself repeating the same checklist from memory.
Install Docker. Create a folder under ~/docker. Copy the Compose file. Pick ports. Generate secrets. Bind the app to localhost unless it truly needs a public listener. Remember which apps need a database warning. Run docker compose up -d. Check logs. Save the notes somewhere future-me can find. Repeat the whole thing next week on a different VPS.
That workflow is fine once. It gets sloppy when you do it for the tenth client, or when you are tired, or when the app has three containers and five secrets. WDM is my answer to that drift: a local terminal app that installs, updates, checks, and removes a curated set of Docker Compose stacks with the safety rules baked in.
The first public release, v1.0.0, went live on June 17, 2026. It is written in Go, ships as a single Linux amd64 binary, and has two faces: a keyboard-driven TUI for humans and a scriptable CLI for automation.
This is not another Docker dashboard. It does not try to manage every random Compose project on your box. It manages the stacks it created, under the paths it owns, using templates I would be willing to run myself.
Why I built WDM Docker Manager
The self-hosting world has a strange gap. On one side, you have beautiful web dashboards that can do almost anything if you already know what you are doing. On the other side, you have blog-post Compose files, GitHub gists, and curl | sh installers that ask for a lot of trust.
Most small teams do not need a platform. They need a boring way to get from “fresh VPS” to “Uptime Kuma is running behind my reverse proxy” without accidentally exposing a database, losing a volume, or pasting secrets into logs.
I kept solving that problem by hand. The same app templates. The same .env defaults. The same “bind to 127.0.0.1 first, publish later through a proxy” rule. The same warning before touching database-backed apps. The same habit of preserving volumes on remove, because docker compose down -v is one of those commands that looks harmless until it isn’t.
WDM turns those rules into a tool.
What WDM Docker Manager does
Run wdm in an interactive terminal and it opens the TUI. From there you can browse the catalog, install a stack, check status, view redacted logs, update an app, manage pre-change config backups, and update WDM itself.
Run it in a script or pipe and it behaves like a CLI:
wdm apps list
wdm apps install nextcloud --domain cloud.example.com --yes
wdm apps status nextcloud --json
wdm apps update nextcloud --dry-run
wdm apps logs nextcloud --tail 100 --follow
wdm self-update checkBoth interfaces call the same engine. That matters because the TUI is not a separate path with different behavior. If an install refuses root in the CLI, it refuses root in the TUI. If an update needs explicit database-risk confirmation, it needs that confirmation in both places.
The first release targets Linux amd64 on Debian 12, Debian 13, Ubuntu 24.04, and Ubuntu 26.04. It expects Docker 20.10 or newer with Compose V2. It runs as your normal user in the docker group and refuses root or sudo by design.
The default runtime layout is simple:
~/.local/bin/wdm
~/.config/wdm/config.toml
~/.local/share/wdm/catalogs/stable/
~/.local/state/wdm/
~/docker/<app>/Each managed app gets its own directory under ~/docker/<app>/. WDM writes the generated Compose file, .env, state lock, and config backups there. It does not wander around the filesystem looking for other projects to “help” with.
The v1 catalog: 19 apps I would actually run
The launch catalog is intentionally small. WDM v1 ships nineteen apps, not an endless marketplace.
| Area | Apps |
|---|---|
| Monitoring and operations | Uptime Kuma, n8n, SerpBear |
| Collaboration and business tools | Nextcloud, Baserow, DocuSeal, Zulip, Stoat |
| Security and access | Vaultwarden, Authentik, WireGuard + AdGuard Home |
| Remote management and admin | MeshCentral, Dockhand |
| Media, sync, and personal infrastructure | Jellyfin, Navidrome, Syncthing, FreshRSS, qBittorrent |
| AI interface | Open WebUI |
That list mirrors the stack I keep coming back to in client work and my own infrastructure. Uptime Kuma for monitoring. Vaultwarden for passwords. Authentik for identity. n8n for workflow glue. Nextcloud and DocuSeal for client-facing operations. MeshCentral when remote support matters. WireGuard + AdGuard Home when the first requirement is “stop exposing admin things to the public internet”.
Could WDM support hundreds of templates later? Maybe. I am more interested in keeping the catalog curated enough that each template can carry real opinions: image pins, resource defaults, capabilities, internal networks, database warnings, and install guidance.
A large catalog that nobody maintains is worse than a small catalog with taste.
The safety model is the product
The most important part of WDM is not the TUI. It is the set of things it refuses to do casually.
WDM refuses to run as root or through sudo. That will annoy someone. Good. A local Docker manager already talks to a privileged Docker daemon; it does not need to add root shell habits on top.
Generated stacks bind to localhost by default. If an app genuinely needs a public listener, such as a VPN endpoint, the template can express that. Everything else starts at 127.0.0.1 and belongs behind a reverse proxy or private network.
Release and catalog updates verify signed artifacts and fail closed. The v1 release publishes seven assets: the binary, catalog bundle, SLSA provenance attestation, SPDX SBOM, checksums, detached Ed25519 signature, and cosign bundle. If verification fails, WDM stops.
Secrets are generated and redacted before they hit logs or JSON output. That sounds small until you have automation scraping command output into CI logs, issue comments, or chat notifications.
Remove does not delete volumes. WDM’s remove operation stops the managed stack and leaves files and volumes in place. There is a separate delete command for removing stack files, and it requires the exact app id as confirmation. WDM still does not back up application data for you. That boundary is explicit.
Database-backed apps carry database-risk warnings. --yes accepts safe confirmations, but it does not silently accept the database-risk path. If an update could affect a database-backed stack, WDM makes you say so.
This is the part I care about most. A Docker helper that makes destructive work faster without making intent clearer is not helping.
Where WDM fits in a self-hosted agency stack
WDM belongs after the boring foundation work.
Start with a hardened Linux host. SSH keys, no password auth, a normal sudo user, a firewall, updates, and a clear backup plan. I cover that baseline in Linux server security fundamentals. Then install Docker from the official Docker repository, not from a random script and not from a stale distro package.
After that, WDM fits nicely beside the rest of the agency stack. It can install Uptime Kuma, n8n, Vaultwarden, Authentik, Nextcloud, MeshCentral, and the other curated apps without forcing you to keep a folder of half-remembered Compose snippets.
It also pairs well with a reverse proxy. My usual pattern is still to bind apps locally and put Nginx Proxy Manager, Caddy, Traefik, or Pangolin in front. WDM gets the app running. The proxy decides what should be reachable and under which hostname.
If you already use Portainer, WDM does not make it useless. Portainer is still good for reading container logs, inspecting networks, and managing general Docker state. WDM is better for “install this known stack using the current catalog rules”. Different job.
Who should try it first
Try WDM if you run small self-hosted stacks on Debian or Ubuntu and you are comfortable enough in a terminal to understand what Docker Compose is doing.
You are probably a fit if you:
- deploy the same apps repeatedly across client or personal VPSs
- want a TUI for day-to-day operations but still need CLI and JSON output for scripts
- prefer curated templates over a generic app store
- care about signed releases and catalog verification
- want remove operations that preserve volumes by default
You are probably not a fit if you need arbitrary Compose project management, Windows or macOS support, ARM builds, Kubernetes, multi-node orchestration, or a commercial SLA. WDM v1 is a local Linux tool with one stable release channel. That constraint is intentional.
I would rather ship a small tool with clear edges than pretend the first release is a platform.
How to install WDM Docker Manager
The verified one-line installer for Linux amd64 is:
curl -fsSL https://raw.githubusercontent.com/wnstify/wdm/main/scripts/install.sh | shI know. I do not usually like one-line installers either.
The reason I am comfortable publishing this one is that the installer is part of the public repository and the release verification path is documented in SECURITY.md. It downloads a pinned temporary cosign verifier, checks that verifier against a pinned SHA-256 checksum, verifies the signed release checksums and provenance attestation, then installs WDM to ~/.local/bin/wdm by default.
If that still feels too magical, use the manual path:
- Download
wdm-linux-amd64and the verification assets from the GitHub Releases page. - Verify the signature, checksums, and attestation using the commands in SECURITY.md.
- Put the verified binary on your
PATH.
Then run:
wdmThe TUI should open. If you are in a non-interactive shell, WDM prints CLI help instead.
Closing the loop
WDM is small on purpose. It is not trying to own your whole server. It is not trying to become a hosted control plane. It is not trying to turn Docker into a mystery behind a shiny button.
It is the path I wanted between a hardened VPS and the self-hosted apps I keep recommending: signed binary, verified catalog, curated Compose templates, clear confirmations, preserved volumes, and a terminal interface that does not punish you for wanting both TUI comfort and CLI automation.
If you try it and something feels wrong, file an issue. If you want a specific app in the catalog, open a feature request and explain the production use case. If WDM saves you an afternoon, star the repo or support Webnestify Education. That is how this stays free, public, and useful.
