Developer Tools Azure

Diun on Ubuntu 24.04 on Azure User Guide

| Product: Diun on Ubuntu 24.04 LTS on Azure

Overview

Diun (Docker Image Update Notifier) is a lightweight, self hosted daemon that watches container image registries and notifies you the moment a watched image gets a new tag or a digest change. Instead of finding out an image you rely on has moved on only after something breaks, Diun runs quietly in the background, performs scheduled registry checks, and fires a notification through the channel of your choice the instant a new version appears.

The cloudimg image installs the official Diun binary at /usr/local/bin/diun, running as the diun systemd service under a dedicated unprivileged system user. It is configured with Diun's file provider, a plain YAML watch list, so the appliance needs only outbound internet access: there is no Docker socket to mount, no database server to run, and no inbound port for anything 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 (gRPC, used only by the diun healthcheck / diun image / diun notif command line subcommands to talk to the running daemon) which upstream binds to every interface by default; 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 simply 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. It has 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 is included:

  • Diun (verified at 4.33.0) as the official release binary, MIT licensed
  • diun.service configured with the file provider and a starter watch list
  • diun-firstboot.service for the first boot instance info note
  • The local control API bound to 127.0.0.1:42286 only
  • A starter watch list (nginx, redis, alpine) so the appliance proves itself working immediately
  • Ubuntu 24.04 LTS base, fully patched
  • 24/7 cloudimg support, 24 hour response SLA

Prerequisites

An active Azure subscription, an SSH key pair, and 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.

Step 1: 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: Diun only makes outbound connections.

Step 2: Deploy from the Azure CLI

RG="diun-prod"; LOCATION="eastus"; VM_NAME="diun-01"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/diun/versions/<version>"
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
az vm create -g "$RG" --name "$VM_NAME" --image "$GALLERY_IMAGE_ID" \
  --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 Standard

Step 3: Connect via SSH

ssh azureuser@<vm-ip>

Step 4: Verify the service is running

Diun runs as a systemd service. Its local control API (used only by Diun's own CLI subcommands) is bound to loopback, never reachable from the network.

sudo systemctl is-active diun
ss -tln | grep 127.0.0.1:42286

You should see active and a single loopback listener on 127.0.0.1:42286. No other Diun listener exists on any interface.

Terminal showing diun.service active and its local control API bound to loopback 127.0.0.1:42286 only, confirmed against every interface

Step 5: Read your first boot info note

On first boot Diun writes a short quick start note with the exact file paths and commands you need. There is no secret to read here: 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 the shipped diun.yml carries no live notifier credential outside its commented example block.

Terminal showing the root only first boot info note and confirming no live notifier credential exists in the shipped configuration

Step 6: Watch Diun actually work

This is the proof that matters: Diun performing a real registry check against the starter watch list and firing a real notification, not just 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 -6

The 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 is Diun genuinely reaching out to Docker Hub and reporting back, end to end.

Terminal showing Diun's real registry check against the watch list and the resulting notification events logged locally

Step 7: Watch your own images

Replace the starter watch list with the images you actually care about. Edit /etc/diun/images.yml with your own editor of choice (sudo vi /etc/diun/images.yml). Each entry is a Docker image reference; the registry defaults to docker.io and the tag defaults to latest if you omit them.

- name: docker.io/library/postgres
  watch_repo: false

- name: ghcr.io/your-org/your-app
  watch_repo: false

Save the file, then restart Diun to pick it up:

sudo systemctl restart diun
sudo systemctl is-active diun

The 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.

Step 8: 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 ever baked into the image; 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/WEBHOOK

Restart the service to apply the change:

sudo systemctl restart diun

Diun 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 one only needs the credential fields 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: true

This is entirely optional and not part of the default appliance: enabling it means giving the diun service access to the Docker socket, which the guide leaves to you deliberately rather than shipping it wired up by default.

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 exactly what powers the proof of life in Step 6. The first boot oneshot writes the per VM info note, then disables itself so subsequent reboots are unaffected. The OS ships fully patched with unattended security upgrades enabled.

/usr/local/bin/diun --version
ls -1 /etc/diun/*.yml

The first boot unit itself (diun-firstboot.service) shows as disabled once it has already run on this VM — it is a one shot, ordered to run before diun.service on every fresh boot, and it turns itself off after writing the info note so later reboots are unaffected.

Terminal showing the installed Diun version, the watch list and config on the OS disk, the first boot service state, and a clean OS security baseline with no held packages

Support

Every cloudimg deployment includes 24/7 support with a 24 hour response SLA. Contact support@cloudimg.co.uk for help with deployment, configuration or scaling.

This is a repackaged open source software product with additional charges for cloudimg 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.