mirror of
https://github.com/moghtech/komodo.git
synced 2026-05-06 08:55:40 -05:00
[GH-ISSUE #767] ENVIRONMENT and .env file: existing contents of .env is deleted on deployment
#6302
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nisrael on GitHub (Aug 25, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/767
Thanks for implementing #716. Unfortunately, we didn’t include the request to make the Environment section in the Web UI reflect changes to the
.envfile (and vice versa). So now the existing file is being replaced during the deploy step.Steps to reproduce:
.envfile with contents:ANOTHER_VAR=1..env.envResult:
The contents of the
.envfile are replaced with the contents of the Environment section.@mbecker20 commented on GitHub (Aug 25, 2025):
First, note that "Additional Env Files" / "Config Files" are available to edit from the Info tab. This is where the changes made to those files are reflected back, and you can use the refresh button to refresh contents from source immediately. Otherwise this is done on the
resource_poll_interaval.The behavior you describe is expected, due to the file name collision in this configuration. It says under "Env File Path" that it will write the contents there to that path, IE overriding existing contents. The 2 simple solutions are:
komodo.env, orbase.envor something like that, and change it on host / in repo to matchJust make sure these don't collide and you will be good which ever way you want to manage it, or use both features together.
Also, if you keep the Komodo Environment (under Config not Info) all commented out / empty, it won't try to write anything. In this case the file collision is OK.
@TheLinuxGuy commented on GitHub (Aug 25, 2025):
+1 this behavior is working as expected and is not a bug. My recommendation is to solely edit and manage your .env within komodo - rather than having multiple .env files that you expect be magically combined.
@nisrael commented on GitHub (Aug 25, 2025):
Thanks for the clarification. I’m now using it as @mbecker20 suggested.
My "problem" is that in our CI/CD pipeline the
TAGvalue in the.envfile gets replaced with the image’s commit SHA instead oflatest. We do this so we can roll back to a previous image if needed. Also I’d like to keep restarting or redeploying the container easy from both the web UI and the CLI. And with this setup that's possible.@Twilek-de commented on GitHub (Aug 25, 2025):
I now can see the contents of the .env file under environment and change them
But if I save the changes in the GUI the file will NOT be written back to the original .env file.
Is this a bug or expected behaviour???
@TheLinuxGuy commented on GitHub (Aug 25, 2025):
Thats WAI.
Komodo managed .env variables at injected at runtime and are NOT dumped into the .env file that gets committed to your repository. This way your secrets are not leaked.
Do note that your .env variables managed by komodo could be leaked if you have setup a ResourceSync job for main.toml - so dump that into a private repository if what you wanted was a backup or viewing the diffs between commits.
@mbecker20 commented on GitHub (Aug 25, 2025):
@TheLinuxGuy you use the Komodo Variables in the Komodo Environment to keep those out of your resource sync files / git
@mbecker20 commented on GitHub (Aug 25, 2025):
@Twilek-de add repo committed env files to Additional Env Files, and leave Environment under Config commented out. You then edit the env file in the Info tab.
@Twilek-de commented on GitHub (Aug 26, 2025):
Ok, I think this is problem of the lingo. With repo you mean on the server where the compose file also sits, not some github shenanigans?! I just want to edit the .env file which is in the same directory as the compose file on the server without the comments being stripped.
@mbecker20 commented on GitHub (Aug 26, 2025):
Yes you are correct, just put it next to the compose file. Comments have not been stripped from env in some time.