Skip to content
All posts
strategyhomelab

Notify-only vs auto-update: choosing a safe Docker update strategy

Should you auto-update Docker containers or get notified? A practical framework for choosing per-container update modes, and when notify-only is the right call.

The loudest debate in container maintenance is framed as a binary: auto-update everything, or update nothing and patch by hand. Both extremes are wrong for most homelabs. The right answer is per container, and freshdock is built around that.

The two failure modes

Auto-update everything is how the "Watchtower broke my server overnight" stories happen. A bad upstream image ships, your tool pulls it at 4 a.m., the container won't start, and you find out when something you depend on is down.

Update nothing feels safe but isn't. Stale images accumulate known vulnerabilities, and "I'll get to it" becomes months. The friction of manual updates is exactly why tools like this exist.

The useful question isn't "auto or manual?" It's "what's the cost if this specific container updates badly, and how much do I trust its upstream?"

A simple framework

Sort each container into one of three buckets:

  • Stateless and well-behaved (reverse proxies, dashboards, exporters). Low blast radius, easy to roll back. Good candidates for automatic updates.
  • Stateful or critical (databases, auth, anything with a migration step). High cost if an update goes wrong. Keep these on notify-only and update them deliberately, when you can watch.
  • Pinned on purpose (you need a specific version). Pin the digest and let the tool report it as pinned, no checks.

How freshdock expresses this

Each opted-in container picks a freshdock.mode:

# auto-update nightly, with the safety net
labels:
  - "freshdock.enable=true"
  - "freshdock.mode=nightly"

# detect updates, but only tell me, never restart
labels:
  - "freshdock.enable=true"
  - "freshdock.mode=watch"

watch is the default, and it's a legitimate permanent choice. It's exactly what Diun does as its entire purpose: tell you an update exists and let you decide. freshdock just lets you mix watch and auto-update modes on the same daemon, container by container.

Auto-update is safer here than you'd expect

The usual argument against auto-update assumes a bad update leaves you broken. freshdock's health gate changes that calculus: an updated container has to pass its healthcheck (or a grace period) before the update is kept. If it doesn't, the previous container is restored automatically and you get a failed notification. The downside of auto-updating a stateless service shrinks a lot when "it broke" becomes "it reverted and told me."

That's why a reasonable default for many homelabs is: stateless services on nightly, stateful services on watch, and a healthcheck declared wherever it's cheap to add one, because the gate is only as good as the signal you give it.

Start conservative

You don't have to decide all of this up front. Install freshdock, label everything watch, and run freshdock check for a week. Watch what would have updated. Then promote the containers you trust to nightly one at a time.

More on the modes and the health gate is on the features page and in the scheduling docs. If you're coming from Watchtower's monitor-only, the comparison maps it straight onto watch.