reivilibre
commented
1 year ago I think this is unlikely to be considered, because we have intentionally moved away from this in the past.
Other than the PostgreSQL configuration, a homeserver configuration still needs various secrets (macaroon key, registration shared secret, TURN configuration, a signing key), a server name and quite often many more tweaks too. It's not wrong to wish that this was all configurable from the env alone, but on the other hand it makes it harder for us to provide support, because people will be using this other way of configuration and asking questions so we'll have more things we need to think about when helping people (a task that is already quite time-intensive already!). I don't particularly remember #5518 but I imagine this is the sort of thought process that went into it for why we decided to give up on this method of configuration.
I'm aware of #5518, but that issue focuses on configurability and complex use cases. For basic setups users won't need power via environment variables, they'll just care about safe-by-default, easy deploys.
By having environment variables to connect to a database (user, password, database), simple use cases won't need touching a homeserver.yaml config file at all, just relying on orchestration tools. Named volumes that are not directly exposed to the filesystem become a possibility. And by making it easier to use PostgreSQL, less users will be using SQLite, which is explicitly not recommended by the Synapse docs.