Import existing env file on disk to show/edit in Komodo #1017

Closed
opened 2026-03-22 17:05:55 -05:00 by GiteaMirror · 14 comments
Owner

Originally created by @kpatdev on GitHub (Feb 9, 2025).

Maybe I am doing something wrong but I have stacks exposed to periphery and when I set them up the compose file shows up in Komodo. This is great, but within these stack folders I also have .env files. Those .env files do not show up in Komodo.

So for example, I've setup a stack called immich in Komodo. I set the run directory to /etc/komodo/stacks/immich. After saving, when I go to the Info tab in the stack I can see my compose.yaml from my disk. However, on the Config tab, at the Environment section, the path to the env file relative to the run directory is .env which is correct, but the environment variables do not populate with my defined variables in the existing .env file on disk.

Folder structure for clarification:

.
└── etc/
    └── komodo/
        └── stacks/
            ├── immich/
            │   ├── compose.yaml
            │   └── .env
            └── librechat/

I am unsure if this is by design or if I have a misconfiguration somewhere but this feature/ability would be great and would reduce my reason to edit the files directly in VSCode or something and I can just manage everything right from Komodo.

Please let me know if more info is needed.

Thanks!

Originally created by @kpatdev on GitHub (Feb 9, 2025). Maybe I am doing something wrong but I have stacks exposed to periphery and when I set them up the compose file shows up in Komodo. This is great, but within these stack folders I also have .env files. Those .env files do not show up in Komodo. So for example, I've setup a stack called `immich` in Komodo. I set the run directory to `/etc/komodo/stacks/immich`. After saving, when I go to the Info tab in the stack I can see my compose.yaml from my disk. However, on the Config tab, at the Environment section, the path to the env file relative to the run directory is `.env` which is correct, but the environment variables do not populate with my defined variables in the existing .env file on disk. Folder structure for clarification: ``` . └── etc/ └── komodo/ └── stacks/ ├── immich/ │ ├── compose.yaml │ └── .env └── librechat/ ``` I am unsure if this is by design or if I have a misconfiguration somewhere but this feature/ability would be great and would reduce my reason to edit the files directly in VSCode or something and I can just manage everything right from Komodo. Please let me know if more info is needed. Thanks!
Author
Owner

@fdisamuel commented on GitHub (Mar 22, 2025):

I would also like to know whether this is intentional, or a bug! In case the earlier, I would really appreciate the ability to edit the existing .env files through komodo as well. Thank you!

@fdisamuel commented on GitHub (Mar 22, 2025): I would also like to know whether this is intentional, or a bug! In case the earlier, I would really appreciate the ability to edit the existing .env files through komodo as well. Thank you!
Author
Owner

@SeiyaGame commented on GitHub (Mar 24, 2025):

That would be a really great feature, I'm waiting for it to switch to Komodo, I've already had the opportunity to discuss it on reddit

