The source issue was real in the 2024–2025 ZimaOS app model: installing an app with latest could resolve that tag at installation time, but ZimaOS then kept the resolved version rather than automatically following future registry changes behind the same tag. Zima-Giorgio said this behavior was intentional for stability and repeatedly warned that forcing an app upgrade could break it.
Two things have changed since. First, ZimaOS 1.7 introduced App Store 2.0 with a dedicated installed-app management page and update status. Second, Docker semantics still matter: a running container never automatically becomes the new image merely because the registry's latest tag moved. An update always requires detecting/pulling a changed image and recreating the container or stack.
The Historical ZimaOS Design Resolved the Tag Then Fixed the Version
Giorgio explained that latest was effective when the app was installed, after which ZimaOS held the version stable. That was meant to reduce surprise breakage from upstream images changing underneath users.
The same community problem later appeared with develop and likely any mutable named tag—not only latest.
Docker latest Never Means “Auto-Update My Running Container”
A mutable tag is only a registry pointer. If example/app:latest points to a new image tomorrow, an already-created container continues using its existing image until an update workflow pulls/recreates it.
Therefore “latest” and “automatic update” are separate concepts even outside ZimaOS.
The Source Used Explicit Version Tags as a Workaround
CogZog reported manually changing Immich's tag to the published version number and getting the app onto v1.132.3. Giorgio later said users who needed a specific version could edit the app version field and save.
This was a community/user-level workaround, not proof that blindly updating every app to the newest upstream image is safe.
Multi-Container Apps Can Break When Only One Image Is Updated
Immich is a good example: server, machine learning, database, and cache components may have coordinated migration requirements. Editing one tag without following the app's upstream release/migration instructions can create an incompatible mixed stack.
ZimaOS 1.7 Added Explicit Installed-App Update Management
The current ZimaOS App Store presents installed apps in one management page, including their status and update availability. App Store 2.0 packages also include version metadata/content hashes used to detect package changes.
See the current App Store update experience.
Store Apps and Custom Compose Have Different Update Owners
For an App Store package, the store maintainer decides when a tested package update is published. For a custom Compose stack, you are the maintainer: you decide the image tag/digest, read upstream release notes, pull the new image, and recreate the stack.
Do not expect the store to rewrite a custom Compose file or automatically migrate a custom database.
Explicit Version Pinning Is Often Safer for Important Services
For databases, photo managers, automation systems, and other stateful apps, a tested version tag or digest plus deliberate upgrade window gives you rollback planning and time to read breaking changes.
For disposable/stateless tools, following a mutable tag may be acceptable if you still control when the pull/recreate occurs.
Docker Tag Update FAQ
Did the source user misunderstand Docker latest entirely?
No. ZimaOS really did pin the resolved app version in the historical design, but Docker itself also requires an image pull/recreate to update a running container.
Does current ZimaOS have an app update management page?
Yes. App Store 2.0 added installed-app update status and management.
Should every app always follow latest automatically?
No. Mutable-tag updates can introduce breaking changes, especially for stateful or multi-container applications.
