[GH-ISSUE #716] [FEATURE REQUEST] Ability to edit .env files via the UI #5108

New Issue

GiteaMirror · 2026-04-22T00:22:28-05:00

GiteaMirror commented

2026-04-22 00:22:28 -05:00

Originally created by @GentleHoneyLover on GitHub (Aug 7, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/716

It would be very useful to be able to edit .env files for each stack the same way we can edit compose.yml files:

Currently, if I need to manipulate the .env files I have to be SSHing into the host and editing the files via vim. If this feature is implemented, one could be editing both compose.yml and .env files without ever leaving the Komodo UI.

Thanks!

EDIT: For clarification, the feature request is about having an .env file editable both from the Komodo UI and directly from the host (e. g. via ssh). Just like it is with compose.yml. The source of ".env truth", therefore, is stored in the .env file on disk rather than in the Komodo DB.

Originally created by @GentleHoneyLover on GitHub (Aug 7, 2025). Original GitHub issue: https://github.com/moghtech/komodo/issues/716 It would be very useful to be able to edit .env files for each stack the same way we can edit compose.yml files: <img width="623" height="286" alt="Image" src="https://github.com/user-attachments/assets/1bec68df-9bce-483b-9878-1f92042dfa4f" /> Currently, if I need to manipulate the .env files I have to be SSHing into the host and editing the files via vim. If this feature is implemented, one could be editing both compose.yml and .env files without ever leaving the Komodo UI. Thanks! EDIT: For clarification, the feature request is about having an `.env` file editable both from the Komodo UI and directly from the host (e. g. via ssh). Just like it is with `compose.yml`. The source of ".env truth", therefore, is stored in the `.env` file on disk rather than in the Komodo DB.

GiteaMirror closed this issue

2026-04-22 00:22:28 -05:00

GiteaMirror commented

2026-04-22 00:22:29 -05:00

@thundernode commented on GitHub (Aug 14, 2025):

If you visit the Config tab for your stack you will find the Environment section where should be able to store and edit your .env file

You can save secrets and variables like this as well https://komo.do/docs/variables.

@thundernode commented on GitHub (Aug 14, 2025): If you visit the Config tab for your stack you will find the Environment section where should be able to store and edit your .env file <img width="566" height="857" alt="Image" src="https://github.com/user-attachments/assets/63b2cb95-3e17-4d87-b8a0-9b5f92077724" /> You can save secrets and variables like this as well https://komo.do/docs/variables.

GiteaMirror commented

2026-04-22 00:22:30 -05:00

@GentleHoneyLover commented on GitHub (Aug 14, 2025):

@thundernode, thanks! The way I setup all my stacks is I import existing files from pre-existing locations on the host. Each of my stacks has one .env file in the same folder with compose.yaml. It works well in a sense that I can control my stacks both, from Komodo and via ssh. When an existing stack gets imported, the contents of the pre-existing .env file doesn't get pulled into the Komodo UI though (e. g., the Environment section is empty for all of my stacks). The environment variables themselves are recognized by the docker compose itself correctly — they are just not present in the UI for me.

Is it a bug or a feature? Or am I missing something? :)

@GentleHoneyLover commented on GitHub (Aug 14, 2025): @thundernode, thanks! The way I setup all my stacks is I import existing files from pre-existing locations on the host. Each of my stacks has one `.env` file in the same folder with `compose.yaml`. It works well in a sense that I can control my stacks both, from Komodo and via ssh. When an existing stack gets imported, the contents of the pre-existing `.env` file doesn't get pulled into the Komodo UI though (e. g., the Environment section is empty for all of my stacks). The environment variables themselves are recognized by the docker compose itself correctly — they are just not present in the UI for me. Is it a bug or a feature? Or am I missing something? :) <img width="940" height="917" alt="Image" src="https://github.com/user-attachments/assets/c7711d94-3377-4a16-9476-389c3562a15b" />

GiteaMirror commented

2026-04-22 00:22:31 -05:00

@nisrael commented on GitHub (Aug 15, 2025):

I am using the same workflow as @GentleHoneyLover.

Based on my understanding, here's how it currently works in Komodo: the contents of the environment field are stored in the database directly after clicking Save but it is written to the Env File Path only after clicking the Redeploy link, but before the actual docker compose commands execute. The filename is also passed via CLI.

I would prefer it to work the same way as the compose file does in "files on server" mode, where the contents are read from and written to the default .env file.

Since the filename is passed to the CLI anyway, it would be possible to support both workflows: one field to show and edit .env file contents, and another field for additional variables with a filename that is not .env.

@nisrael commented on GitHub (Aug 15, 2025): I am using the same workflow as @GentleHoneyLover. Based on my understanding, here's how it currently works in Komodo: the contents of the environment field are stored in the database directly after clicking Save but it is written to the Env File Path only after clicking the Redeploy link, but before the actual docker compose commands execute. The filename is also passed via CLI. I would prefer it to work the same way as the compose file does in "files on server" mode, where the contents are read from and written to the default .env file. Since the filename is passed to the CLI anyway, it would be possible to support both workflows: one field to show and edit .env file contents, and another field for additional variables with a filename that is not .env.

GiteaMirror commented

2026-04-22 00:22:31 -05:00

@GentleHoneyLover commented on GitHub (Aug 15, 2025):

@nisrael just described the essence of my feature request :)

@GentleHoneyLover commented on GitHub (Aug 15, 2025): @nisrael just described the essence of my feature request :)

GiteaMirror commented

2026-04-22 00:22:32 -05:00

@mbecker20 commented on GitHub (Aug 24, 2025):

https://github.com/moghtech/komodo/releases/tag/v1.19.1

@mbecker20 commented on GitHub (Aug 24, 2025): https://github.com/moghtech/komodo/releases/tag/v1.19.1

Sign in to join this conversation.