Findings from reading other projects' bug trackers, each reproduced here before being fixed — plus one feature that came out of the same conversation.
Watch and report, never update
MONITOR_ONLY_CONTAINERS=systemd-*,gitea-* (wildcards, and a docksentry.monitor-only label for anyone who can set one).
@LeeNX runs podman quadlets. systemd owns those containers, so recreating one behind its back leaves two things with an opinion about what should be running. Every existing exit meant stop looking — pin, enable=false and exclude drop the container from the scan entirely, taking the version and update information with it. And with no middle setting he could not turn on auto-update for that host at all; two containers were the only things allowed to update there.
The refusal sits beside the existing self-kill backstop, so it covers the scheduler, the Web UI, both bots, and anything added later. Never automatically and never by hand — the update is wrong no matter who asks. In the table the row keeps its check button and loses everything else, with the disabled tooltip explaining why rather than just greying out.
Not a niche, incidentally: on my own host 8 of 20 running containers are Portainer-managed, where a recreate would fight the tool that deployed them.
EXCLUDE_CONTAINERS takes the same wildcards. A pattern without one behaves exactly as before.
A stale backup could leave Docksentry dead
The self-update helper ran stop && rename && (run || rollback) && rm _old. rename fails when <name>_old survives an interrupted run — and the chain then stops before the run, while the rollback hangs off the run and never executes. The container has already been stopped by that point.
Docksentry down, nothing to bring it back. And since it is the thing that would have told you, nobody finds out until something else is missed.
Proved both directions against throwaway containers:
old script + stale _old → Exited (137), stopped, unrenamed, not updated
new script + stale _old → comes back as the new generation
A comma in a label could set a flag on your behalf
Labels were parsed out of docker ps --format '{{.Labels}}', a flat comma-separated string that loses data two ways, both measured:
A newline in any label value truncates the line. A container carrying docksentry.pin=true alongside a two-line description parsed to just the description — the explicit pin silently ignored, the container left watched and updatable.
A value containing , key=value parses as two labels. So LABEL description="Handy tool, docksentry.enable=false" in somebody else's image sets a docksentry flag for you, baked in rather than chosen.
Labels come from docker inspect now, which takes many refs at once and answers in JSON — one extra call per sweep rather than one per container.
Two ways a failure looked like good news
An unreachable daemon. get_running_containers never checked the return code, so a failing docker ps gave empty output, an empty list, zero updates, that host's pending slice wiped, and an all-clear sent. It raises now — which the Discord bot already expected — and because it raises at the top of the check, the pending file is never touched.
A rate-limited registry. A full scan rewrites this host's pending entries from the updates it found. A container whose check failed is not among them, so its badge and update button vanished and the next report said everything was current. One 429 from Docker Hub was enough. Failed checks are remembered and their entries carried over.
The container table
Seven action buttons need 248px and the column was 179px, so they wrapped and a row with six stood 89px tall next to one with four at 66px. That is why @LeeNX's docker host looked untidy while his podman host, with a uniform action set, did not.
The real constraint was underneath: a 900px cap on the whole content area. On a 2560px monitor the table scrolled sideways by 48px with 1700px of screen sitting empty. The status page has a wider measure now and the buttons no longer wrap. Every row is the same height.
UPDATE_POLICY now admits when it does nothing
It judges bump size from a version string — the OCI image.version label, or a full x.y.z tag. Almost nobody runs :1.2.3; they run :latest, :17, :31-apache. When nothing parses, the update goes through.
That fail-open stays. Switching it would stop every automatic update overnight for anyone on :latest who had set a policy, and a silent change that large is not a bug fix. What does not stay is the silence: someone who sets "patch only" to stop a postgres:16 → 17 jump was never told the setting does not reach that container. Startup reports the real coverage — on my host, 3 of 18 — and names the settings that do work.
Upgrading is the usual docker pull ghcr.io/amayer1983/docksentry:latest, or nothing at all with auto-selfupdate on.