WUD

Self-hosted Docker update monitoring, honestly reviewed. Because finding out your containers are six versions behind via a security advisory is a bad day.

TL;DR

• What it is: Open-source (MIT) Docker container monitoring tool that watches your running containers, detects when newer image versions are available, and either notifies you or updates them automatically [5].
• Who it’s for: Homelab operators and small-team DevOps who run a dozen or more Docker containers and want to stay current without checking Docker Hub by hand. Also anyone who depended on Watchtower and noticed it went silent in November 2023 [5].
• Cost: Free. MIT license. You run it on the same infrastructure you’re already running your containers on. Add one container, done [4][5].
• Key strength: Per-container granularity. You decide which containers update automatically and which ones only notify you. That distinction matters in production [5].
• Key weakness: Sparse documentation for edge cases, and the project sits at 3,376 GitHub stars — real adoption, but a small maintenance team. The official website is a JavaScript-rendered docs site that doesn’t load without a browser, which is a minor but real friction point.

---

What is WUD

WUD — short for What’s Up Docker? — is a self-hostable monitoring daemon that answers one question: are your containers running the image versions they should be? It works by polling Docker registries on a schedule, comparing the tags on your running containers against what’s currently published, and doing something about the difference [5].

That “something” is configurable. WUD runs in two modes. In notification mode, it tells you an update is available through Slack, Discord, email, Gotify, Ntfy, Pushover, webhook, or a half-dozen other channels — and leaves the update to you [4][5]. In automated mode, it stops the container, pulls the new image, and restarts it, optionally updating your docker-compose.yml in the process [5]. You can mix modes per container using Docker labels.

The project lives at https://github.com/getwud/wud under the MIT license with 3,376 stars. It’s not a megaproject. It doesn’t need to be — it solves a focused problem.

---

Why People Choose It

The most direct explanation comes from the Linuxiac guide [5]: the author relied on Watchtower for years, then noticed it hadn’t shipped an update since November 2023. That’s a common migration path. Watchtower is still cited everywhere as the go-to container update tool, but its maintenance status is unclear, and WUD is where a lot of the Docker homelab community has landed instead.

The appeal breaks into three things:

It does the boring work automatically without destroying your production stack. The per-container label system is the key insight. You don’t have to choose between “update everything automatically” and “update nothing automatically.” You label your Nginx container for auto-update, label your database container for notify-only, and WUD handles both correctly in one run [5]. That’s not a feature you appreciate until you’ve had Watchtower restart your Postgres at 2am on a Friday.

It integrates with how people already handle alerts. Version 7.1 added Gotify and Ntfy support [4] — two of the most popular self-hosted notification services in the homelab space. If you’re already routing alerts through Ntfy or Gotify, WUD drops into that setup without a new account or a new service. The alternative is a cron job and a shell script, which works until it doesn’t.

It’s self-contained. WUD runs as a Docker container itself. There’s no database to provision, no separate agent to deploy, no cloud account to create. The monitoring tool for your containers is itself a container [5]. The irony is intentional and functional.

---

Features

Based on the official documentation and the Linuxiac setup guide [5]:

Registry monitoring:

• Polls Docker Hub and private registries for new image tags
• Compares against currently running container versions
• Handles tag patterns — you can tell it to track latest, a major version family, or a specific semver range [5]
• Include and exclude rules so you can omit containers you manage separately

Update behavior:

• Notification-only mode: alerts fire when update is detected, container is untouched
• Auto-update mode: stop → pull → restart, with compose file patching
• Per-container control via Docker labels — granular enough to mix modes in a single stack [5]

Notifications (as of v7.1):

• Email, Slack, Discord, Pushover (with HTML templating) [4]
• Gotify and Ntfy (added in v7.1) [4]
• Generic webhook for custom integrations
• Multiple triggers per event

Web UI:

• Container list with update status
• Manual trigger launch from the dashboard [5]
• Sorting (a sort bug was fixed in v7.1) [4]

Docker Compose support:

• Can automatically rewrite docker-compose.yml image references when it updates a container [5]
• Include and exclude triggers for compose-managed containers

What it doesn’t do:

• Kubernetes workload management (it’s Docker-focused)
• Image vulnerability scanning
• Rollback if a new image breaks something
• Any kind of drift detection beyond image version

---

Pricing: SaaS vs Self-Hosted Math

