Recent change caused Environment variables to no longer work

[xarinatan]

Today when I updated my dockergen container (latest tag), it no longer worked, seemingly not finding the environment variables I have defined anymore.
When I reverted to 0.14 everything worked fine again, so it seems like in image 9209330fbea3 there's a bug that it doesn't read from environment anymore.

I saw these errors that seem to indicate that it's reading the wrong maps for the wrong variables perhaps, but perhaps I'm wrong:

nginx-proxy-gen   | 2025/06/18 16:15:16 unable to find key from the path expression VIRTUAL_HOST in map map[PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
nginx-proxy-gen   | 2025/06/18 16:15:16 unable to find key from the path expression VIRTUAL_HOST in map map[ACMESH_VERSION:3.1.1 COMPANION_VERSION:v2.6.0-4-g1fd6385 DHPARAM_GENERATION:false DOCKER_HOST:unix:///var/run/docker.sock PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/app]
[...]
map[LETSENCRYPT_HOST:bashquotes.dragonhive.net NODE_VERSION:18.20.8 PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin VIRTUAL_HOST:bashquotes.dragonhive.net VIRTUAL_PORT:3000 VIRTUAL_PROTO:http YARN_VERSION:1.22.22]
nginx-proxy-gen   | 2025/06/18 16:15:16 unable to find key from the path expression CERT_NAME in map map[LETSENCRYPT_HOST:bashquotes.dragonhive.net NODE_VERSION:18.20.8 PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin VIRTUAL_HOST:bashquotes.dragonhive.net VIRTUAL_PORT:3000 VIRTUAL_PROTO:http YARN_VERSION:1.22.22]

Note the VIRTUAL_HOST is present in the maps of the later errors when it's looking for different variables (like CERT_NAME), but not in the maps when it's looking for the VIRTUAL_HOST variable, so perhaps it's grabbing the wrong ones?

I know about the work to move to labels instead of environment variables but this seemed unrelated (and I also recall it being said they would still support the 'legacy' environment variables for the time being)

[aaccioly]

Likely #682 @buchdag.

[buchdag]

@aaccioly agreed 👍

@xarinatan could your pull the image nginxproxy/docker-gen:revert-682 and validate that it fix the issue ?

[xarinatan]

@aaccioly agreed 👍

@xarinatan could your pull the image nginxproxy/docker-gen:revert-682 and validate that it fix the issue ?

Sorry for the delay, I've been busy and forgot to get back to this. I just gave it a quick test in production (because I'm 🤠 like that) and it seems to work 👍
nice quick find! @aaccioly @buchdag

[buchdag]

@xarinatan I'm actually unable to reproduce the bug on my side, and the nginx-proxy test suite seem to pass just fine with a docker-gen version that include the patch from #682, the one that was supposed to cause the bug 🤷

• could you detail the issues you experienced beside the log warnings ?
• could you provide a reproducible example ?

So far I've seen that #682 mistakenly generate a LOT of undesirable logs, but I did not manage to make it break anything.

[xarinatan]

I've tested the latest tag again and it seems like it works again. Previously it definitely didn't work, the frontend was fully offline while I had those error messages in the log I posted in the original report. I'm not seeing those anymore either.. so maybe something was fixed, or maybe it was a temporary glitch on my side somehow (I did reboot the server at least once since for unrelated updates).

So I guess it can be closed for now, I'll reopen it if the problem happens again (or if anyone else runs into it, feel free to reopen it too).

[buchdag]

@xarinatan the issue is that I had to revert a fix for another bug, and I was unable to reproduce the problems you encountered.

In all the tests I've done, I had tons of garbage log messages like the one you mentioned but no actual breakage.

The fix I had to revert is still needed, so I'm gonna need your help to reproduce the problem you had, or confirm that another new version with the aforementioned fix still work for you.

[aaccioly]

@buchdag, it was failing for me as well. In addition to the logs, with a 3-container setup, nginx container was getting stuck in a restart loop. Could you cut a tag "reverting your revert" and maybe trim the excess logs? I'm happy to test it against my setup and, if it fails, try to provide you with a reproducible example.