Diun
Notifier that alerts when Docker images receive updates
Diun is a small utility that watches Docker images in registries and sends a notification when a new version becomes available, without applying updates itself. It lets administrators decide when to upgrade.
Key features
- Watches registry images
- Many notification channels
- No automatic updates
- Provider-based discovery
Pros & cons
Strengths
- Stays in control of upgrades
- Lightweight
Trade-offs
- Notifies but does not update
- Configuration needed per source
Diun replaces
Last reviewed Sep 13, 2026 · 747 words
Watchtower once pulled a new Postgres major into a compose stack of mine overnight and the database refused to start against the old data directory. That is the entire pitch for Diun in one sentence: it watches registries for new image tags and sends you a message, and it never, under any configuration, restarts a container. You decide when to upgrade. For a homelab where a broken service at breakfast is an annoyance and a broken service during a workday is a problem, the notification-only model is the correct default, and Diun is the smallest tool that implements it: a Go binary, 64 MB of RAM, MIT licence, no database.
The setup is one container and one YAML file
services:
diun:
image: crazymax/diun:latest
command: serve
volumes:
- ./data:/data
- ./diun.yml:/diun.yml:ro
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- TZ=Europe/London
- LOG_LEVEL=info
restart: unless-stopped
And the config:
watch:
workers: 10
schedule: "0 */6 * * *"
firstCheckNotif: false
providers:
docker:
watchByDefault: true
notif:
ntfy:
endpoint: https://ntfy.example.com
topic: docker-updates
That is a working install. Every 6 hours Diun asks each registry whether the digest behind each running image's tag has changed, keeps what it saw in a small BoltDB file under /data, and posts to your ntfy topic when something moved. firstCheckNotif: false stops it flooding you with one message per container on the first run. Set watchByDefault: false and add the label diun.enable=true to the containers you care about if you would rather opt in.
It watches tags, so how you tag decides what you learn
A container running postgres:16 gets a notification whenever Docker Hub republishes the 16 tag, which is every patch release and every rebuild of the base image. A container on postgres:latest gets a notification when 17 lands. The signal you receive is exactly as good as the tag discipline you already have, and the container updates without fires post makes the case for pinning to a major or minor tag rather than latest for precisely this reason.
Add diun.watch_repo=true on a container and Diun also reports new tags in the repository, not just changes to the tag you run. Pair it with diun.include_tags using a regex such as ^16\..* and you get "a new 16.x exists" without noise from 15.x or release candidates. Registry rate limits are the other thing to plan for: Docker Hub throttles anonymous manifest requests and every check counts, so put a Hub login in the regopts block if you run more than a few dozen containers.
Notifications go everywhere, which is the point
The channel list is long: ntfy, Gotify, Telegram, Discord, Slack, Matrix, Pushover, Rocket.Chat, Teams, SMTP mail, MQTT, AMQP, a generic webhook, and a script transport that runs any command you like. Each entry sits under notif: and you can enable several at once. The message includes the image, the tag, the platform, and the new digest, which is enough to decide whether to act now or wait for the weekend.
Beyond Docker, the file provider takes a plain list of images to watch, useful for base images in your own Dockerfiles, and there are swarm, kubernetes, nomad, and dockerfile providers for people running those.
Where Diun stops and something else starts
Diun does not pull, does not restart, and does not tell you what changed in the release. When the notification arrives, the work is still yours: read the release notes, docker compose pull && docker compose up -d, check the logs. If you want the pull-and-restart automated with a little more care than Watchtower shows by default, run Watchtower with --monitor-only and you get roughly Diun's behaviour with fewer notification channels, or keep Watchtower scoped by label to the stateless containers where an automatic restart cannot hurt and let Diun cover the databases. The two coexist fine on one host.
What I'd do
Diun on every Docker host, 6-hour schedule, ntfy transport, watchByDefault: true. Pin databases and anything with a migration step to a major tag, and add diun.watch_repo=true to those so you hear about the next major ahead of time. Do updates by hand on a Saturday morning with the release notes open. It costs 64 MB and removes the one category of homelab outage that is entirely self-inflicted.
Compare Diun
2 head-to-head comparisons.
Similar automation & workflows apps
n8n
Automation & WorkflowsWorkflow automation with a node-based editor
Replaces Zapier, Make
Firecrawl
Automation & WorkflowsTurn websites into clean data for AI applications
Replaces Apify
Crawl4AI
Automation & WorkflowsOpen-source web crawler built for LLM data pipelines
Replaces Firecrawl
Huginn
Automation & WorkflowsAgents that monitor and act on your behalf
Replaces IFTTT, Zapier
Apache Airflow
Automation & WorkflowsProgrammatically author, schedule and monitor workflows
Replaces AWS Step Functions, Azure Data Factory
ToolJet
Automation & WorkflowsLow-code platform for building and automating business tools
Replaces Retool, Microsoft Power Apps