PSA: Don't simply update container image in Docker just because it is easy to do. It's so easy to just click 1 time on the update to update it. Read the developer or maintainer release note first.

I updated my Jellyfin server container without reading it first and after update the container stopped immediately after run. Then only I read release note and found out need to stop the container first before update. Also need to update to v10.10.7 before update to the latest v10.11.0, unfortunately I was on v10.9 when I update and run the container. Going from v10.9 directly to v10.11.0 causes the database or config files to be corrupted. I re create back v10.9 container but the server still can't run because the database or config files have corrupted. All the weeks spent to set up the database for the image, description, grouping and many more now all gone.

Never guessed that I have luck on my side. Turned out I have set Snapshot Replication to run every 2 hours for Docker config & cache folder. I restore back the snapshot before update to v10.11.0, re create v10.9 image and it run as if nothing has happened before this.

Another PSA: make sure to have snapshot or versioning for all your files. This is like rewind function back to before the mess up.

the problem with auto updating docker container images to update the app are a couple of things

Cons

1. it MAY or MAY not break your docker container for that app. It may come as a surprise to some, but some of these updates entail ALSO editing your YAML file as WELL as updating the image. Just updating the image might not be sufficient. This is why you have to read the changelog to see if any of those edits need to be done or not. It doesn't happen frequently, but it does happen. An example is Immich. Few times i noticed that broke because didn't update the YAML docker compose file for the new changes.

2. Some of these docker repositories do get hacked into from time to time. The most serious recent case was one repo used by the popular nginx proxy manager. So those malware got onto NPM, and people who simply auto update got a surprise malware that they themselves had auto updated to their NAS.

https://www.bleepingcomputer.com/news/secur...7-npm-packages/



Pro

1. just the usual keep it up to date

2. too lazy to check for update, so you use something like watch towerr to check for new image, then to update based on your own set schedule, daily, weekly? monthly?




For the 1st con that breaks docker containers, one way to deal with that is only set auto update for NON CRITICAL docker container apps. So even if it does break it's not a big deal.


But even then, this does not solve the 2nd problem which is rather serious. You are fully entrusting your NAS security to the github developer.

Well as you can see even they get lax on security and got hit by phishing attacks, and the supply chain they used those resources without any sort of checks, thinking it was safe (it wasnt), then everyone who also trusted npm got hit.

So one method you could do for a balance between auto updating and security safety, don't set the auto update to daily. Set it to like weekly or monthly. Why? because when you stagger an update this way, it gives you time for the github devs to discover and remove these infected packages.

But this is assuming that it does get discovered in the nick of time. Some malware often go undetected for long periods. So it's not a full proof method but it's something.


For backing up your docker container apps, at least in truenas, i suggest you set a fixed location for where you store

1. your yaml docker config templates. For dockge they do this.

2. save a fixed location where your docker data is stored.


Next, STOP all the docker containers from running. I'd go to dockge and stop them. Once done, then run your backup. I use the truenas rsync in the data protection section in UI. This backups the docker templates and data to my backup NAS.



another thing to be aware of, you think that just because you update means that all the security issues got patched, yes? that is not always the case. Often the docker image comes bundled with stuff that has many vulnerabilities that to date haven't been patched. This is why some packages these days have become more popular because they use a leaner setup thus reducing the stuff that may contain vulnerabilities.

Linux alpine builds for example






If you are wondering whether a docker container image has vulnerabilities, you can use something like Trivy to check




then you would at least be somewhat informed that the image you want to deploy has this vulnerability and whether you think its worth using or not.

If it's low risk should be ok. if it's critical, definitely not



Some docker container projects receive so much flak for their lack of security patches that they end up in the news
https://www.securityweek.com/dozens-of-squi...ter-disclosure/


like this squid proxy which you should NEVER use any docker container images with a similar issue most often some docker container images are no longer maintained, or they are lax on vulnerability patches, one it reaches that point, i recommend you find alternatives and don't use that docker image anymore.

if you are unsure as the project is merely 1-2 year not maintained, you can run a trivy scan and check how many vulnerabilities it accrued and remained unfixed but the rule of thumb, if updates is 1-2 year no activity, it's time to move on.

This post has been edited by Moogle Stiltzkin: Nov 2 2025, 07:59 AM