Support more complicated and individual ENV file setups

[terafirmanz]

⚠️ Please verify that this feature request has NOT been suggested before.

• I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature

🔖 Feature description

Support multiple ENV files and keeping them in a subfolder.

✔️ Solution

Edit for clarity - I am referring to managing the env files for the env_file part of a service in a compose file here not the ability to place variables in a compose file for interpolation of compose itself on startup

In larger stacks it is common to split the ENV files up into per-container ENV files. this ensures that conflicting variables can be managed and also that variables not required in one image are not passed to another. An example of this would be that Traefik should not know the credentials to login to my SQL backend.

The UI could detect compose files that reference separate ENV files and surface them in the UI this would mean that existing stacks would show up and for new stacks, the existing simple UI would remain and extra ENV file management would only show up if a user typed in a reference to another file.

❓ Alternatives

No response

📝 Additional Context

No response

[thatg33khub]

Hello,
I am trying to work the other way around, with a "master" .env file which is populated via a symlink into each individual stack. It allows you to have an overview of the used ports and also to share the same db container with different stacks if you want to.
But an .env management tool integrated in the GUI would be a nice plus indeed.

[syko9000]

Hello, I'm working on the global.env feature. Just for clarification about this, do you want the service level .env file to be involved in the interpolation of the compose file per service as it comes up? ie.

...
    volumes:
      - $CONFIG_DIRECTORY:/config

Or, just a UI to edit the files referenced and the variables only be passed to the containers via the env_file section?

Or, both?

[terafirmanz]

For me when talking about global ENV file and service level ones I would want that to be used for the interpolation of the compose file. I think container-level ENV files should be managed via the env_file section as this sticks to Dockers design.

[jruiz94]

Super great to hear that this is already on the works, I'm also waiting for a global env configuration to jump straight into dockge, this is the number one feature that drags me out of Portainer, having to copy and paste a bunch of environment variables on all stacks.

Would it be possible to get updates on the release date of this? Whenever it might be of course, no hurry at all :) you folks are doing a phenomenal job on this tool!

[frauseo]

Hope I'm not late to the party since the PR #387 was allredy accepted...
In version 1.5.0 i can configure my stack like this:

services:
  duckdns:
    ...
    env_file:
      - ./duckdns.env

and all my .service.env would stay untouched like so:

PUID=value
...
TOKEN=value