[GH-ISSUE #28] [Feature] global .env file for all stacks #10545

New Issue

GiteaMirror · 2026-05-12T20:43:55-05:00

GiteaMirror commented

2026-05-12 20:43:55 -05:00

Originally created by @C0untZero on GitHub (Aug 12, 2024).
Original GitHub issue: https://github.com/moghtech/komodo/issues/28

It would be nice to have a ui option to set a global .env file that would auto apply to all created stacks.
At the moment I created a .env file on my filesystem and shared it with the periphery systemd service, but it would be nice to be able to manage this through monitor itself, and would also give us the ability to reuse one config across different servers.

Originally created by @C0untZero on GitHub (Aug 12, 2024). Original GitHub issue: https://github.com/moghtech/komodo/issues/28 It would be nice to have a ui option to set a global .env file that would auto apply to all created stacks. At the moment I created a .env file on my filesystem and shared it with the periphery systemd service, but it would be nice to be able to manage this through monitor itself, and would also give us the ability to reuse one config across different servers.

GiteaMirror added the enhancement label 2026-05-12 20:43:55 -05:00

GiteaMirror commented

2026-05-12 20:43:57 -05:00

@mbecker20 commented on GitHub (Aug 12, 2024):

I'm not totally sure what you mean by this: "At the moment I created a .env file on my filesystem and shared it with the periphery systemd service".

But I have some idea for a solution for shared environments. What if you can create multiple global environments, and attach them to Resources like Deployment, Stack?

This way, you have preset variables / values that you can attach to multiple resources, and edit them all together. But also, maybe you have a different set of services, and those want to share different environment variables. So we can just have as many Global Environments as we want, and attach them to particular resources.

And also, the global variables attached would be combined with any specific ones defined on the resource. Specific ones on the resources would have priority in the case of any variable collisions.

@mbecker20 commented on GitHub (Aug 12, 2024): I'm not totally sure what you mean by this: "At the moment I created a .env file on my filesystem and shared it with the periphery systemd service". But I have some idea for a solution for shared environments. What if you can create multiple global environments, and attach them to Resources like Deployment, Stack? This way, you have preset variables / values that you can attach to multiple resources, and edit them all together. But also, maybe you have a different set of services, and those want to share different environment variables. So we can just have as many Global Environments as we want, and attach them to particular resources. And also, the global variables attached would be combined with any specific ones defined on the resource. Specific ones on the resources would have priority in the case of any variable collisions.

GiteaMirror commented

2026-05-12 20:43:58 -05:00

@C0untZero commented on GitHub (Aug 13, 2024):

I'm not totally sure what you mean by this: "At the moment I created a .env file on my filesystem and shared it with the periphery systemd service".

Sorry I'm a linux noob so bear with me. The way I got it to work right now is by editing /etc/systemd/system/periphery.service to add the EnvironmentFile line:

[Unit]
Description=agent to connect with monitor core

[Service]
ExecStart=/usr/local/bin/periphery --config-path /etc/monitor/periphery.config.toml
EnvironmentFile=/home/ignis/compose/global.env
Restart=on-failure
TimeoutStartSec=0

[Install]
WantedBy=default.target

That way I can reference variables defined in the file from my compose yamls, as from what I saw I can't just reference regular environment variables added in /etc/environment. That may be some confusion in the setup steps on my end, but it works in the above described way.

But I have some idea for a solution for shared environments. What if you can create multiple global environments, and attach them to Resources like Deployment, Stack?

This way, you have preset variables / values that you can attach to multiple resources, and edit them all together. But also, maybe you have a different set of services, and those want to share different environment variables. So we can just have as many Global Environments as we want, and attach them to particular resources.

And also, the global variables attached would be combined with any specific ones defined on the resource. Specific ones on the resources would have priority in the case of any variable collisions.

That sounds awesome. I would also add the ability to attach them to servers, that way if you have a variable called $FILE_PATH, their values would be different across two servers but all deployments/stacks that use it would just use the one variable name and would have the correct value for the server they're deployed on.

@C0untZero commented on GitHub (Aug 13, 2024): > I'm not totally sure what you mean by this: "At the moment I created a .env file on my filesystem and shared it with the periphery systemd service". Sorry I'm a linux noob so bear with me. The way I got it to work right now is by editing /etc/systemd/system/periphery.service to add the EnvironmentFile line: ``` [Unit] Description=agent to connect with monitor core [Service] ExecStart=/usr/local/bin/periphery --config-path /etc/monitor/periphery.config.toml EnvironmentFile=/home/ignis/compose/global.env Restart=on-failure TimeoutStartSec=0 [Install] WantedBy=default.target ``` That way I can reference variables defined in the file from my compose yamls, as from what I saw I can't just reference regular environment variables added in /etc/environment. That may be some confusion in the setup steps on my end, but it works in the above described way. > But I have some idea for a solution for shared environments. What if you can create multiple global environments, and attach them to Resources like Deployment, Stack? > > This way, you have preset variables / values that you can attach to multiple resources, and edit them all together. But also, maybe you have a different set of services, and those want to share different environment variables. So we can just have as many Global Environments as we want, and attach them to particular resources. > > And also, the global variables attached would be combined with any specific ones defined on the resource. Specific ones on the resources would have priority in the case of any variable collisions. That sounds awesome. I would also add the ability to attach them to servers, that way if you have a variable called $FILE_PATH, their values would be different across two servers but all deployments/stacks that use it would just use the one variable name and would have the correct value for the server they're deployed on.

GiteaMirror commented

2026-05-12 20:43:58 -05:00

@mbecker20 commented on GitHub (Aug 13, 2024):

Just so we are at the same starting point -- I built environment variable management feature into stacks. On the stack config page, you can go to environment tab and input the variables there. When the stack is deployed, those values will be written locally and passed to compose with --env-file flag (docker compose feature).

Doing it this way has portability benefit -- the stack doesn't rely on anything on a particular host to deploy, meaning it can be easily moved between servers if needed.

Did you know about this way for env management / is there a reason this doesn't work for you? I know you can't "share" the environment like this currently, which is why I propose this shared environment feature.

@mbecker20 commented on GitHub (Aug 13, 2024): Just so we are at the same starting point -- I built environment variable management feature into stacks. On the stack config page, you can go to environment tab and input the variables there. When the stack is deployed, those values will be written locally and passed to compose with --env-file flag (docker compose feature). Doing it this way has portability benefit -- the stack doesn't rely on anything on a particular host to deploy, meaning it can be easily moved between servers if needed. Did you know about this way for env management / is there a reason this doesn't work for you? I know you can't "share" the environment like this currently, which is why I propose this shared environment feature.

GiteaMirror commented

2026-05-12 20:43:59 -05:00

@C0untZero commented on GitHub (Aug 13, 2024):

I did know, yes. What I wanted to reuse, and what OMV has as a feature (where I'm migrating my compose stacks from) is the global env file mentioned. The future is documented in this docker_compose plugin https://wiki.omv-extras.org/doku.php?id=omv7:omv7_plugins:docker_compose#edit_global_environment_file

One possible use case for this is for linuxserver.io images, where they have common environment variables in all of their images like PUID, PGID, and TZ (being process user id, process group id, and timezone respectively). Usually when I'm deploying these stacks on a server, these values are all the same across stacks so I would put them all in the OMV global environment file and just reference them throughout all compose files.

I can appreciate the portability benefit, and there are cases where this is great.
But there are also cases where I need to be environment/server specific. When I'm deploying the arr suite for example, I need to reference the download folder in the compose files. The download folder is a different /srv/dev between different servers, so the compose file expects the ${DRIVE_PATH} var value or something, with each server handling the var value for itself.

Having this feature would allow us to only have to define these stack shared variables once, instead of doing it for each stack individually and then having to update each stack on a var change.
I know this can easily be done by replace all in the toml resource files, but it would also be nice if we had a way to do it through the UI.

@C0untZero commented on GitHub (Aug 13, 2024): I did know, yes. What I wanted to reuse, and what OMV has as a feature (where I'm migrating my compose stacks from) is the global env file mentioned. The future is documented in this docker_compose plugin https://wiki.omv-extras.org/doku.php?id=omv7:omv7_plugins:docker_compose#edit_global_environment_file One possible use case for this is for linuxserver.io images, where they have common environment variables in all of their images like PUID, PGID, and TZ (being process user id, process group id, and timezone respectively). Usually when I'm deploying these stacks on a server, these values are all the same across stacks so I would put them all in the OMV global environment file and just reference them throughout all compose files. I can appreciate the portability benefit, and there are cases where this is great. But there are also cases where I need to be environment/server specific. When I'm deploying the arr suite for example, I need to reference the download folder in the compose files. The download folder is a different /srv/dev between different servers, so the compose file expects the ${DRIVE_PATH} var value or something, with each server handling the var value for itself. Having this feature would allow us to only have to define these stack shared variables once, instead of doing it for each stack individually and then having to update each stack on a var change. I know this can easily be done by replace all in the toml resource files, but it would also be nice if we had a way to do it through the UI.

GiteaMirror commented

2026-05-12 20:44:00 -05:00

@mbecker20 commented on GitHub (Aug 13, 2024):

What I propose is Global Environments, defined in UI, that each can be attached to multiple resources. I get that some stacks will share environment variables -- can just make a single Global environment in UI with all the shared variables, and attach it to all the relevant stacks. And each stack can extend the global list with any needed variables defined in its "specific" environment.

@mbecker20 commented on GitHub (Aug 13, 2024): What I propose is Global Environments, defined in UI, that each can be attached to multiple resources. I get that some stacks will share environment variables -- can just make a single Global environment in UI with all the shared variables, and attach it to all the relevant stacks. And each stack can extend the global list with any needed variables defined in its "specific" environment.

GiteaMirror commented

2026-05-12 20:44:01 -05:00

@mbecker20 commented on GitHub (Aug 13, 2024):

"Usually when I'm deploying these stacks on a server, these values are all the same across stacks so I would put them all in the OMV global environment file and just reference them throughout all compose files."

It will work the same as this in the end. Just put all global variable in global environment (in UI) and attach the global environment to the stacks. You will be able to reference them in compose file like PUID=${PUID} as expected.

@mbecker20 commented on GitHub (Aug 13, 2024): "Usually when I'm deploying these stacks on a server, these values are all the same across stacks so I would put them all in the OMV global environment file and just reference them throughout all compose files." It will work the same as this in the end. Just put all global variable in global environment (in UI) and attach the global environment to the stacks. You will be able to reference them in compose file like PUID=${PUID} as expected.

GiteaMirror commented

2026-05-12 20:44:04 -05:00

@C0untZero commented on GitHub (Aug 13, 2024):

That would be an elegant solution yes, and a great improvement in itself already.

I would just additionally suggest to also allow linking these global environments to servers as well - that way one variable name can be referenced in the stacks, while each server would have its unique value.
This would allow easily changing the server where a stack is deployed without any additional configuration.

But I also understand if you don't want to complicate it, and I would be more than happy to just linking these global envs to stacks and deployments :)

@C0untZero commented on GitHub (Aug 13, 2024): That would be an elegant solution yes, and a great improvement in itself already. I would just additionally suggest to also allow linking these global environments to servers as well - that way one variable name can be referenced in the stacks, while each server would have its unique value. This would allow easily changing the server where a stack is deployed without any additional configuration. But I also understand if you don't want to complicate it, and I would be more than happy to just linking these global envs to stacks and deployments :)

GiteaMirror commented

2026-05-12 20:44:04 -05:00

@mbecker20 commented on GitHub (Aug 13, 2024):

Linking them to servers is a good idea.

The application of env vars to stacks / deployments would be as follows:

Apply any Global Environments linked to Server that the Stack is deployed on.
Apply any Global Environments linked directly to the Stack
Apply any specific variables defined on directly the Stack Environment

I think this should elegantly fulfill the requirements. Thanks for the suggestion!

@mbecker20 commented on GitHub (Aug 13, 2024): Linking them to servers is a good idea. The application of env vars to stacks / deployments would be as follows: 1. Apply any Global Environments linked to Server that the Stack is deployed on. 2. Apply any Global Environments linked directly to the Stack 3. Apply any specific variables defined on directly the Stack Environment I think this should elegantly fulfill the requirements. Thanks for the suggestion!

GiteaMirror commented

2026-05-12 20:44:05 -05:00

@C0untZero commented on GitHub (Aug 13, 2024):

Sounds perfect - thanks for accepting, looking forward to it.

@C0untZero commented on GitHub (Aug 13, 2024): Sounds perfect - thanks for accepting, looking forward to it.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#10545