Container Update Workflows: Decoupling Awareness from Action
The default is dangerous, but not for the reason you think
Most containers in most homelabs run on :latest tags. The reasons are familiar: introductory Docker content defaults to it, most Compose examples don't specify versions, and pinning feels like extra work for uncertain benefit. The result is a fleet of running containers where you often can't tell what version anything is actually running, and where your relationship to upstream changes is entirely passive.
The usual framing treats this as a discipline problem. Pin your versions, read your release notes, maintain a proper update schedule. That advice is correct and largely ignored because the maintenance overhead of version pinning across a varied container fleet is significant, and the value isn't immediately visible until something breaks.
The more useful framing treats this as a design problem. Not "how should you behave" but "what does the system need to make good update behavior possible." The answer that tooling like Diun represents is a notification layer that surfaces upstream changes before you're forced to respond to them.
Two failure modes, one root cause
Running :latest tags without a notification layer produces exactly two outcomes, and neither is good.
The first is stagnation. Containers run whatever version they were started on. Updates accumulate upstream. Security patches ship. Bugs get fixed. Nothing changes in your environment because there's no signal that anything needs to change. The gap between what you're running and what you could be running grows silently over months.
The second is blind automation. You install Watchtower in auto-update mode. Images update automatically. Mostly this is fine. Then an upstream maintainer ships a breaking configuration change, doesn't bump a major version, and Watchtower applies it to a running container at 2am. The service fails. You spend an hour tracing what happened before you notice the image timestamp changed.
Both failure modes share a root cause: the update decision is made either never or by the registry, and neither of those is you. The notification layer is the design intervention that puts the decision back where it belongs.
What a notification layer actually does
Diun, in its most basic form, polls Docker registries and fires an alert when an image digest changes. It does not update anything. It does not restart anything. It tells you something changed and lets you decide what to do next.
This is the design principle at work: decouple awareness from action. Automate the part that is purely mechanical (detecting that something changed upstream) and preserve human judgment for the part that carries risk (deciding whether and when to apply that change).
The principle is not new. It appears in change management (notification before execution), patch management (scan before remediation), and monitoring design (alert before automated remediation, or not). What changes in the container context is how invisible the change surface is without a dedicated tool. A traditional server has a package manager with a changelog and explicit upgrade commands. A container running :latest has neither. Diun is the mechanism that restores visibility to a change surface that Docker's floating-tag convention makes opaque.
When automation is still the right answer
Decoupling awareness from action is not an argument against automation. It is an argument for designing the automation boundary deliberately rather than letting it collapse by default.
Some containers are genuinely low-risk to auto-update: stateless tools, media utilities, containers with no persistent state and no external dependencies that might break on a configuration change. For these, Watchtower in auto-update mode is a reasonable choice. The risk of running a stale image outweighs the risk of an update-induced breaking change. Human review adds latency without adding meaningful safety.
Other containers carry higher update risk: anything stateful, anything with database migrations, anything with external API dependencies that version-lock, anything where a restart causes a service interruption with real consequences. For these, the notification layer matters. You want to know before the update happens, not after.
Watchtower supports this split through per-container labels. A container labeled for auto-update gets pulled automatically. One without that label does not. Diun covers the whole fleet regardless. The combination creates a tiered update policy where the automation boundary is explicit and deliberate rather than uniform across everything.
The design question is not "should I automate" but "which containers belong in which tier, and why." That categorisation is the actual decision work. Diun and Watchtower together are the mechanism that enforces whatever answer you arrive at.
Where this starts to break down
The notification-plus-decision model has a load ceiling. At five or ten containers with active upstream maintainers, the alert volume is manageable. At thirty containers, it starts to resemble a second job. If notifications arrive faster than you can meaningfully review them, the review step either gets skipped or becomes rubber-stamping, and you're back to de-facto auto-update without the explicit policy that would make that safe.
There is also a tracking limitation worth understanding. Diun detects digest changes, not semantic version changes. For :latest tags, this is correct behavior. But if your goal is to track what version you are running and what version you could upgrade to, digest comparison doesn't give you that information cleanly. You know something changed; you don't know whether it was a patch, a minor release, or a major version bump with breaking changes. That context requires going to look at the upstream changelog yourself, which is the manual review step the notification is intended to prompt.
At higher container counts, or in environments where you want version-awareness rather than change-detection, the tooling shifts. Renovate, operating against your Compose files or Kubernetes manifests in source control, can detect version bumps and propose them as pull requests with changelog links. That is a different workflow: source-of-truth in git, proposed changes as code, human review at the PR level rather than at the alert level. Diun is not wrong for this work; it is operating at a different point in the design space, and at a certain scale that point no longer fits.
The question that doesn't resolve cleanly
The honest version of the "human in the loop" design question is this: at your scale and with your risk tolerance, does human review at the update decision point add safety, or does it add latency with the illusion of safety?
For a homelab running a dozen containers, a reliable notification channel and a deliberate review habit is a meaningful improvement over both stagnation and blind automation. The human checkpoint is real and achievable.
At larger scale, or in an environment where update volume exceeds what a single operator can meaningfully absorb, the human checkpoint becomes a bottleneck or gets bypassed. The design response is not to remove humans from the loop entirely but to move where in the loop they operate: from per-update decision-making to policy-setting (defining the automation rules, the tiers, the update windows) and exception handling (reviewing only what failed or what falls outside policy). That shift in the human role is what the progression from Diun toward Renovate or more structured change management represents.
Which design is right depends on the environment. What stays constant is the underlying principle: the update notification is not the point. The update decision is the point, and the notification is what makes an informed decision possible. Everything else is implementation.
