Diun
Overview
Diun (Docker Image Update Notifier) is a lightweight, self-hosted daemon that watches container image registries. It notifies you the moment a watched image gets a new tag or a digest change. Diun runs quietly in the background, performs scheduled registry checks, and sends a notification through the channel of your choice as soon as a new version appears, so you do not find out that an image has moved on only after something breaks.
The SecureAnyCloud image installs the official Diun binary at /usr/local/bin/diun and runs it as the diun systemd service under a dedicated unprivileged system user. It is configured with Diun's file provider, a plain YAML watch list. The appliance therefore needs only outbound internet access. There is no Docker socket to mount, no database server to run, and no inbound port that a customer would reach.
Secure by default, no default login. Diun has no web UI at all, so there is no login to protect. It makes outbound registry and notification connections only.
Diun 4.x also ships its own small local control API. It uses gRPC, and only the diun healthcheck, diun image and diun notif command-line subcommands use it to talk to the running daemon. Upstream binds this API to every interface by default, but this image explicitly pins it to loopback 127.0.0.1:42286, so it is reachable only from the VM itself, never from the network.
No notifier credential of any kind is baked into the image. The shipped notifier logs new and updated image events locally, and you add your own email, Slack, webhook or other notifier with your own credential only when you choose to.
Note on the interface. Diun is a headless daemon with no web UI. You drive it through two plain YAML files (diun.yml and images.yml), and you watch it work through systemctl and journalctl. This guide uses the terminal throughout.
What you get:
- Diun (verified at 4.33.0) as the official release binary, MIT licensed
diun.serviceconfigured with the file provider and a starter watch listdiun-firstboot.servicefor the first-boot instance info note- The local control API bound to
127.0.0.1:42286only - A starter watch list (nginx, redis, alpine) so that the appliance proves itself working immediately
- Ubuntu 24.04 LTS base, patched at build time
- 24/7 SecureAnyCloud support, 24-hour response SLA
Prerequisites
Before you deploy, make sure you have:
- An active Azure subscription
- An SSH key pair
- A VNet with a subnet
Diun is extremely light. Standard_B2s (2 vCPU, 4 GB RAM) is ample for watching dozens of images. Diun needs outbound HTTPS access to reach the registries it watches (Docker Hub, GHCR, or any registry you configure), and outbound access for whichever notifier you enable. No inbound port is required at all.
Deploy from the Azure Portal
Search the Marketplace for Diun on Ubuntu 24.04, choose your VM size, and attach an NSG that allows TCP 22 (SSH) from your management network. No other inbound port is needed, because Diun only makes outbound connections.
Deploy from the Azure CLI
RG="diun-prod"; LOCATION="eastus"; VM_NAME="diun-01" IMAGE_URN="sac1647283583153:diun:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name diun-vnet --address-prefix 10.91.0.0/16 --subnet-name diun-subnet --subnet-prefix 10.91.1.0/24 az network nsg create -g "$RG" --name diun-nsg az network nsg rule create -g "$RG" --nsg-name diun-nsg --name allow-ssh --priority 100 \
--source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:diun:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
--size Standard_B2s --storage-sku StandardSSD_LRS \
--admin-username azureuser --ssh-key-values "$SSH_KEY" \
--vnet-name diun-vnet --subnet diun-subnet --nsg diun-nsg --public-ip-sku StandardConnect via SSH
ssh azureuser@<vm-ip>Verify the service is running
Diun runs as a systemd service. Its local control API, which only Diun's own CLI subcommands use, is bound to loopback and is never reachable from the network.
sudo systemctl is-active diun ss -tln | grep 127.0.0.1:42286You should see active and a single loopback listener on 127.0.0.1:42286. No other Diun listener exists on any interface.
Read your first boot info note
On first boot, Diun writes a short quick-start note with the exact file paths and commands that you need. There is no secret to read here, because Diun has no login and no notifier credential ships in the image.
sudo cat /root/diun-info.txt grep -viE '^\s*#' /etc/diun/diun.yml | grep -iE 'password|token|webhookURL|apikey' || echo "no live notifier credential in the shipped config"The note lists the config file, the watch list file, the notify log, the database path and the systemd unit name. The second command confirms that the shipped diun.yml carries no live notifier credential outside its commented example block.
Watch Diun actually work
This step shows Diun performing a real registry check against the starter watch list and sending a real notification, rather than a process sitting idle. The starter watch list ships with three well-known public images (nginx, redis, alpine), so you can see this the moment you connect.
cat /var/log/diun/notify.log journalctl -u diun --no-pager | grep -iE 'found|image\(s\) to analyze' | tail -6The notify log holds one line per notification event, each with a real image reference, a status of new or update, and a timestamp. Diun's own log shows it querying the registry and finding the watched images. This confirms that Diun reaches out to Docker Hub and reports back, end to end.
Watch your own images
Replace the starter watch list with the images that you care about. Edit /etc/diun/images.yml with your editor of choice (sudo vi /etc/diun/images.yml). Each entry is a Docker image reference. If you omit them, the registry defaults to docker.io and the tag defaults to latest.
- name: docker.io/library/postgres watch_repo: false - name: ghcr.io/your-org/your-app watch_repo: falseSave the file, then restart Diun to apply the change:
sudo systemctl restart diun
sudo systemctl is-active diunThe full field reference (including watch_repo to track every tag, include_tags / exclude_tags regular expressions, and per-image registry credentials via regopt) is documented at crazymax.dev/diun/providers/file.
Add a real notifier
Out of the box, new and updated image events are only logged locally, so you can see Diun working immediately with zero configuration. When you are ready, add your own notifier with your own credential by editing /etc/diun/diun.yml (sudo vi /etc/diun/diun.yml). Nothing is baked into the image, so you supply the credential.
For example, to also notify a Slack channel, add your own webhook URL under notif:
notif: script: cmd: "/usr/local/bin/diun-notify-log.sh" slack: webhookURL: https://hooks.slack.com/services/YOUR/OWN/WEBHOOKRestart the service to apply the change:
sudo systemctl restart diunDiun supports many notifiers besides Slack: email, Discord, Gotify, Matrix, ntfy, Pushover, RocketChat, Teams, Telegram, generic webhooks and more. Every notifier's configuration is documented at crazymax.dev/diun/notif. Each notifier needs only the credential fields that it lists, and you can enable more than one at once.
Step 9 (optional): Also watch a local Docker host
This appliance ships with the lightweight file provider, so it needs nothing beyond outbound internet access. If you also run containers on this same VM, or want Diun to watch them directly instead of listing them by hand, install Docker separately and enable Diun's Docker provider in /etc/diun/diun.yml:
providers: file: filename: /etc/diun/images.yml docker: watchByDefault: trueThis step is optional and not part of the default appliance. Enabling it gives the diun service access to the Docker socket, which the image does not wire up by default, so the decision is yours.
Persistence, first boot and updates
The configuration (diun.yml, images.yml) lives on the OS disk under /etc/diun/ and is captured into the image, so a VM launched from this image starts watching immediately.
The Diun database (/var/lib/diun/diun.db) is wiped before capture, so every VM starts with a clean history. The first check after boot treats every watched image as new, which is what produces the notifications that you see in Step 6.
The first-boot oneshot writes the per-VM info note, then disables itself so that subsequent reboots are unaffected. The OS is patched at build time and ships with unattended security upgrades enabled.
/usr/local/bin/diun --version ls -1 /etc/diun/*.ymlThe first boot unit itself (diun-firstboot.service) shows as disabled once it has run on this VM. It is a oneshot unit, ordered to run before diun.service on every fresh boot, and it turns itself off after writing the info note so that later reboots are unaffected.
Support
Every SecureAnyCloud deployment includes 24/7 support with a 24-hour response SLA. Contact sales@secureanycloud.com for help with deployment, configuration or scaling.
This is a repackaged open-source software product with additional charges for SecureAnyCloud support services. Diun is a trademark of its respective owner. Docker is a trademark of Docker, Inc. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
Deploy on Azure
Launch Diun on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.
View this image
Need Help?
Our support team is available 24/7.
sales@secureanycloud.com