Given that Watchtower is potentially unmaintained now, this might be a cool alternative?
Screenshot:
Features from their github:
- Extremely fast. Cup takes full advantage of your CPU and is hightly optimized, resulting in lightning fast speed. On my Raspberry Pi 5, it took 3.7 seconds for 58 images!
- Supports most registries, including Docker Hub, ghcr.io, Quay, lscr.io and even Gitea (or derivatives)
- Doesn’t exhaust any rate limits. This is the original reason I created Cup. I feel that this feature is especially relevant now with Docker Hub reducing its pull limits for unauthenticated users.
- Beautiful CLI and web interface for checking on your containers any time.
- The binary is tiny! At the time of writing it’s just 5.4 MB. No more pulling 100+ MB docker images for a such a simple program.
- JSON output for both the CLI and web interface so you can connect Cup to integrations. It’s easy to parse and makes webhooks and pretty dashboards simple to set up!
I may have to give Cups a try. Watchtower is cool and all, but my issue is this:
INFO[35542] Stopping /READECK (1ec5dfc944bc) with SIGTERM INFO[35543] Creating /READECK INFO[35544] Removing image 08fb22cb922b INFO[35544] Session done Failed=0 Scanned=34 Updated=2 notify=no INFO[57099] Found new codeberg.org/readeck/readeck:latest image (ed6901bd8a5a) INFO[57108] Found new ghcr.io/karakeep-app/karakeep:latest image (0513b9703516) INFO[57133] Stopping /READECK (eed5398e0096) with SIGTERM INFO[57134] Creating /READECK ERRO[57134]** Error response from daemon: the container-wide MAC address must match the endpoint-specific MAC address for the main network**, or be left empty INFO[57134] Session done
The bold part is where the problem occurs. So when there is an error response from the daemon, it stops all updates to that container, and leaves it deleted. This has happened to me several times, but not always. It does update other containers but sometimes it gets a little wonky and I haven’t been able to fix that with anything that I have tried.