I'd be wary of having Isso be configured from multiple places. For now, it already reads ISSO_SETTINGS to find its own config files.

Having too many possible scenarios of mixed configs and inputs creates an untenable situation for testing. A bug in the parsing of another env variable slipped completely under the radar for that reason, see #720

You'd also have to deal with which config source would take precedence and what to do with duplicates. Parsing env variables, which is untrusted input that potentially any user can set, also creates a bit of a security nightmare.

I'm doing to close this for now, unless you have a valid reason for this feature to be implemented.

1. Env vars allow people to check config files into version control. I would like to be able to do this, and specify secrets as needed via env vars.
2. Env vars are not less secure than reading files. Neither method provides security if the system is compromised. Only the user and root can see them, unlike files and directories which also need to be managed via permissions.
3. Env vars take priority over files typically. Just pick one and state it in the documentation. Allowing interpolation in the config file itself solves this issue.
4. "Parsing env variables, which is untrusted input that potentially any user can set" the vast majority of the computing world is completely unsecure, then. Just about every service that I use allows config setting via env vars.

Not allowing env vars doesn't provide any additional security if the system is compromised, and it makes it harder for system administration because I can't check the config into source control systems so I have to manage it by hand every time I (re)install isso (via docker, etc).

Having thought about this a bit, your arguments convince me.
Would you like to submit a PR that introduces such ways of configuring Isso?

Related: #763