Diun

Open-source Docker registry monitoring, honestly reviewed. No auto-updates, no surprises — just a notification when something changes.

TL;DR

• What it is: A CLI tool written in Go that watches Docker registries and sends you a notification whenever an image you’re running gets a new tag or digest update [1][2].
• Who it’s for: Self-hosters and DevOps engineers running multiple Docker containers who want to know when upstream images change before deciding whether to pull [1].
• Cost: $0. MIT license, single binary, runs anywhere Go runs — Linux, macOS, Windows, ARM, amd64, PowerPC [1][2].
• Key strength: Covers every serious notification channel (Slack, Telegram, Discord, ntfy, Gotify, Matrix, webhook, email, and 15+ more) and every serious container orchestration provider (Docker, Kubernetes, Swarm, Nomad) in one tool [2].
• Key weakness: Purely a notifier — it will not update your containers for you. If you want auto-updates, Watchtower is a different tool that does that job. Diun explicitly does not. Also: no web UI, no dashboard, headless-only [1].

---

What is Diun

Diun stands for Docker Image Update Notifier. It’s a single Go binary (or Docker image) that you point at your running containers, your Kubernetes cluster, your Docker Swarm, a Nomad deployment, or even just a plain text file listing image names — and it periodically checks the upstream Docker registry to see if any of those images have received new tags or digest changes. When they have, it fires off a notification through whichever channel you’ve configured [1][2].

The project is maintained by crazy-max (a prolific solo open-source developer) and has accumulated 4,505 GitHub stars. It’s MIT licensed, meaning no restrictions on self-hosting, forking, or embedding it in commercial tooling [1].

The core philosophy is deliberate: notify, don’t act. A significant class of self-hosted infrastructure problems comes from auto-updaters silently pulling a breaking image change at 3am. Diun sits in front of that process. You get the alert; you decide what to do with it [2].

What makes it more than a glorified cron-plus-curl script is the breadth of what it can watch and how it can tell you about it:

• Six providers — it can discover which images to watch automatically from a running Docker daemon, a Kubernetes cluster, Docker Swarm services, Nomad jobs, or from a static Dockerfile or plain file list [2].
• 20+ notification backends — the list includes Slack, Telegram, Discord, Gotify, ntfy, Matrix, RocketChat, Microsoft Teams, Pushover, Signal (via REST), AMQP, MQTT, Elasticsearch, generic webhook, shell script execution, and email [2].
• Tag filtering — you can include or exclude tags using regular expressions, so if you only want to know about semver-tagged releases and not every latest churn, you configure that per-image [2].

The Go implementation matters for self-hosters: the binary has no runtime dependencies. You can drop it on a Raspberry Pi, a cheap ARM VPS, or a VM that’s already running your containers, and it will work without a Python environment or Node.js interpreter in sight [1].

---

Why people choose it

Note: the third-party reviews scraped for this article did not include any Diun-specific content — the data pipeline returned unrelated results. The following section is based on primary sources (GitHub, documentation) and the practical problem Diun is designed to solve.

The self-hosted Docker world has a gap between two extremes: Watchtower (auto-pull and restart any updated container, no questions asked) and doing nothing (manually checking Docker Hub every few months when something breaks). Diun fills the middle position — automated discovery of what changed, human decision on whether to act.

The case for Diun over Watchtower comes down to safety. Watchtower is operationally convenient until a maintainer pushes a broken latest tag, a breaking change lands without a major version bump, or an image with a security regression gets pulled in silently at 2am. In a home lab that’s tolerable. In any setup where uptime matters — a self-hosted business app, a family NAS, a small production deployment — silent auto-updates are a liability. Diun gives you the signal without taking the action [1][2].

The case for Diun over doing nothing is equally straightforward: without monitoring, you find out about available updates in one of three ways — when something breaks, when you manually think to check, or never. For security-critical images (reverse proxies, authentication services, database containers) that’s unacceptable. Diun automates the discovery.

The notification breadth is genuinely impressive for a single-maintainer tool. Most homelab setups already have Slack, Telegram, ntfy, or Gotify running somewhere. Diun slots into whatever channel you already use rather than requiring you to adopt a new one [2].

---

Features

Provider system — rather than requiring you to manually list images, Diun can autodiscover them from your infrastructure [2]:

• Docker provider: watches the local Docker socket, picks up all running containers automatically
• Kubernetes provider: reads pod specs from the cluster API
• Swarm provider: reads Docker Swarm service definitions
• Nomad provider: reads Nomad job allocations
• Dockerfile provider: parses FROM directives in Dockerfiles
• File provider: watches a static YAML/TOML file listing image names

Notification system — 20+ backends [2]:

Gotify, Mail, Slack, Telegram, Discord, Apprise, AMQP, Elasticsearch, Matrix, MQTT, ntfy, Pushover, RocketChat, Script (run any shell command), Signal REST, Microsoft Teams, generic Webhook. You can configure multiple notifiers simultaneously — push to both Slack and ntfy at once.

Tag filtering and registry options:

