Truenas apps have 2 version numbers, one for the container image and one for the apps framework. Most of those updates are most likely not related to the app image but for the framework. If the maintainer changes something on the framework ( new config option exposed) it gets pushed to all apps and all apps will show an update even if there is no change to the image version
1 Like
Exactly, and if I had a way to know it was just a framework update, and it added a new config. I donāt care about that. Iāll wait till the end of the month update, that nonsense. What I want to know is, is this a security update? And if it isnāt a security update, then I will apply it then. But if itās not a security update, then I donāt care. Iāll just wait till the end of the month. Like, I donāt want to be logging into my server every single day, clicking buttons. Maybe itās just me. That seems ridiculous, though. And Iām not saying itās an easy problem to solve. I just donāt think itās a, itās just the reality of the situation, shrug our shoulders and just move on with our lives. And hey, if Iām blowing this out of proportions and Docker security updates arenāt actually that big of a deal, then, you know, Iāll just defer all these updates to an entire month, and this wonāt be an issue. But as far as I understand, we should be updating this stuff.
You could look at which version the update wants to update.
update to āapp versionā = update to the container image
update to āversionā = update to the framework
but i donāt think watchtower works with truenas apps since, afaik it only updates apps with latest tags, not with certain version tags and since truenas apps use certain version tags instead of latest it wonāt update them. And i donāt believe watchtower will update apps if the repository is not dockerhub, but iām not certain on that part.
Edit:
I recently found another docker container called tugtainer for app updates with a gui and an option to specify other repositories to check for updates, which may work with truenas apps. But since i only use 2 truenas apps and one custom app i donāt really care for the frequent updates
Its a reasonable suggestionā¦ please use the Feature Request category and provide a link to it.
1 Like
Yeah itās very practical for administration. App updates tagged as security or bugfix, and changing your config based on what you want is the rough equivalent to the risk acceptance of choosing which OS train to follow. Homelab, latest and greatest but mostly stable, thatās where Iād be. Not beta but may break once in a while, letās go. Iād vote for that feature.
Microsoft has only been doing this for decades, so that admins arenāt 24/7 patching and rebooting stuff. You can decide that n-30 is your patch cadence except for emergency critical security patches for zero day big problems that get patched sooner. We should be able to manage apps the same way.
i use watch towerr to auto update containers, butā¦ i didnt deploy the majority of my apps with truenas apps. i used dockge docker compose method. and in my docker compose, i got the watch tower line for updating or skipping certain containers. it works for that.
for truenas apps UI, that i update manually.
Microsoft doesnāt rely on a bunch of random volunteers to package each app their own way and issue updates whenever they feel like it. If youāre going to trust TrueNASās community apps, you need to trust the community members who maintain and distribute their versions of these apps, even though these community members absolutely never issue changelogs when they make their (very frequent) updates. As many have noticed, the vast majority of these very frequent updates are not for the upstream app itself, just the random volunteerās version of it, for reasons unknown.
Or, you can just abandon the community apps altogether, and get the apps directly from the source. Install Dockge or Portainer, then install each app with a simple docker-compose yaml script pointing to the appās official dockerhub account. Then install Watchtower if you like to keep track of when updates are available. I did this ages ago when I got frustrated with how these ācommunity appsā are run, and I donāt have to deal with frequent updates at all for most apps (just my reverse proxy, which understandably has somewhat frequent security updates). As a bonus, I have far more power to configure apps, such as running them as non-root users, using a VPN for some of them, etc.
FWIW, watchtower is not maintained anymore. There is GitHub - getwud/wud: Keep your containers up-to-date! Ā· GitHub but I did not play with that yet.
1 Like
Your solution is perfectly valid, but I just want to point out that this is a bit of a misinterpretation. Most of these updates you would see where the App Version itself doesnāt change are revisions to the TrueNAS catalog. In many cases these would be an update to, for example, enable a configuration field in a single app form, but this would require a bump to the catalog revision of all apps to keep versioning consistent. So most of those updates you would have seen would not have been because some random maintainer tweaked something in your app, but typically just because something else in the catalog changed and your app is just getting a bump to keep the catalog in sync.
I know there is some work in 26 around making this process more transparent, though Iām not familiar with all the details, and also to make upstream changelogs more visible in the update experience:
4 Likes
omgā¦ didnt know this. ty for the update.
iām assuming your recommendation works similar to watchtowerr? iāll check it out ty.
this sucks because i use watch towerr and it just workedā¦. sigh
i did some research for a alternative
No, nicholas-fedor/watchtower is not considered malware. It is currently one of the most widely recommended and active forks of the original Watchtower project.
The confusion often stems from the fact that the original repository,
containrrr/watchtower, was officially archived
in December 2025. When the original maintainers stepped away, they
warned users about āAI slopā forks that might be untrustworthy. However,
the community has largely vetted Nicholas Fedorās version as a
legitimate, high-quality replacement.
itās got 3.1k stars and seems up to date.
so is switched to
image: nickfedor/watchtower:latest
anyway thx for headsup.
4 Likes
Is that an AI telling you to trust that this project is NOT AI slop? Hmmā¦ 
2 Likes
i also checked elsewhere. obviously i dont put all my eggs in one basket ^^; and of course take with a grain of salt as per usual.
iām not totally oblivious, i do understand the risks
but thx for reminder.
one thing though. the github doesnt mention any notes he wasnāt the original author.
the previous fork i used did
soā¦ yehā¦ 
anyway this is his reddit feed
nick_fedor-
7mo ago
Yes, the Containrrr version of Watchtower has been left unmaintained without any updates.
The lack of dependency updates and ongoing maintenance and/or development from the Containrrr developers has left both it and Shoutrrr (Watchtowerās notification library) in a deteriorating state.
Beatkind has a fork thatās basically the Containrrr version with (mostly) updated dependencies. Iāve been actively developing mine to eliminate many of the pesky issues that have plagued the original version while also integrating some long-overdue functionality.
If youāre not interested in using Watchtower, then there are always other options available, such as using a CI/CD process to trigger updates, Whatās Up Docker, etc.
i tried looking for alternatives, but watchtowerr just works nicely for meā¦ so settled for a fork that i hope is safe
Unforked open source projects are vulnerable too:
Iād say most likely no, being added to the roadmap doesnāt nessessarily mean for the next releaseā¦ it may be scheduled for truenas 27/28 or even later
Trust can be easily damaged, and very difficult to regain. I am buying a Unifi NAS in the next few days, and moving most of my data to that, and relegating TrueNas to occasional testing, with a view to moving off it. Apps will be redeployed on Proxmox. I do hope ixSystems can somehow rebuild the relationship with community members, and learn to value their contributions and feedback, as the unpaid testers they are.
4 Likes
Macvlan creation from GUI. Not in next release?
I have been using them. Use a script to create it when TN boots.
But donāt rely on the slow IX progress to get TN up to par with other open source solutions.
I am using Dockhand now and you can create networks there so I will be implementing my macvlans there.
sorry i missed what happened. what did they do that damaged trust?
i did the macvlan creation last time via portainer. so if my docker container was using a critical port like 8080, and i couldnāt change it, i would set itās networking using the portainer macvlan via the UI in that app.
*update
i just looked up dockhand u mentioned, looks interesting. ty u for the tip