WUD has no SaaS tier. There is no hosted version to subscribe to. It’s MIT licensed, runs on your existing infrastructure, and costs nothing beyond the compute you’re already paying for [5].

The math is almost trivially simple. If you’re running WUD on the same VPS or homelab server that hosts your containers, the marginal cost is near zero — WUD is lightweight and idle most of the time between polling cycles.

Comparison to doing it without WUD:

• Manual monitoring: Free, but requires someone to check Docker Hub periodically, remember which containers need attention, and actually perform the update. Realistic cost: 1–3 hours per month for a medium-sized stack, indefinitely.
• Commercial container management platforms (Portainer Business, Rancher): Start at $5–7/node/month for managed update features. For a homelab with 5–10 nodes, that’s $25–70/month for a problem WUD solves for free.
• Watchtower (the alternative): Also free, also open source, but has not shipped updates since November 2023 [5]. Using an unmaintained tool to keep your infrastructure current is the kind of irony that shows up in post-mortems.

The honest caveat: WUD doesn’t give you an SLA. If the project stalls or a major Docker API change breaks something, you’re dependent on a small community to fix it. That’s a real risk for anyone running it in a regulated or production-critical environment.

---

Deployment Reality Check

WUD deploys as a Docker container via Docker Compose. The Linuxiac guide [5] walks through the full setup, and it’s about as simple as self-hosted tools get:

What you need:

• An existing Docker environment (the tool monitors Docker, so you already have this)
• Docker Compose
• Credentials for any private registries you want to monitor
• Outbound HTTPS to Docker Hub or your registry

What the setup looks like: A docker-compose.yml with the WUD container, a couple of environment variables for configuration, and Docker socket access (/var/run/docker.sock) so WUD can inspect the running containers. This is the standard pattern for Docker management tools and the expected tradeoff: you’re giving a container host-level Docker access, which is a meaningful permission to grant intentionally [5].

What can go sideways:

• The official documentation site (getwud.github.io/wud) requires JavaScript to render. The scrape of it returned “Please wait…” — meaning if you try to read docs with a reader-mode browser or any non-JS scraper, you get nothing. Not a blocker, but worth knowing.
• Auto-update mode is genuinely automatic. If a new image introduces a breaking change, WUD doesn’t know. It will restart your container on the new image. For stateful services (databases, auth providers), staying in notify-only mode is the saner default until you understand what a new version contains.
• Tag handling requires configuration for non-obvious patterns [5]. If your container uses a custom tag format, you’ll need to read the docs on regex tag matching. It works, but it’s not automatic.
• The project’s small team means issue response time varies. At 3,376 stars it has an active community, but it’s not in the same league as Portainer or Traefik in terms of dedicated maintainers.

Realistic setup time: 15–30 minutes for someone comfortable with Docker Compose. If you’ve already deployed similar tools (Portainer, Traefik, Uptime Kuma), this is the same skill level. If Docker Compose is new to you, budget an afternoon and follow a guide like [5] step by step.

---

Pros and Cons

Pros

• MIT licensed. No commercial restrictions, no “fair-code” asterisks, no usage limits imposed by the license [merged profile].
• Per-container mode control. The ability to auto-update some containers while only notifying on others is the feature that makes WUD actually safe to run in production. Watchtower applies one policy to everything [5].
• Lightweight. Runs as a single Docker container with no external dependencies. Doesn’t need a database or a separate agent process [5].
• Notification flexibility. Slack, Discord, email, Gotify, Ntfy, Pushover, webhook — if you already have an alerting setup, WUD probably speaks it [4][5].
• Docker Compose-aware. Auto-patching compose files is a real convenience for compose-managed stacks [5].
• Active enough. v7.1 shipped new features (Gotify, Ntfy, HTML templating for Pushover) in 2024, which means the project isn’t in the same maintenance limbo as Watchtower [4].

Cons

