What's Up Docker

Diun tells you when a container image has been updated. What's Up Docker does the same job, adds a web UI, understands semantic versioning, and — if you let it — applies the update itself.

Whether that last part is a feature or a hazard is the interesting question, and this page takes a position on it.

What's Up Docker keeps your containers up to date.

1. Watches running containers and checks their registries for newer tags
2. Semantic version aware — distinguishes a patch from a major, so you can act differently on each
3. Web UI listing every container and what update is available
4. Triggers — notify via ntfy, Discord, Slack, email, or act via webhook, Kafka, MQTT
5. Auto-update trigger that recreates the container on a new image
6. Registry support for Docker Hub, GHCR, ECR, GCR, ACR, Quay and private registries

WUD or Diun?

You already run Diun, so the honest comparison:

Diun is a notifier and nothing else, which is a defensible design. WUD does more, and the UI genuinely helps when you have thirty containers and want to see the whole update picture at once.

Running both is redundant. Pick based on whether you want a dashboard.

1. The Compose file

sudo mkdir -p /opt/docker/wud && cd /opt/docker/wud
sudo nano docker-compose.yml

Upstream's quickstart:

services:
  whatsupdocker:
    image: getwud/wud
    container_name: wud
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 3000:3000

A more considered version — read-only socket, restart policy, and a port that does not fight Grafana, Dockhand and Homepage:

services:
  wud:
    image: getwud/wud
    container_name: wud
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - wud_store:/store
    ports:
      - 3003:3000
    environment:
      - TZ=Europe/London
      - WUD_WATCHER_LOCAL_CRON=0 6 * * *

volumes:
  wud_store:

Mount the socket read-only unless you intend to use auto-update. WUD only needs to read container metadata to report updates; write access is what enables it to recreate containers. Start read-only, and make granting write access a deliberate decision rather than a default.

docker compose up -d

Browse to http://<host-ip>:3003.

2. What the UI shows

Every running container, its current tag, and whether a newer image exists — with the semver relationship marked, so a 1.2.3 → 1.2.4 patch is visually distinct from 1.2.3 → 2.0.0.

That distinction is the reason to prefer WUD over a plain notifier: a patch on Uptime Kuma and a major version on your database are not the same event, and a notification that treats them identically trains you to ignore both.

3. Add a notification trigger

Triggers are configured as environment variables, in the pattern WUD_TRIGGER_<TYPE>_<NAME>_<SETTING>:

    environment:
      - TZ=Europe/London
      - WUD_TRIGGER_NTFY_HOMELAB_URL=https://ntfy.example.com
      - WUD_TRIGGER_NTFY_HOMELAB_TOPIC=homelab
      - WUD_TRIGGER_NTFY_HOMELAB_PRIORITY=3

HOMELAB is a name you choose; use it consistently across the three lines. Discord, Slack, SMTP, MQTT and generic webhooks follow the same shape — the trigger docs list the settings for each.

4. Control what gets watched

By default WUD watches everything. Per-container labels refine that:

    labels:
      - "wud.watch=true"
      - "wud.tag.include=^\\d+\\.\\d+\\.\\d+$$"
      - "wud.link.template=https://github.com/org/repo/releases/tag/$${major}.$${minor}.$${patch}"

wud.tag.include is the useful one. A container pinned to :15 should not report :latest as an update, and a regex restricting it to semver tags stops the noise. Note the doubled $$ for Compose.

To exclude a container entirely, wud.watch=false.

5. Auto-update — think before enabling

WUD can recreate a container when a new image appears:

      - WUD_TRIGGER_DOCKER_UPDATE_PRUNE=true

with wud.watch.digest=true and the auto-update trigger on containers you opt in.

6. Put it behind Traefik

    networks:
      - traefik-net
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.wud.rule=Host(`wud.home.lan`)"
      - "traefik.http.routers.wud.entrypoints=https"
      - "traefik.http.routers.wud.tls.certresolver=letsencrypt"
      - "traefik.http.services.wud.loadbalancer.server.port=3000"
      - "traefik.docker.network=traefik-net"

networks:
  traefik-net:
    external: true

WUD has optional basic auth, but it exposes an inventory of everything you run and their versions — which is a useful reconnaissance document. Keep it on the LAN or behind Tinyauth.

Updating

cd /opt/docker/wud
docker compose pull
docker compose up -d

There is a pleasing circularity in WUD telling you that WUD needs updating.

Backup

Almost nothing to keep — the store holds cached state that rebuilds on the next scan. The configuration is your Compose file, so keep that in Git.

sudo cp /opt/docker/wud/docker-compose.yml /mnt/user/backups/

Troubleshooting

No containers listed. Socket not mounted, or permissions. docker exec wud ls -l /var/run/docker.sock.

Everything reports an update available, constantly. Containers on :latest. WUD compares digests, and :latest changes often. Pin real version tags — this is a signal your tagging is too loose, not a WUD bug.

Registry rate limit errors. Anonymous Docker Hub pulls are limited. Add credentials via WUD_REGISTRY_HUB_LOGIN and WUD_REGISTRY_HUB_TOKEN, or lower the scan frequency.

Private registry images not checked. Configure that registry explicitly; WUD cannot guess credentials.

Notifications fire repeatedly for the same update. Expected until the container is actually updated. Adjust the cron, or update the thing.

Trigger does not fire at all. The name segment must match across all its variables. WUD_TRIGGER_NTFY_HOMELAB_URL and WUD_TRIGGER_NTFY_HOME_TOPIC define two different half-configured triggers.

Where this sits in my lab

WUD runs on the Docker VM on my first Proxmox node with the socket mounted read-only and auto-update off everywhere. It notifies to ntfy at low priority — update notifications are not an emergency, and mixing them with Uptime Kuma's "something is down" alerts would devalue both.

The semver awareness is the reason it earns its place over a plain notifier. Patch updates I apply in a batch when convenient; major versions get the release notes read first, which is exactly the distinction I want a tool to make for me.