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.
This was asked and answered but it seems DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com is required not just the alias as in DISCOURSE_HOSTNAME_ALIASES: other.domain.com
Can someone confirm please?
Also, it looks the PR by @pfaffman was not merged so the sample templates need a manual change, yes?
No. The example is confusing. Only EXTRA names need to be in DISCOURSE_HOSTNAME_ALIASES.
You don’t need DISCOURSE_HOSTNAME_ALIASES at all unless you need your site to have a certificate for another name (like yesterday when I moved someone from forum.example.com to fancyword.example.com.
So I did
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: forum.example.com
And backed up the forum before making the changes, made the changes, rebuilt, restored the backup (the restorer handles fixing up the hostname refences) and now if you go to forum.example.com you get a valid cert and redirected to the new subdomain.
Yes, it looks like no one noticed the PR. I always have to go looking for this. Sure, DISCOURSE_HOSTNAME_ALIASES is “obvious” but only when I’m looking at it. 
Thank you for that @pfaffman
In my case I need this to make AWS CDN and AWS S3 CDN work properly with caching
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
Creating multiple certs is exactly what we needed/ Unfortunately we hammered the account with certbot way too many time yesterday so it is time jail for that site. Going to try with a different site now that you have confirmed proper use of DISCOURSE_HOSTNAME_ALIASES
Then you need to do that at AWS.
If you add another alias then it’ll let you request a new one (unless you did something to get the whole domain blocked)
Looks like this may not be needed after all. Caching seem to be working. I will update with details at Issues with AWS CDN and S3