• Small project. 3,376 GitHub stars is solid for a focused tool, but the team is small. Long-term maintenance isn’t guaranteed. If Docker makes a breaking API change, you’re dependent on community response time.
• No rollback. WUD updates containers. If the new image breaks something, WUD does not know and does not help. You need a separate recovery plan for stateful services [5].
• No vulnerability scanning. WUD tells you a new version is available — it doesn’t tell you whether the old version has a CVE or whether the new one fixes it. Those are different questions requiring different tools (Trivy, Grype).
• JS-required documentation. The official docs site doesn’t render without JavaScript [website scrape]. A minor friction point but a signal about documentation investment.
• Docker-only. If you’re running Kubernetes, Podman, or any non-Docker container runtime, WUD is not your tool.
• Auto-update mode requires trust in upstreams. Automatically pulling and restarting on a new image version assumes the upstream maintainer isn’t shipping breaking changes on minor tags. That assumption is correct most of the time until it isn’t.

---

Who Should Use This / Who Shouldn’t

Use WUD if:

• You’re running a homelab or small-team Docker environment with a dozen or more containers and currently have no systematic way to track available updates.
• You were using Watchtower and noticed it stopped shipping updates — WUD is the current community successor in the same space [5].
• You want notification-only mode for production containers and auto-update for low-stakes services, from a single tool.
• You’re already routing alerts through Gotify or Ntfy and want container update notifications to land in the same stream [4].

Skip it (stay manual) if:

• You run fewer than five containers. The overhead of setting up WUD probably exceeds the time you’d spend checking versions by hand.

Skip it (look at Diun or Renovate) if:

• You want update notifications without giving a container Docker socket access — Diun is an alternative that some operators prefer specifically because it’s read-only focused.
• You manage your infrastructure as code and want update PRs filed against your repo automatically — Renovate (or Dependabot) is a better fit for that workflow.

Skip it (use a real platform) if:

• You’re running a production Kubernetes cluster. WUD doesn’t speak Kubernetes. Look at Keel or Argo CD for that workload.
• You need image vulnerability scanning as part of the update decision. WUD doesn’t provide that; pair it with Trivy or use a platform like Portainer Business that bundles scanning.

---

Alternatives Worth Considering

• Watchtower — The predecessor and the most-cited alternative. Still functional, Docker socket-based, simpler configuration. Has not shipped updates since November 2023 [5]. If you need long-term maintenance confidence, this is the risk.
• Diun (Docker Image Update Notifier) — Similar scope to WUD, focused on notification-only (no auto-update), and often cited by operators who prefer not to grant full Docker socket write access. Smaller community than WUD.
• Portainer — Full Docker management platform with an update-checking feature included. Free community edition available. If you want a GUI for everything Docker (not just update monitoring), Portainer is a better fit than adding WUD to a bare CLI setup.
• Renovate / Dependabot — For teams managing Docker image versions in code (Dockerfiles, compose files in a repo), these tools file PRs when updates are available. Different model — infrastructure-as-code first, not runtime monitoring.
• Keel — Kubernetes-native, focused on automatic image updates for Helm releases and Kubernetes deployments. Not comparable to WUD for Docker environments but the right tool if you’re on Kubernetes.

For a homelab operator escaping the Watchtower maintenance limbo, the realistic shortlist is WUD vs Diun. Pick WUD if you want the auto-update option available. Pick Diun if you want notification-only with a stricter security posture around Docker socket access.

---

Bottom Line

WUD occupies a small, useful niche: it does one thing (monitor Docker containers for image updates) and does it without ceremony. The two-mode design — notify-only for things you don’t trust to update themselves, auto-update for everything else — is genuinely thoughtful and the reason it’s become the practical successor to Watchtower for homelab operators. The limitations are real but proportional: it’s a small project with no rollback, no vulnerability intelligence, and no Kubernetes support. If those gaps matter to your use case, they matter a lot. If they don’t — if you’re running a compose-managed server with 20 containers and you’re tired of discovering you’re six versions behind — WUD is a 30-minute install that pays off immediately. MIT license, no accounts, no bill.

If you want someone to deploy it for you and configure it correctly across your stack — that’s the kind of setup work upready.dev handles as a one-time service.

---

Sources

1. Bobby Borisov, Linuxiac — “WUD 7.1 Brings Fresh Notification Features to Docker Monitoring”. https://linuxiac.com/wud-7-1-docker-images-monitoring-tool-released/
2. Bobby Borisov, Linuxiac — “How to Keep Containers Up-to-Date with What’s Up Docker (WUD)”. https://linuxiac.com/how-to-keep-containers-up-to-date-with-whats-up-docker-wud/

Primary sources:

• GitHub repository: https://github.com/getwud/wud (3,376 stars, MIT license)
• Official documentation: https://getwud.github.io/wud