@SeiyaGame commented on GitHub (Mar 24, 2025): That would be a really great feature, I'm waiting for it to switch to Komodo, I've already had the opportunity to discuss it on [reddit](https://www.reddit.com/r/selfhosted/comments/1hethhe/comment/m28lnx7/?context=3)
Author
Owner

@kpatdev commented on GitHub (Apr 4, 2025):

Is there any updates to this? Looking for any type of clarification on this. Would really help legitimize this project and put it above the likes of Portainer or Dockge.

Unfortunately I'm seeing many issues ignored/disregarded.

@kpatdev commented on GitHub (Apr 4, 2025): Is there any updates to this? Looking for any type of clarification on this. Would really help legitimize this project and put it above the likes of Portainer or Dockge. Unfortunately I'm seeing many issues ignored/disregarded.
Author
Owner

@OddMagnet commented on GitHub (Apr 8, 2025):

I'm in the process of moving (or wanting to move) to Komodo as well.
I make heavy use of .env files and would love it if Komodo would allow me to manage them in the same way as it does with the yaml files.

Simply copy&pasting the existing content of my .env files into the UI is something I want to avoid, since then I'd have two sources of truth for my config

@OddMagnet commented on GitHub (Apr 8, 2025): I'm in the process of moving (or wanting to move) to Komodo as well. I make heavy use of `.env` files and would love it if Komodo would allow me to manage them in the same way as it does with the yaml files. Simply copy&pasting the existing content of my `.env` files into the UI is something I want to avoid, since then I'd have two sources of truth for my config
Author
Owner

@itzwolf commented on GitHub (May 3, 2025):

Bump! Came looking for information about this very topic/issue. Seems I can only get specifically configured variables to create a .env (no comments come through on disk side), but Komodo will not read an existing one stored on disk like it does docker-compose.yml files. Periphery is installed as a systemd service if that helps any.

@itzwolf commented on GitHub (May 3, 2025): Bump! Came looking for information about this very topic/issue. Seems I can only get specifically configured variables to create a .env (no comments come through on disk side), but Komodo will not read an existing one stored on disk like it does docker-compose.yml files. Periphery is installed as a systemd service if that helps any.
Author
Owner

@jlssmt commented on GitHub (May 3, 2025):

+1 here. big show stopper for switching

@jlssmt commented on GitHub (May 3, 2025): +1 here. big show stopper for switching
Author
Owner

@jmarmstrong1207 commented on GitHub (May 19, 2025):

I'm in the process of moving (or wanting to move) to Komodo as well. I make heavy use of .env files and would love it if Komodo would allow me to manage them in the same way as it does with the yaml files.

Simply copy&pasting the existing content of my .env files into the UI is something I want to avoid, since then I'd have two sources of truth for my config

Copying the .env contents to the UI won't make a second a copy actually. So that means to set it up, just copy/paste to the UI and it'll show up from now on. Seems like it might be a easy fix for those who know the codebase.

Keep note that doing this through the UI will also pass the file to the container itself (if you're just using it to define variables for your compose file

@jmarmstrong1207 commented on GitHub (May 19, 2025): > I'm in the process of moving (or wanting to move) to Komodo as well. I make heavy use of `.env` files and would love it if Komodo would allow me to manage them in the same way as it does with the yaml files. > > Simply copy&pasting the existing content of my `.env` files into the UI is something I want to avoid, since then I'd have two sources of truth for my config Copying the .env contents to the UI won't make a second a copy actually. So that means to set it up, just copy/paste to the UI and it'll show up from now on. Seems like it might be a easy fix for those who know the codebase. Keep note that doing this through the UI will also pass the file to the container itself (if you're just using it to define variables for your compose file
Author
Owner

@yvvidolov commented on GitHub (Jul 23, 2025):

+1
There is already an editor available for Stack -> Config -> Files -> File Paths
So why not make the same available for Stack -> Config -> Environment -> Additional Env Files

@yvvidolov commented on GitHub (Jul 23, 2025): +1 There is already an editor available for Stack -> Config -> Files -> File Paths So why not make the same available for Stack -> Config -> Environment -> Additional Env Files
Author
Owner

@yvvidolov commented on GitHub (Jul 23, 2025):

I present to you a simple use-case:

  • Configure stack from a public git repository (compose.yml, .env)
  • Modify ports/passwords in .env for your specific needs
  • Deploy and enjoy the fruits of your labor

Current workflow:

  • Configure stack from a public git repository (compose.yml, .env)
  • Copy only relevant options from .env file to: Stacks -> Config -> Environment
  • Set: Stacks -> Config -> Env File Path: .env-override (so we don't overwrite future repository updates of the standard .env file)
  • Set: Stacks -> Config -> Additional Env Files: '.env' and '.env-override' (both are needed, because 'Env File Path' will always be given first to the docker compose command)

This results in the following deployment command:
docker compose -p db -f docker-compose.yml --env-file .env-override --env-file .env --env-file .env-override pull
So the options from .env-override will indeed overwrite the settings in the .env file from the repository.
We can now easily change some of the settings from the UI and redeploy.

Example Stack Sync:
I add this to a private repo for easy deployment using configuration as code:

[[stack]]
name = "stack_name"

[stack.config]
server = "server_name"
repo = "git_namespace/repository_name"

run_directory = "docker_path"
file_paths = ["docker-compose.yml"]
additional_env_files = [".env", ".env-override"]

env_file_path = ".env-override"
environment = """
PORT=1337
APP_URL=https://your_app.your_domain.com
MYSQL_ROOT_PASSWORD=super_secret_password
APP_KEY=super_secret_token
"""

After executing the sync, the additional settings are visible in the stack UI. And most importantly they are persistent if git_namespace/repository_name gets updated.

p.s. My compliments to the developers for adding configuration as code. I haven't had this much fun with a piece of software in a very long time.

@yvvidolov commented on GitHub (Jul 23, 2025): **I present to you a simple use-case:** - Configure stack from a public git repository (compose.yml, .env) - Modify ports/passwords in .env for your specific needs - Deploy and enjoy the fruits of your labor **Current workflow:** - Configure stack from a public git repository (compose.yml, .env) - Copy only relevant options from .env file to: Stacks -> Config -> Environment - Set: Stacks -> Config -> Env File Path: .env-override (so we don't overwrite future repository updates of the standard .env file) - Set: Stacks -> Config -> Additional Env Files: '.env' and '.env-override' (both are needed, because 'Env File Path' will always be given first to the docker compose command) This results in the following deployment command: `docker compose -p db -f docker-compose.yml --env-file .env-override --env-file .env --env-file .env-override pull` So the options from .env-override will indeed overwrite the settings in the .env file from the repository. We can now easily change some of the settings from the UI and redeploy. **Example Stack Sync:** I add this to a private repo for easy deployment using configuration as code: ``` [[stack]] name = "stack_name" [stack.config] server = "server_name" repo = "git_namespace/repository_name" run_directory = "docker_path" file_paths = ["docker-compose.yml"] additional_env_files = [".env", ".env-override"] env_file_path = ".env-override" environment = """ PORT=1337 APP_URL=https://your_app.your_domain.com MYSQL_ROOT_PASSWORD=super_secret_password APP_KEY=super_secret_token """ ``` After executing the sync, the additional settings are visible in the stack UI. And most importantly they are persistent if git_namespace/repository_name gets updated. > p.s. My compliments to the developers for adding configuration as code. I haven't had this much fun with a piece of software in a very long time.
Author
Owner

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

I plan to do this feature one better. Why stop at .env? What if you can edit arbitrary config files from Komodo? https://github.com/moghtech/komodo/issues/92

@mbecker20 commented on GitHub (Jul 24, 2025): I plan to do this feature one better. Why stop at `.env`? What if you can edit arbitrary config files from Komodo? https://github.com/moghtech/komodo/issues/92
Author
Owner

@kpatdev commented on GitHub (Aug 25, 2025):

Glad to see #740. Should we close this as completed?

@kpatdev commented on GitHub (Aug 25, 2025): Glad to see #740. Should we close this as completed?
Author
Owner

@Checker8763 commented on GitHub (Aug 25, 2025):

The release of 1.19.1 is epic and a step forward.
For me one issue remains, I don't have the option to add config files in a ui defined stack...

I don't se the technical difference that would ui definded stacks be unable to have addidtional config files, as they are compose.yaml on the server like a "file from server"-stack.

@Checker8763 commented on GitHub (Aug 25, 2025): The release of 1.19.1 is epic and a step forward. For me one issue remains, I don't have the option to add config files in a ui defined stack... I don't se the technical difference that would ui definded stacks be unable to have addidtional config files, as they are compose.yaml on the server like a "file from server"-stack.
Author
Owner

@Checker8763 commented on GitHub (Aug 25, 2025):

Please correct me if I missed something or should open this in a seperate or moe related issue.

The release of 1.19.1 is epic and a step forward. For me one issue remains, I don't have the option to add config files in a ui defined stack...

I don't se the technical difference that would ui definded stacks be unable to have addidtional config files, as they are compose.yaml on the server like a "file from server"-stack.

@Checker8763 commented on GitHub (Aug 25, 2025): Please correct me if I missed something or should open this in a seperate or moe related issue. > The release of 1.19.1 is epic and a step forward. For me one issue remains, I don't have the option to add config files in a ui defined stack... > > I don't se the technical difference that would ui definded stacks be unable to have addidtional config files, as they are compose.yaml on the server like a "file from server"-stack.
Author
Owner

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

@Checker8763 its a different feature for UI defined, actually older and I opened issue for it last year #92. Its more complicated so I ended up doing filed on host / git repo one first.

@mbecker20 commented on GitHub (Aug 26, 2025): @Checker8763 its a different feature for UI defined, actually older and I opened issue for it last year #92. Its more complicated so I ended up doing filed on host / git repo one first.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/komodo#1017