Not likely. It’s the kind of thing that you’re likely to do exactly once, and you’ll do it when you’re already mucking with app.yml.
I’ll see about making a PR that adds it to the standalone.yml, though.
And with this in place, this is much simpler!
thanks for this, i have been locally modifying templates/web.letsencrypt.ssl.template.yml but this makes my life so much easier!
Do we need to include the (OG) hostname in this, or just the aliases?
Just the aliases. The hostname is the hostname.
So like this then?
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
Wrestling philosophically with the meaning of ‘alias’, I included both urls that I want to lead to my site: nzarchitecure.net.nz and www.nzarchitecture.net.nz with no obvious ill effects (& presumably no benefit either).
Can standalone.yml be altered by or tasked to read administrator settings within a running instance of Discourse?
If so that would be a real help to new users and those looking to migrate domains or add aliases - one less headache to research and troubleshoot.
No. It would be really bad if the jobs running in the container could change things like app.yml. Actually, a good security practice is to put stuff like S3 keys in the yml file so that they are hidden from the Discourse interface.
Again, it’s very rare that you make changes like what domains need to be redirected, and they require other things, like DNS settings. The time to do it is when you set up Discourse, and when you set up Discourse, you’re mucking with the yml file.