• Include/exclude tags by regex — useful for distinguishing stable releases from nightly builds [2]
• Override image OS and architecture for cross-platform registries [2]
• Registry authentication configuration (private registries, Docker Hub rate limit mitigation) [2]

Operational features:

• Internal cron scheduler implemented via goroutines — no external cron dependency [2]
• Worker pool for parallel registry checks — handles large image sets without queuing serially [2]
• Healthchecks.io integration for monitoring the watcher itself (so you know if Diun stops running) [2]
• Bolt database for state persistence — tracks what was last seen so it doesn’t re-notify on restart [2]
• Structured logging with configurable verbosity [2]

Deployment options:

• Single static binary (Linux, macOS, Windows; amd64, i386, ARM, ARM64, PowerPC, others) [1][2]
• Official Docker image (crazymax/diun) [1]
• Linux service installation guides in documentation [2]

---

Pricing: SaaS vs self-hosted math

Diun has no pricing tiers, no cloud offering, and no commercial edition. It’s MIT open source, free to use and self-host [1].

What you actually pay:

• Diun itself: $0
• A server to run it on: whatever you already have, or ~$4–6/mo for a minimal VPS if you need one dedicated to it (though realistically it runs alongside your existing Docker stack on the same host)
• Storage: negligible — the Bolt database stays small, logging is configurable

For comparison: there is no direct SaaS competitor offering exactly this functionality at a price point you’d compare against. Datadog, Sysdig, and similar tools include container image scanning as part of broader platform products that start at $15–35/user/month with minimum seat requirements. If you’re running a small self-hosted stack, that math doesn’t work. Diun is the self-hosted answer to a problem those platforms solve incidentally as part of something much larger and more expensive [2].

If you want a purely cloud-based option, Docker Hub itself sends notifications for watched repositories, but only for images hosted there, and only for Hub-native events. Diun works with any OCI-compliant registry: Docker Hub, GHCR, Quay.io, private Gitea registries, self-hosted Harbor instances [2].

---

Deployment reality check

Diun is not complex to deploy, but it does require understanding what you’re pointing it at.

Simplest path (Docker socket monitoring on the same host):

1. Drop a docker-compose.yml with the crazymax/diun image
2. Mount the Docker socket (/var/run/docker.sock) read-only
3. Add environment variables or a config file for your notification backend
4. Run docker compose up -d

At this point Diun will autodiscover all containers running on that host and start watching their images on the configured cron schedule [2].

Kubernetes path:

Requires deploying a ServiceAccount with appropriate RBAC permissions to read pod specs across namespaces. The documentation covers this with example manifests. More moving parts than the Docker path but manageable [2].

Configuration:

Diun uses a TOML or YAML config file plus environment variable overrides. The configuration surface is large — you can configure defaults that apply to all images and then per-image or per-provider overrides. The documentation is thorough but the initial config file can feel dense if you want non-default behavior for specific registries or providers [2].

What can go sideways:

• Private registry authentication requires careful configuration. Docker Hub rate limits (especially for unauthenticated pulls from docker.io) will cause Diun checks to fail if you run many images and don’t configure Hub credentials [2].
• ARM and multi-arch images: if you’re running ARM containers (e.g., Raspberry Pi) but checking from an amd64 host, you need the os/arch override settings to check the right manifest. The feature exists; it just needs explicit configuration [2].
• No web UI whatsoever. Diun is headless. All status comes through your configured notification channels or by checking logs. If you want a dashboard showing update status across your stack, you need a different tool or you wire up Diun webhooks into something else.
• Healthchecks integration is opt-in. By default, if Diun’s cron job silently fails (bad config, network issue), you won’t know. Configuring Healthchecks.io monitoring is recommended so you know the watcher is actually running [2].

Realistic setup time: For a technical user running Docker on a single host, 15–30 minutes from zero to first notification. Kubernetes deployment with proper RBAC: 1–2 hours. Configuration tuning for private registries and per-image filters: variable, depending on your setup.

---

Pros and Cons

Pros

• MIT license, zero cost. No usage limits, no commercial restrictions, no paid tiers. Deploy as many instances as you want [1].
• Notify-not-act philosophy. You stay in control of when images actually update. Silent auto-updates are not the default behavior, which is correct for anything beyond a throwaway lab environment [1][2].
• Single binary, minimal footprint. No interpreter, no dependencies, cross-platform. Runs on everything from a Pi Zero to a 64-core server [1][2].
• Broad provider support. Docker, Kubernetes, Swarm, Nomad, Dockerfile, and file-based watching in one tool — you don’t need separate solutions for different parts of your infra [2].
• Deep notification coverage. 20+ backends covers essentially every notification platform a self-hoster might already use. You won’t have to run something new just to receive Diun alerts [2].
• Tag filtering. Regex-based include/exclude means you can be precise about what update signals you actually care about [2].
• Healthchecks integration. The meta-monitoring capability (watching the watcher) is often an afterthought in OSS tools; Diun has it built in [2].

Cons

