Dockge seems to overwrite compose file with previous values even after saving

[Milind Patel]

⚠️ Please verify that this bug has NOT been reported before.

• I checked and didn't find similar issue

🛡️ Security Policy

• I agree to have read this project Security Policy

Description

I have a compose file for a service called "Tauticord".
In it i specify my discord server id via env variable. I edited that variable with new id in the dockge webui, and saved it. Then it shows the updated changes. But once i refresh the webpage, the changes are reverted and it starts showing old value.

Now the weird part is, the reverted changes are only in the webui of dockge. If i go and manually check my compose.yml file, it has my new edited changes.

But if i now deploy the stack via dockge webui, it uses the old value and overwrites the compose file on disk.

I have tried refreshing the webpage multiple time. I am even accessing it directly via IP:PORT to prevent any issues of caching due to reverse proxy.
I have also tried the "Scan Stacks Folder" button in webui, but it still shows the old value in webui and new value in actual compose file on disk.

Here's the env variable in webui of dockge

Here's it's value that's in compose file accessed directly

👟 Reproduction steps

1. Edit Stack
2. Change env variable value
3. Save stack
4. The variable is updated in webui and on disk
5. refresh the webpage of dockge
6. the changes are reverted to the previous value in the webui only. The compose file on disk keep the new value.
7. But if i deploy the stack from webui, it uses the old value that's showing in the webui and overwriting the compose file on disk with the old value.

👀 Expected behavior

It should retain the new values

😓 Actual Behavior

It's not retaining the new value

Dockge Version

1.4.2

💻 Operating System and Arch

Ubuntu 20.04 x64

🌐 Browser

Firefox

🐋 Docker Version

Docker version 25.0.3, build 4debf41

🟩 NodeJS Version

No response

📝 Relevant log output

Nothing shown in logs when editing a stack.

[Ryan Hartman]

I had this happen too, not for an env var, but a command parameter. In my case, I found that stopping and starting the container manually, via the web UI, resolved the issue. I suspect there is a difference in code structure, or the cached compose used instead of the newly updated version.