I do not completely understand how the proposed new versions work

[wsw70]

First of all: thank you again for the great tool. It has the power to become the next Watchtower, seriously.

---

I will go through a few examples of containers to show what I mean when I say that I do not understand the versions upgrades (it is not specific to these containers, just wanted to take a real-life example). I am on the default "Auto" setting for updates. I do not use (yet) any labels.

Home Assistant

The image I use is 2026.2. I expect to follow everything under this version, such as 2026.2.1, ...
I noticed that docker-sentinel proposed me to update 2026.2 → 2026.2.1. I pressed Approve. The update went fine.
Then, a few days later I got a warning from my monitoring system that HA was down for a minute or so, thsi was strange becaise everything else was working and then I thought "maybe it upgraded on its own...?". And yes it did.

This is not a bad thing on its own but I did not expect the upgrade to now happen every time without me deciding (either through Approve each time, or via some labels (but I did not dig into that yet)

❓My question
Does pressing Approve switches the approval to "he wanted to do it once, so let's go forever"? Actually some kind of "Auto" mode (as is the default), but "approved" once for each container?
Is it going to stop at 2026.2.x (per the image tag) or will it now skip to 2026.3 and all new ones?

The other thing is that it does not seem to be consistent. I started with 2026.2, upgraded it via "Approve" to 2026.2.1, the unexpected upgrade moved it to 2026.2.2 but I now see that there is a new upgrade (2026.2.3) that was not applied

Traefik

I use the image traefik:3. I see a possible update called 3.

❓My question
I presume this is a minor version under 3, but why is it different from the one above? In other words, why not 3 → 3.4.7
If I press Approve, and there is a new version in the future, will I see 3 again?

Immich vs Stirling

Consider these two images:

• image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
• frooodle/s-pdf:latest

This is how they are seen in the update section

Both are "tag-named" releases (latest and release) but seen differently

❓My question
Is it so that latest will be seen as "version → version" and any other image tag will just be ""?

Automatic updates

I had a look at the history and, surprise, some containers were updated without asking for anything

❓My question
Why the difference in behaviour between containers?

The only difference I can think of is that the images are without tags (esphome/esphome for example)

[wsw70]

Now that I re-read my question, questions 2 and 3 may actually be the same

[Will-Luck]

These are all valid points — thanks for the detailed writeup.

What was happening

The root issue is that SENTINEL_LATEST_AUTO_UPDATE defaulted to true. This forced any container using :latest (or no tag at all, which Docker treats as :latest) to auto-update on digest change, regardless of the global manual default policy. That explains why some containers (like esphome) updated without approval — they had no explicit tag, so they fell into the :latest auto-update path.

For Home Assistant (2026.2): after you approved 2026.2.1, the next scan found 2026.2.2 as the newest semver tag. If the policy resolved to auto (e.g. via Docker label or a prior override), it applied without approval. The inconsistency with 2026.2.3 pending could be a timing issue or a policy change between scans.

What's changing (#37)

1. Safer defaults — SENTINEL_LATEST_AUTO_UPDATE now defaults to false. Nothing auto-updates unless you explicitly opt in via:

• Per-container policy on the dashboard
• Docker label sentinel.policy=auto
• Environment variable SENTINEL_LATEST_AUTO_UPDATE=true

2. Version resolution for all non-semver tags — Previously only :latest got digest-to-version resolution (showing 1.25.0 → 1.26.0). Tags like :release, :3, :stable just showed the tag name with no version context. Now all non-semver tags get the same resolution, so traefik:3 will show something like 3.3.0 → 3.4.7 instead of 3 → 3.

Your specific questions

Home Assistant: Approve is a one-time action — it doesn't change the policy. It stays within your tag's semver range (e.g. 2026.2.x updates but won't jump to 2026.3 unless it's semver-newer and matches).

Traefik :3: Was showing 3 → 3 because version resolution was limited to :latest. With #37, it will resolve the actual versions behind the digest.

Immich :release vs Stirling :latest: Same issue — :release didn't get version resolution. Now it will.

Auto updates without approval: Caused by SENTINEL_LATEST_AUTO_UPDATE=true default. Fixed in #37.

[wsw70]

Thank you for the super detailed answer! The changes that unify the X → Y are great.

There is one thing I do not understand, though: according to your description, either all non-semver containers would be updated (SENTINEL_LATEST_AUTO_UPDATE=true), or none (SENTINEL_LATEST_AUTO_UPDATE=false). In my case, however, only some of them do.

I did not change any settings since installing Docker Sentinel (I first wanted to understand everything, and only then make informed decisions), so I do not understand why the updates (or no updates) are not consistent between images.
For reference, I am on v2.3.1 (38ab51b5f6bf5816ca295d595b7c2ff9134869f8).

[Will-Luck]

Good question. The inconsistency is caused by rate limiting during the scan.

Docker Hub's unauthenticated limit is 100 pulls per 6 hours. The scan loop iterates containers in the order Docker returns them (not deterministic). For each container, it checks if there's enough rate limit headroom before making a registry call. Once the remaining quota drops below a safety reserve (10 requests), all remaining containers in that scan cycle are silently skipped.

So if esphome happens to be early in the iteration order, it gets checked and auto-updated. Containers checked later in the loop may hit the rate limit and get skipped entirely — no update, no notification, no queue entry. The only evidence is a debug-level log line.

This isn't a bug per se (it's protecting you from exhausting your Docker Hub quota), but the UX is poor because there's no visibility into why some containers were skipped.

Two things you can do right now:

1. Add Docker Hub credentials in Settings → Registries. Authenticated pulls get 200 pulls/6h (vs 100 unauthenticated), which may be enough for your setup. You can generate a read-only token at https://hub.docker.com/settings/security.
2. Set SENTINEL_POLL_INTERVAL to a longer interval (default is 6h) if you have many containers.

For the next release, we'll look at adding better visibility when containers are skipped due to rate limits — probably a warning in the UI rather than just debug logs.

[wsw70]

Thanks! I have 65 containers and now added credentials for Docker Hub. I will wait until tomorrow (two 6 hours cycles) and see how it looks like.

[Will-Luck]

Actually just implemented this - turned out to be easier than expected because the scan result already tracked RateLimited and error counts internally, they just weren't surfaced anywhere.

What's in the next release:

1. History log entries for skipped containers - when a container is skipped during a scan (rate limit or registry error), it now gets a "Skipped" entry in the update history with the reason (e.g. "rate limit low on docker.io"). You'll see these on both the History page and individual container detail pages.

2. Warning toast after scan - if any containers were skipped or failed during a scan, you'll get a yellow toast like "Scan complete: 3 skipped (rate limit)". Clean scans show nothing (no noise).

In the meantime, adding Docker Hub credentials in Settings → Registries will double your rate limit (200 pulls/6h authenticated vs 100 unauthenticated), which should help avoid the skipping in the first place.

Also, genuinely appreciate all the testing and detailed bug reports you've been filing. Having someone actually put this through its paces with real-world setups is incredibly helpful for finding these kinds of edge cases. Keep them coming!

[wsw70]

Also, genuinely appreciate all the testing and detailed bug reports you've been filing. Having someone actually put this through its paces with real-world setups is incredibly helpful for finding these kinds of edge cases. Keep them coming!

Thank you for this great piece of software. I discovered it when I was almost to the point of coding my own updater (watchtower being abandoned and another solution unreliable). The fact that you managed to code something that works that well with Claude gives hope for better code generation (I use it too, but the results are so-so)