Update Monitor for ZimaOS

Insight & Feedback
1

Hi everyone,

after working on Disk Monitor, I started another project for ZimaOS: Update Monitor.

The idea came from a problem I had myself: Docker update detection is not always clear enough, especially when containers use tags like latest, fixed versions, different registries or multiple services in one stack.

So I built Update Monitor to make Docker updates easier to understand and manage directly from ZimaOS.

What Update Monitor can do

  • Checks installed Docker applications for available updates
  • Shows installed and available versions
  • Supports fixed versions and following tags like latest
  • Individual update policies for each app
  • Manual and automatic updates
  • Targeted verification after an update
  • Backup before updates
  • Restore existing backups
  • Docker app start, stop and restart functions
  • GitHub and Docker Registry version checks
  • Supports applications with multiple containers
  • Persistent settings and policies
  • German and English interface
  • Responsive interface for desktop, tablet and phone

Update Monitor also tries to avoid false update notifications. For example, a newer upstream version can still be displayed for information even when an application is intentionally fixed to an older version.

Security

Update Monitor needs access to the Docker socket because it reads Docker information and can perform Docker actions.

Before the first start, please change:

UPDATE_MONITOR_USERNAME

UPDATE_MONITOR_PASSWORD

UPDATE_MONITOR_SESSION_SECRET

The GitHub token is optional.

Current version

v0.3.316

Installation

Update Monitor is now available through my ZimaOS third party App Store:

https://isanto1306.github.io/zima-appstore/store.json

You can also find the source code here:

https://github.com/isanto1306/Update-Monitor

Feedback

This is still a project I am actively developing.

If you find bugs, strange version detection, problems with a specific Docker image or have ideas for improvements, please let me know.

I would especially be interested in tests with different Docker applications and setups.

Thanks!

iSanto1306

2

Hi iSanto1306,

I installed Update Monitor v0.3.330 on my ZimaCube Pro and completed a full scan of 96 images. The container is healthy, the persistent mounts are correct, and the interface is very impressive.

I found a few items that may be worth reviewing:

  1. The initial scan remained at 93% for a long time while checking versions. It eventually completed successfully, but it appeared frozen because there was no intermediate counter or progress update during that stage.

  2. Frigate uses ghcr.io/blakeblackshear/frigate:stable, but Update Monitor displays 0.15.0-beta1 as the available version. A stable installation should not appear to be offered a beta version without clear warning or confirmation.

  3. Mailcow contains 18 containers. The application card displays 1.98 as the available version, but this appears to refer to the ghcr.io/mailcow/acme component currently using 1.97, rather than the overall Mailcow release. This could be misleading at the application level.

  4. Four port conflicts were reported for ports 8080, 8099, 8610 and 8798. Docker verification showed that only one affected container was currently running:

clamav-dashboard-v024  ***.***.1.100:8099->8080/tcp

The remaining reported conflicts were between stopped applications. It may be clearer to separate active port conflicts from configured port overlaps involving stopped containers.

  1. The Notices panel contains many individual version-confirmation warnings for local images and moving tags such as latest, main, stable and alpine. The warnings are valid, but grouping or filtering them would make the panel easier to manage.

  2. The application correctly refused to start when the session secret was shorter than 32 characters. A visible length indicator or automatic secret generator in the installation form could help prevent the resulting restart loop.

I have not installed any detected updates because I want to verify the reported versions first.

Overall, this is a very useful and well-designed application. These findings are from actual Docker verification on my Cube, not only from the dashboard.

3

Hi gelbuilding,

thank you very much for the detailed testing and especially for verifying the results directly against Docker on your ZimaCube Pro.

This is very useful feedback.

I will review all six points carefully. In particular:

  • the progress indication during the version checking stage
  • Frigate stable incorrectly showing a beta version
  • Mailcow component versions being displayed as if they were the overall application version
  • separating active port conflicts from configured overlaps involving stopped containers
  • improving the grouping/filtering of notices
  • making the session secret requirement clearer during installation

The Frigate and Mailcow findings are especially important because Update Monitor should not present a misleading update version at application level.

Thank you also for not installing the detected updates before verifying the versions. Version detection and update safety are areas I want to handle very carefully.

Thanks again for taking the time to test Update Monitor with 96 images and for providing such detailed results.

4

Hi iSanto,

Thank you for the quick and thoughtful reply.

Since my previous post, I went one step further and completed two controlled update tests.

I first updated Homepage from v2.1.2 to v2.3.0 using Full app backup. The update was quick, Homepage returned healthy, and all my settings were preserved. That worked perfectly.

I then tested an unused Mailcow installation with 18 stopped containers. Update Monitor successfully updated the Memcached image, preserved my modified files and correctly returned the stack to its previous stopped state. ACME remained on the configured 1.97 image, confirming that the displayed 1.98 was informational rather than an update that was applied.

I was genuinely impressed with how quickly the update and targeted verification completed.

However, the Mailcow test revealed an important issue with Full app backup.

My Docker named volumes are stored under:

/media/Samsung SSD 980 PRO 1TB/docker/volumes/

The completed Mailcow backup was only 46 MB. Its metadata showed:

MODE=full
CONTAINERS=18
PERSISTENT_DETECTED=51
MOUNTS_COPIED=51
COPIED_TYPES={'bind': 51}

It copied 51 bind mounts but none of the Docker named volumes. Approximately 581 MB of MySQL, ClamAV, Rspamd, Redis, SOGo and other persistent volume data was excluded.

