I installed Gladys without Watchtower because I don’t want Gladys and all the other containers to be updated. I want to wait for the first feedback before updating. Especially since, with the external integrations, I don’t think it’s a good idea right now.
I manually started the update, but it doesn’t work. Indeed, the Watchtower image is retrieved, but nothing more. In the end, Gladys is not updated.
Additionally, running this manual update should not update the other containers.
Hello @ArMour85,
Thank you for your feedback, and you’re right about one thing: today, the manual update launches a Watchtower in --run-once mode without restricting the list of containers, so it potentially affects all containers on your machine. This is a behavior we need to fix, I’ll note it.
For your update issue that doesn’t complete, I need some information to confirm what I suspect. Two possible causes:
1. How you disabled Watchtower. If you added the label com.centurylinklabs.watchtower.enable=false to your Gladys container (the classic method to exclude a container), then the Watchtower launched by the « Update » button also respects it: it starts, finds nothing to update, and stops. This exactly matches what you describe.
Can you give me the result of:
docker inspect gladys --format '{{json .Config.Labels}}'
And let me know how you disabled Watchtower: container removed, container stopped, or label on the containers?
2. A silent error. Currently, if something fails after downloading the image, the error is only logged on the server side: the interface remains on « Update in progress » without displaying anything. The Gladys logs at the moment you click the button would tell us everything:
docker logs gladys --tail 200
(click on « Update », wait a minute, then run the command)
And finally, to complete:
docker ps -a
to see if a gladys-watchtower-… container has started and with what exit code.
Thanks in advance, with this we should be able to see clearly quickly.
Well, I didn’t disable anything, I just launched the container creation by running the command from the documentation. I didn’t use docker compose.
Here is the result of the command:
$ sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fb8251117cc4 gladysassistant/gladys:v4.83.0 "docker-entrypoint.s…" 40 hours ago Up 16 hours gladys
$ sudo docker inspect gladys --format '{{json .Config.Labels}}'
{}
Here are the logs:
2026-08-02T12:59:39+0200 <info> system.installUpgrade.js:63 (System.installUpgrade) Pulling nickfedor/watchtower:latest image...
2026-08-02T12:59:41+0200 <info> system.installUpgrade.js:79 (System.installUpgrade) Watchtower container started
2026-08-02T12:59:44+0200 <info> system.installUpgrade.js:113 (System.installUpgrade) Watchtower container finished with status code 0
No Watchtower container but the image does exist:
$ sudo docker image ls
**i** Info → U In Use
**IMAGE** **ID** **DISK USAGE** **CONTENT SIZE** **EXTRA**
**gladysassistant/gladys:v4.83.0** 92e700688a85 2GB 414MB U
**nickfedor/watchtower:latest** 696a5fb17b9a 52MB 13.4MB
You have all the information.
Thanks @ArMour85, your logs provide the answer. It’s neither a label nor an error: it’s the tag of your image.
Your container is running on gladysassistant/gladys:v4.83.0, which is a fixed tag. However, Watchtower updates a container by re-downloading exactly the same tag as the one it was created with. And v4.83.0 will always point to the same image, by definition. Watchtower starts, checks, finds nothing new, and exits cleanly in 3 seconds with code 0, as shown in your logs. With this tag, the « Update » button will never do anything.
The documented tag is gladysassistant/gladys:v4: it’s a rolling tag that follows new versions.
And the important point for your need: it’s not the tag that triggers automatic updates, it’s the Watchtower container. Since you haven’t installed it, nothing will update automatically. By switching to :v4, you keep exactly the control you want, no automatic updates, but the « Update » button works when you decide. That’s the configuration I recommend.
To switch (your data is in /var/lib/gladysassistant, it’s not in the container, so nothing is lost):
sudo docker stop gladys && sudo docker rm gladys
Then restart Gladys with the command here: Install Gladys Assistant with Docker | Gladys Assistant
You will directly get 4.84.1, and future updates will be done from the interface, at your request.
If you really prefer to stay on fixed tags, it’s also possible, but you’ll have to manually update each time (docker pull gladysassistant/gladys:v4.84.1, then stop/rm/run with the new tag).
That said, your feedback highlights three things we need to fix on our side, and I’ll take care of them:
Thanks for the report, it’s very useful.
Oh yes, I had forgotten that I had chosen a specific version for a test, which is why it doesn’t work.
Glad my foolishness highlights issues 
This leads me to a question. Is it possible to do something other than with Watchtower? Gladys knows the latest available version. Even with my foolishness, it would be possible to update to the latest version.
Another interesting feature would also be to be able to roll back in case the latest version doesn’t work. This will also require a backup of the database.
The fixes are available in the latest version of Gladys!
There isn’t really a better solution, as Gladys cannot kill and then recreate its container from within. You necessarily need a third-party container to do the job. Might as well rely on Watchtower, the industry standard for years 