Patch release addressing two #2 reports that didn't need additional diagnostic data to land.
Fixed
Selfupdate history (selfupdate vX → ?) placeholder now always patched
Reported by @famewolf. The post-boot fixup in main.py (since v1.17.6) that replaces the ? with the new VERSION was gated on post_selfupdate_restart, which depends on the deferred_check_file marker. That marker is only written by the auto-selfupdate path (cron + AUTO_SELFUPDATE=true); manual /selfupdate doesn't create it. So users running manual selfupdates — which is most users — saw the ? stick around forever in their history, making downgrade discovery harder ("what was I on before this update?").
Decoupled — the endswith("→ ?)") guard is itself the safety check, so running the fixup on every boot only ever touches the real placeholder and is a no-op otherwise.
Selfupdate no longer reports "❌ Unable to find image 'docker:cli' locally" when it actually worked
Reported by @NotRetarded. The helper-container launch (docker run docker:cli ...) was relying on Docker's implicit auto-pull when the image wasn't local. The auto-pull writes progress to stderr (`Unable to find image 'docker:cli' locally` + layer download lines). If the auto-pull went sideways — slow registry, transient blip, rate limit — the helper-launch subprocess surfaced that stderr as the failure message even when the update completed successfully seconds later.
Fixed: pre-pull docker:cli explicitly before launching the helper. Either the pull succeeds → helper launch is clean and silent → no false failure; or the pull genuinely fails → honest error pointing at the helper image (not at our update logic).
Still pending
@famewolf's homarr deletion report — waiting on diagnostic output (docker ps -a | grep homarr, full stop+kill stderr, journalctl -u docker.service excerpt) to determine whether it was a Docker-daemon cleanup race or a real bug in our code. See issue #2 thread for details.
Upgrade
docker pull amayer1983/docksentry:latest
docker compose up -d