It appears that the named volumes were treated as media mounts because Docker’s data root is located under /media. On ZimaOS, Docker volumes can be stored on different disks under /media, so I believe mounts with Type=volume should still be included even when their resolved host path contains /media. Media bind mounts should continue to be excluded.

Two smaller UI observations from the update test:

  • Mailcow’s detailed view becomes extremely long and narrow with 18 containers, making it difficult to identify the affected images.
  • The red button under the Uninstall section is labelled INSTALL. I believe this should say UNINSTALL, as the current label could be dangerous.

Apart from the named-volume backup issue, the actual update and verification workflow performed very well.

5

Hi, I’ve now worked through all the issues you reported and the fixes are included in Update Monitor v0.3.342.

This includes the Full Backup issue with Docker named volumes, the long multi container view, the incorrect uninstall label, version detection issues, port conflict handling, scan progress, notices, and the update/backup handling.

I also found and fixed a release issue where the previous update was still pulling the old v0.3.341 Docker image. The v0.3.342 image has now been rebuilt and published correctly.

If you have time, could you please update to v0.3.342 and test the reported issues again, especially the Full Backup with Docker named volumes?

If you find anything else, please let me know.

6

Hi Santos,

I updated to the latest published image, which appears to be v0.3.345, and tested it again.

Overall, I’m very impressed. The interface feels much more polished, nearly everything is clickable, the progress display is clearer, and the large multi-container view is much easier to work with.

I specifically tested the Full Backup fix using an isolated ZimaOS Compose app with one Docker named volume stored on a different SSD. I added a test file, created a Full Backup, changed the file and added another file, then restored the backup.

The result was successful:

  • One persistent named volume was detected and copied.

  • The metadata correctly recorded it as a Docker volume.

  • The original file returned with the exact same SHA-256 checksum.

  • The file created after the backup was removed during restoration.

  • The live app data and Compose file remained unchanged when the later image pull failed.

The image update itself could not complete because Docker Hub returned an unauthenticated pull-rate-limit error, but Update Monitor displayed that error clearly and safely left the existing container and image unchanged.

I found a few remaining issues:

  • Under the Uninstall section, the red button still says INSTALL.

  • A Compose app installed outside the ZimaOS app directory was offered an update, but installation failed with HTTP 404: app 'casadrop' not found. It may be better to detect this before showing Install Update, or fall back to the Docker Compose labels and file path.

  • The Check error badge does not show the actual reason in Notices or the Docker information screen. In my test, the local image had no RepoDigest. Pulling the same fixed tag populated the digest and cleared the error.

  • After returning CasaDrop from Switch to a new version to Version fixed, the card correctly returned to Current with Update 0, but a red Select version message and New version badge remained.

  • During the restore test, the named-volume data restored correctly, but the operation was reported as failed because the temporary test container did not pass its health check. Update Monitor safely stopped it, although it had started the previously stopped test container during validation.

The important result is that the Docker named-volume Full Backup and restoration are now working correctly. That was the main issue I wanted to verify.

Very good work on this update.

7

First of all, thank you for this very successful application.
I tested it for a long time, as a user, I am not a developer.
Having offered several languages is really very pleasant.
I was able to update, extremely precisely, my numerous dockers applications.
Automatic backup for a reconstruction of the previous version remains very secure.
This is the best app for making updates I’ve ever seen. It’s impressive.
In short, a superb tool and many thanks for your work.

8

Hi Gelbuilding,

all issues from your latest test round should now be fixed. The remaining Disk Monitor issues have also been addressed in Update Monitor v0.3.348, including the incorrect digest pin detection and sha-* build tags being treated as normal application versions.

Thank you very much for testing everything again and for the detailed feedback. It was really helpful and helped me find several cases that I would probably not have noticed otherwise.

If you have time, please update to v0.3.348 and give it another test. If you notice anything else, just let me know.

Thanks again!

9

Thank you very much for your kind words and for taking the time to test Update Monitor so thoroughly.

I’m especially happy to hear that the update process, language support and backup functionality worked well for you.

Feedback like this means a lot to me and motivates me to keep improving the app.

If you ever notice any issue or have an idea for a new feature, please feel free to let me know.

Thanks again for your support!

10

For my part, with Lintux’s Firewall and Cron (too bad it’s not multilingual), this application is great. Update Monitor no longer leaves my server.
Disk monitor is also really good. Better than Scrutiny.
If a developer could create a sync and backup app as ergonomic and easy to use as the apps mentioned, that would be great.
Please thank you for your creations. They are now in production on my server. I will be sure to provide feedback like I do with @Lintux. Kind regards.

11

Hello, I use your two applications—Disk and Update Monitor—on my main server every day.

Concerning Disk Monitor, would it be possible to have an alert functionality (e-mail for example) in the event of a hard drive crash.

Concerning Update Monitor would it be possible to have the functionality to stop the backup in progress. This could allow you to change the current backup mode. This can be practical when you realize that the folder to save is too large.

For these two applications, will there be a light and dark mode (optional)?

Thanks again for your great work.

12

Thank you for your feedback and for using both applications every day.

For Disk Monitor, I have now added an e-mail notification feature for drive problems.

For Update Monitor, I have also added the option to cancel a backup while it is running.

Regarding the light and dark mode: after testing this, I decided to keep both applications in their current dark design. A light mode is not planned and will not be added in the future.

Thanks again for your suggestions and support.