[Bug] Auto Update failed to start correct updated image

[NotRetarded]

What happened?
Unifi OS Server updated to release 1.30

Expected behavior
Unifi OS Server to show updated version to 5.1.19

Steps to reproduce
DockSentry auto-update

Logs
⚡ Auto-update complete:

✅ Unifi-OS-Server: OK (🗓️ 2026-05-29 → 2026-06-18, 📦 1.9 GB (v1.2.0 → v1.3.0))```

Checking: Unifi-OS-Server (ghcr.io/lemker/unifi-os-server:latest)
Local: sha256:445c3350bdb44ac68a7770e...
Remote: sha256:445c3350bdb44ac68a7770e...

By all accounts the image was updated, but it still showed it was on version 5.1.15, somehow using the older
image.

**Your setup**
- Docksentry version: latest
- Docker version:
- OS:
- Deployment:  Docker Compose

I was able to resolve this in Dockge by stopping 
the container, setting it to inactive, forcing an
update image pull again, and restarting it. 

Simply restarting the container did not work. 
Somehow, even when it downloaded the correct
 image, it still loaded up the previous image until
 I killed it and forced a re-pull and start. 




Setting APP_MODEL to UOSSERVER
Setting APP_VERSION to 5.1.15
Setting FIRMWARE_PLATFORM to linux-x64
Setting  PRODUCT_NAME to UniFi OS Server
Setting UOS_SYSTEM_IP to 192.168.0.50
Setting Unifi-OS-Server exited with code 137
Setting APP_MODEL to UOSSERVER
Setting APP_VERSION to 5.1.19
Setting PRODUCT_NAME to UniFi OS Server
Setting FIRMWARE_PLATFORM to linux-x64
Setting UOS SYSTEM_IP to 192.168.0.50

[amayer1983]

Thanks @NotRetarded — good catch. Found the gap: our compose path ran docker compose up -d --no-deps, which can leave the old container (and old image) running when Compose thinks the service is unchanged — so the new image is pulled but never loaded, and we still report OK.

Fixed in v1.23.7:

• recreate now uses --force-recreate so the container is actually replaced;
• after it comes up we compare the running container's image ID against the pulled one — a mismatch is now reported as a failure, not a success.

That should resolve it on the next auto-update. One thing to confirm: if it ever recurs with matching image IDs, then it's unifi-os-server caching its app version in a volume (separate from the image) — let me know and we'll dig into that angle.

[NotRetarded]

@amayer1983 Thanks for the follow up and fix. I'll reopen the issue if reoccurs. But to confirm: The update did show matching IDs after the update - it didn't use the updated image until I killed the entire container and forced a repull and create of the image.