Komodo uses old value of env-variable instead of current #631

New Issue

GiteaMirror · 2025-10-31T15:16:43-05:00

GiteaMirror commented

2025-10-31 15:16:43 -05:00

Originally created by @OddMagnet on GitHub (Oct 17, 2025).

I've recently updated one of my services and had to create a new API key for it, so while updating the image I also changed the variable in the .env file.

I pushed the changes to my GitTea instance, the Webhook triggered, Komodo pulled the repo and updated the services.

The service correctly uses the new image version, but it still uses the old value for the .env variable

The .env shows the correct value in the UI as well when looking at it via

docker exec -it komodo-periphery bash 
less /mnt/user/appdata/service/.env

With docker inspect service | grep key I can also see that it uses the old value

When I manually start the service again (from the host system) via

cd /mnt/user/appdata/service
docker compose -f compose.yaml --env-file .env up -d

It uses the current value of the .env file.

I also tried destroying the stack (afaik that's equivalent to a docker compose down) and then redeploy, but it keeps using the old value for the .env variable

Originally created by @OddMagnet on GitHub (Oct 17, 2025). I've recently updated one of my services and had to create a new API key for it, so while updating the image I also changed the variable in the `.env` file. I pushed the changes to my GitTea instance, the Webhook triggered, Komodo pulled the repo and updated the services. The service correctly uses the new image version, but it still uses the old value for the `.env` variable The `.env` shows the correct value in the UI as well when looking at it via ```sh docker exec -it komodo-periphery bash less /mnt/user/appdata/service/.env ``` With `docker inspect service | grep key` I can also see that it uses the old value When I manually start the service again (from the host system) via ```sh cd /mnt/user/appdata/service docker compose -f compose.yaml --env-file .env up -d ``` It uses the current value of the `.env` file. I also tried destroying the stack (afaik that's equivalent to a `docker compose down`) and then redeploy, but it keeps using the old value for the `.env` variable

GiteaMirror closed this issue

2025-10-31 15:16:43 -05:00

GiteaMirror commented

2025-10-31 15:16:44 -05:00

@OddMagnet commented on GitHub (Oct 18, 2025):

Some more debugging I did:

docker exec -it komodo-periphery bash
$ echo $THE_VARIABLE
THE_VARIABLES_OLD_VALUE
$ unset THE_VARIABLE
$ docker compose -p service -f compose.yaml --env-file ../.global.env --env-file .env up -d

After that the correct value was used.
I'm not sure why the variable's old value was set in the periphery containers environment.

What causes that / how do I avoid causing it again in the future?

@OddMagnet commented on GitHub (Oct 18, 2025): Some more debugging I did: ```sh docker exec -it komodo-periphery bash $ echo $THE_VARIABLE THE_VARIABLES_OLD_VALUE $ unset THE_VARIABLE $ docker compose -p service -f compose.yaml --env-file ../.global.env --env-file .env up -d ``` After that the correct value was used. I'm not sure why the variable's old value was set in the periphery containers environment. What causes that / how do I avoid causing it again in the future?

GiteaMirror commented

2025-10-31 15:16:44 -05:00

@mbecker20 commented on GitHub (Oct 18, 2025):

There shouldnt be any place where Periphery sets its container env vars, they should be set by docker. I'm not sure why this env var was set inside container

@mbecker20 commented on GitHub (Oct 18, 2025): There shouldnt be any place where Periphery sets its container env vars, they should be set by docker. I'm not sure why this env var was set inside container

GiteaMirror commented

2025-10-31 15:16:45 -05:00

@OddMagnet commented on GitHub (Oct 19, 2025):

I just tried to destroy and recreate the stack via Komodo's UI, the old value got set again.
Not sure where it's coming from.
Even when I destroy via UI, unset the variable in the periphery container and create again, it uses the old value.
When I execute the docker compose ... up -d (copied from what the UI shows when clicking 'Deploy Stack') command inside the periphery container, it uses the correct value

@OddMagnet commented on GitHub (Oct 19, 2025): I just tried to destroy and recreate the stack via Komodo's UI, the old value got set again. Not sure where it's coming from. Even when I destroy via UI, unset the variable in the periphery container and create again, it uses the old value. When I execute the `docker compose ... up -d` (copied from what the UI shows when clicking 'Deploy Stack') command inside the periphery container, it uses the correct value

GiteaMirror commented

2025-10-31 15:16:45 -05:00

@OddMagnet commented on GitHub (Oct 27, 2025):

I think I figured it out. Komodo itself seemed to get the value from an old env file (initially I had the value in a "global" env file, since multiple services were using it).
I updated the file to remove the value, but didn't docker compose up Komodo again, so it was still captured by Komodo

@OddMagnet commented on GitHub (Oct 27, 2025): I think I figured it out. Komodo itself seemed to get the value from an old env file (initially I had the value in a "global" env file, since multiple services were using it). I updated the file to remove the value, but didn't `docker compose up` Komodo again, so it was still captured by Komodo