Each time I mention Watchtower for container updates, I generally have comments that Watchtower is a very stale project. This is definitely true as it hasn’t had any updates in around three years or so. So, lately, one of my projects has been to find what I think is the best suitable replacement for Watchtower in my lab environment. I am documenting my journey on that front with a series of blog posts on the contenders to replace Watchtower to keep docker containers updated automatically. The first solution is What’s Up Docker (WUD) which certainly wins on the best name award. Let’s see what it is, how you set it up and what it can do.
What is going on with Watchtower?
Watchtower is an oldie and has worked so well for so long. However, as of now, it is going on three years stale without updates. In fact, with the latest update to Docker 29.x, it has reported to be broken. Note the following comments I have received on my recent YouTube video about Watchtower. These comments represent good community feedback on the Watchtower project.
“Watchtower is not maintained anymore. Replace watchtower with WUD.” – @jvmauricio107
“Watchtower is not only unmaintained, but breaks with the latest version of Docker. You should either move to a fork or use a different solution. I actually set up a self-hosted Renovate bot that looks at my docker compose definitions in my git repo, and adds PRs with updates. Super cool tool that has some pain points, but is so far working well for me.” – @Eysvar
containrrr/watchtower is an abandoned project, I used it for a long time but its latest version is not compatible with the new docker engine’s api you can downgrade the api requirement in a single config file but that would cause compatibility issues later on after this api issue I switched to nickfedor/watchtower which is a maintained fork of the original watchtower and that just works without even changing the configuration in the compose (only needed to change the container image)” – @bornivok
What is What’s Up Docker (WUD)?
WUD stands for What’s Up Docker and it is an open-source tool that watches your containers running on your Docker hosts and checks for newer image versions. WUD watches container images and alerts you as soon as new versions are available. It inspects your running containers, reads their image references, and queries the image registries they are pulled from. If a newer version of your image is available, it gives you that information in a user interface or using notifications that you configure.
WUD is designed so it can perform these checks automatically based on a schedule you define. You do not have to manually visit container pages or run docker commands to inspect tags. WUD watches everything for you.
You can also define what the triggers do. There are many triggers that it supports for updating your containers, such as:
- Notify you (email or modern notification)
- Actually update the containers (docker-compose)
- Run a script that you choose
WUD architecture and monitoring setup
There are several components to the WUD monitoring architecture and how it keeps things up to date and you notified when there are new images available. Let’s look at the components:
- Watchers – These are the component that scans your Docker environment and discovers containers you have running in the environment.
- A watcher can inspect the mount of the Docker socket locally to inspect containers directly. Using this method, WUD can see container names, tags, digests, labels, and all the metadata needed to track their versions.
- Triggers – Triggers allow you to perform an action. Those actions include webhooks, email alerts, and messaging your notification provider. You can also configure triggers that perform actions on your containers so WUD can update services for you.
For example, you can create a trigger that fires when WUD detects a new image for a specific container. That trigger might call a webhook that kicks off a redeployment. Also it may directly interact with your host environment to pull a new image and restart the service.
Triggers make WUD more than just a monitoring tool. They turn it into a lightweight automation platform for managing lifecycle updates across your containers.
When WUD sees a container, it identifies the image and tag it is using right now. It then checks the registry to see whether a newer version exists. WUD supports both simple tag checks and digest based comparisons. So this means it works with regular versioned tags and also latest based tags where digests change without the tag changing. You can also filter which tags WUD should consider valid updates using regular expressions.
You can also configure how often WUD scans for updates using CRON style expressions. If you want checks every morning or every hour you can do that. The scheduling is pretty flexible and can do anything you can basically do with CRON. This means you can tune WUD to your environment without adding unnecessary load to your registry or host.
You can use docker labels
Another really great feature of WUD is the ability you have to use Docker labels. You have probably used labels if you have worked with Traefik before. Labels are used to add metadata to a container. These allow you to control monitoring of the container with WUD, such as you can exclude containers from monitoring with labels. The labels I think help to take it to a really good level for using this solution in both home lab environments and production.
How to run WUD as a Docker container
WUD itself is run as a Docker container. Let’s take a look at the Docker Compose code we need to use to spin up a WUD environment. The configuration includes the WUD image, port mapping for the user interface, and mounting the Docker socket so it can see running containers. Running it as a container really helps with housekeeping of the solution itself and you don’t have to worry about installing other software on your Docker hosts themselves.
A typical deployment looks like this using the official instructions:
services:
wud:
image: ghcr.io/getwud/wud
ports:
- "3000:3000"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- WUD_WATCHER_LOCAL_CRON=0 0 * * *
This example checks for updates every night at midnight and exposes the WUD interface on port 3000. You can adjust the schedule and options however you want. Once the container starts you can navigate to the interface and immediately see your running containers along with their current and latest versions.
WUD reads the Docker socket, so it sees everything running on the host without needing additional configuration. This makes it incredibly easy to drop into existing stacks.
Logging into WUD for the first time
After you spin up the container, you just open a web browser and browse out to port 3000 or whichever port you have exposed on the outside of your container. You will see something that looks like this for your dashboard.
Below, you can see that WUD has picked up that I have 7 containers running on my Docker host. We haven’t defined any triggers as of yet, we have the 1 watcher, 5 registries, etc.
If we click into our containers, we can expand and see the details of updates. I really like the level of detail that you get here, with the tag, and also the Update kind which WUD lets you know if it is a minor or major update.
Defining triggers
So in our original Docker Compose code, we didn’t have any triggers defined. How do we do that? Well, these are essentially just environment variables that we configure for our WUD container. Below are examples of the most used triggers that you will likely want to define.
After these environment variables, when I log into the interface, I see the Docker Update now available under the Triggers button for my containers. You can also manually run your triggers as you can see here. I can push the Run button, and it will run the update for the container we are viewing.
Below are a few of the trigger configurations you can use with WUD.
1. SMTP (Email)
The traditional email trigger for WUD.
environment:
- WUD_TRIGGER_SMTP_GMAIL_HOST=smtp.gmail.com
- WUD_TRIGGER_SMTP_GMAIL_PORT=587
- [email protected]
- WUD_TRIGGER_SMTP_GMAIL_PASS=your-app-password
- [email protected]
- [email protected]
- WUD_TRIGGER_SMTP_GMAIL_TLS_ENABLED=true
- WUD_TRIGGER_SMTP_GMAIL_SIMPLETITLE=Container $${name} Update Available
- WUD_TRIGGER_SMTP_GMAIL_SIMPLEBODY=Container $${name} can be updated from $${local} to $${remote}Note: Use $$ to escape dollar signs in template variables.
2. Discord Webhook
You can send to Discord webhook URL.
environment:
- WUD_TRIGGER_DISCORD_MYDISCORD_WEBHOOKURL=https://discord.com/api/webhooks/YOUR_WEBHOOK_URL
- WUD_TRIGGER_DISCORD_MYDISCORD_MODE=simple # or batch3. Telegram
Here you simply use your bot token and chat ID.
environment:
- WUD_TRIGGER_TELEGRAM_MYTELEGRAM_BOTTOKEN=your-bot-token
- WUD_TRIGGER_TELEGRAM_MYTELEGRAM_CHATID=your-chat-id4. MQTT (for Home Assistant integration)
Great for Home Assistant.
environment:
- WUD_TRIGGER_MQTT_MOSQUITTO_URL=mqtt://mqtt-server:1883
- WUD_TRIGGER_MQTT_MOSQUITTO_USER=username # optional
- WUD_TRIGGER_MQTT_MOSQUITTO_PASSWORD=password # optional
- WUD_TRIGGER_MQTT_MOSQUITTO_HASS_ENABLED=true
- WUD_TRIGGER_MQTT_MOSQUITTO_HASS_PREFIX=homeassistant5. HTTP Webhook (Generic)
A general webhook example for those running other solutions with API endpoints enabled.
environment:
- WUD_TRIGGER_WEBHOOK_MYWEBHOOK_URL=https://your-webhook-url.com
- WUD_TRIGGER_WEBHOOK_MYWEBHOOK_METHOD=POST6. Gotify
Gotify example:
environment:
- WUD_TRIGGER_GOTIFY_MYGOTIFY_URL=https://gotify.example.com
- WUD_TRIGGER_GOTIFY_MYGOTIFY_TOKEN=your-gotify-token7. Slack
You can send to Slack.
environment:
- WUD_TRIGGER_SLACK_MYSLACK_WEBHOOKURL=https://hooks.slack.com/services/YOUR/WEBHOOK/URL8. Pushover
I personally use Pushover, you just need your app token and user key.
environment:
- WUD_TRIGGER_PUSHOVER_MYPUSHOVER_TOKEN=your-app-token
- WUD_TRIGGER_PUSHOVER_MYPUSHOVER_USER=your-user-key9. Docker Update Trigger (Automatic Updates – be careful with this one)
This one will pull any updates, so you need to filter down with tags. I haven’t played around enough with this as of yet to recommend settings that I am comfortable passing along.
environment:
- WUD_TRIGGER_DOCKER_UPDATE_MODE=simple # or compose
- WUD_TRIGGER_DOCKER_UPDATE_PRUNE=true # Remove old images after update
- WUD_TRIGGER_DOCKER_UPDATE_THRESHOLD=minor # major, minor, or patchThe Docker trigger will automatically update containers when set using this trigger. If you don’t want auto-updates, use notification triggers only (SMTP, Discord, etc.).
10. Docker Compose Trigger
This I think is the most interesting as it actually makes use of your Docker Compose stack file which is safest.
environment:
- WUD_TRIGGER_DOCKERCOMPOSE_WUD_FILE=/path/to/docker-compose.yml
- WUD_TRIGGER_DOCKERCOMPOSE_WUD_PRUNE=true
volumes:
- /path/to/docker-compose.yml:/path/to/docker-compose.yml11. Command Trigger (Run Custom Scripts)
This is also very cool in that you can trigger or run your own custom scripts to do really anything.
environment:
- WUD_TRIGGER_COMMAND_UPDATE_CMD=/script/script.sh
- WUD_TRIGGER_COMMAND_UPDATE_SHELL=/bin/bash
- WUD_TRIGGER_COMMAND_UPDATE_TIMEOUT=300000
volumes:
- /path/to/script.sh:/script/script.shComparing WUD with Watchtower
So, there is a new fork of Watchtower that is a drop in replacement. And, you only have to change the image name. Everything else stays the same, which is great. The forked image is: nickfedor/watchtower. This may be the easiest for many to just swap out an image reference and be done. However, if you are looking to try out something new, WUD is definitely a great alternative.
| Feature | WUD (What’s Up Docker) | Watchtower |
|---|---|---|
| Pros | – Shows running containers with version comparison – Clean web interface that shows current vs latest images – Fine grained control using labels and tag filters – Can notify or automate updates through triggers – Supports update policies per container – It is actively maintained with frequent releases | – Lightweight and simple to deploy – Extremely easy to set up automatic updates – Minimal configuration required – Very low resource usage – Good for small or simple stacks – Has a new fork that is recently updated |
| Cons | – Much more complicated to use than Watchtower – Must secure the UI to avoid exposing update data – You need labeling for advanced control – Heavier footprint due to UI and features | – The official project has grown stale – Broken with the latest Docker 29.x release? – Does not show what updates are available – No dashboard or visibility into version differences – Updates containers without context or preview – Less flexible control over which tags to track |
Wrapping up
One of the tasks you will need to take on as part of your admin work in a home lab lab when you start running containers is keeping them updated. I have used Watchtower for years now and it has served me well, but with the project going stale, I have been making an effort to try out different solutions as alternatives. What’s Up Docker (WUD) is a great project that has a lot of features and capabilities to keep your docker images updated. While there is a really good fork of Watchtower that I have linked above, finding alternative projects helps to have options which you can pivot to if needed. WUD feels like an enterprise solution with a slick interface and a lot of features. Have you tried it out yet? Let me know in the comments.
About The Author