• No web UI or dashboard. Diun is entirely headless. Useful status is only visible through notification channels or logs. If your team is non-technical and expects a UI showing “these 3 images are behind,” Diun doesn’t provide that [1][2].
• Solo maintainer project. crazy-max is active and prolific across many projects, but a single-maintainer tool carries inherent bus-factor risk compared to foundation-backed or well-funded OSS projects. The last commit activity and release cadence should be checked before making it a critical piece of infrastructure [1].
• Configuration complexity at scale. For large setups with many registries, different auth requirements per registry, and per-image overrides, the config file grows. There’s no UI to manage it, and mistakes in registry auth config cause silent failures [2].
• Does not auto-update. This is listed as a pro above (it is, by design) but it’s also a con if what you actually want is Watchtower-style automation. Diun is the wrong tool for that use case [1].
• No built-in remediation. Diun has a “Script” notification backend that can run a shell command, which some users use to trigger updates or CI pipelines — but this is DIY. The tool doesn’t orchestrate anything beyond the notification [2].
• Private registry setup requires attention. Docker Hub rate limits and private registry authentication must be configured explicitly, and failures here cause missed notifications without obvious error surfacing in a default setup [2].
• No aggregation or snooze logic. If you have 50 images and a batch of updates lands on a Tuesday, Diun will fire 50 notifications. No batching, no deduplication window, no “send a daily digest instead.” This is configurable only by routing notifications through a secondary aggregation system [2].

---

Who should use this / who shouldn’t

Use Diun if:

• You run multiple Docker containers (home lab, small production stack, or self-hosted business tools) and you want to know when upstream images release updates without having to manually check Docker Hub.
• You’ve been burned by Watchtower silently pulling a broken image or want to stay in control of when your stack updates.
• You’re running containers on Kubernetes, Swarm, or Nomad alongside plain Docker and want a single tool that covers all of them.
• Your notification preferences already include Slack, Telegram, ntfy, Gotify, Discord, or any of the 20+ supported backends — Diun fits into your existing alerting infrastructure.
• You want MIT-licensed tooling with no usage limits, no account required, and no vendor relationship to manage.

Skip it if:

• You want automatic image updates, not just notifications. Use Watchtower or Renovate instead.
• Your team needs a web UI or dashboard to check update status. Diun has none.
• You’re a non-technical user who isn’t comfortable with TOML/YAML configuration files and Docker socket mounts.
• You need enterprise features like RBAC for who can configure what, audit logging, or centralized multi-tenant management. Diun has none of these.
• You want this to be a critical alerting system but don’t have a plan for monitoring that Diun itself is running correctly (this is solvable with Healthchecks, but requires additional setup).

---

Alternatives worth considering

• Watchtower — the most common alternative. Watchtower automatically pulls and restarts containers when images update. Opposite philosophy from Diun. Use Watchtower if you want automation; use Diun if you want control. Both are free and OSS.
• Renovate — broader dependency tracking including Docker images, but also npm, pip, Go modules, and more. Output is pull requests to a Git repository rather than real-time notifications. Correct choice if you’re managing infrastructure as code and want PRs for image bumps.
• Dependabot — GitHub-native equivalent to Renovate. Works if your Dockerfiles and compose files are in GitHub; no option for runtime container monitoring.
• Portainer — provides a UI for managing Docker and Kubernetes, and has some awareness of image versions, but it’s a full management platform, not a lightweight notifier. Significant resource overhead compared to a single Diun binary.
• ntfy + custom scripting — if your needs are simple (one or two images, one notification channel), a cron job that runs docker pull --quiet and checks the digest against a saved value achieves a subset of what Diun does in about 20 lines of shell. Scales poorly but has zero dependencies.
• Harbor — if you’re running a private registry and want comprehensive image scanning, CVE alerting, and policy enforcement, Harbor is a different class of tool (and significantly more complex to operate).

For most self-hosters the realistic choice is Diun vs Watchtower. The question is simple: do you want to be notified (Diun) or do you want the update to happen automatically (Watchtower)?

---

Bottom line

Diun solves a specific and common problem in self-hosted infrastructure: knowing when your Docker images change without being surprised by it. It does this job well — broad provider support, deep notification coverage, solid configuration options, and a single MIT-licensed binary that runs anywhere. The notify-not-act philosophy is the right default for any self-hoster who has production workloads or learned the hard way that silent auto-updates break things. The limitations are real (no UI, solo maintainer, no aggregation logic, configuration complexity at scale) but none of them are fundamental design flaws — they’re trade-offs consistent with a focused, lightweight tool. If you’re managing a self-hosted stack and you don’t have image update monitoring, Diun is the most pragmatic way to add it.

---

Sources

1. crazy-max/diun — GitHub Repository (4,505 stars, MIT license). https://github.com/crazy-max/diun

2. Diun Official Documentation — “Docker Image Update Notifier — CLI application written in Go to receive notifications when a Docker image is updated on a registry.” https://crazymax.dev/diun/

Primary sources:

• GitHub repository: https://github.com/crazy-max/diun
• Official documentation: https://crazymax.dev/diun/
• Notification backends reference: https://crazymax.dev/diun/notif/
• Provider reference: https://crazymax.dev/diun/providers/

Note: Third-party independent reviews of Diun were not available in the data sourced for this article. The review is based on primary documentation and the tool’s documented feature set.