Hi, thank you for the PR, looks good so far. I'm not sure about how useful the .env file is as it effectively doubles the places where the options have to be changed to not override them, is there another benefit of having it? (besides changing an env file instead the compose file).
Also the dockerignore part seems to be not that useful?

I'm not sure about how useful the .env file is as it effectively doubles the places where the options have to be changed to not override them, is there another benefit of having it?

Yeah I also noticed that ... I will probably just move the env vars back into the docker-compose.yml .. Its just that I am currently stuck having some options set via env vars and some as a config change and I think only one of them at a time would be better / more consistent.

I mean that is probably a design decision, but we could also remove some of the currently existing env options and remove this line from the Dockerfile and say that creating a custom config is the way to go:

I would like more env vars, thats why I wrote the PR this way :D

Yeah I also noticed that ... I will probably just move the env vars back into the docker-compose.yml .. Its just that I am currently stuck having some options set via env vars and some as a config change and I think only one of them at a time would be better / more consistent.

Imho the only config in the compose file should be that one which needs to be changed to run there (so only mysql).

I mean that is probably a design decision, but we could also remove some of the currently existing env options and remove this line from the Dockerfile and say that creating a custom config is the way to go

Baking config files into the container never was and never will be a good idea and should be avoided so the line should remain (and config files linked to containers on start). Creating a config file should only be required if some 'less used / technicaly problematic (shirts and other arrays)' configs have to be changed).

I would like more env vars, thats why I wrote the PR this way :D

Thats definitely a good way, i agree -> more env vars are better!

The plan is that at some time in the future most of them can be changed using the webinterface and the other more or less dynamically replaced by env vars but thats another issue ^^

I should had used *requests changes ;)