DI

Diun

Notifier that alerts when Docker images receive updates

Automation & Workflows ★ 4.9k stars Easy setup MIT

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