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!
bedankt hiervoor, ik heb lokaal templates/web.letsencrypt.ssl.template.yml aangepast, maar dit maakt mijn leven zoveel gemakkelijker!
Do we need to include the (OG) hostname in this, or just the aliases?
Alleen de aliassen. De hostnaam is de hostnaam.
Dus zo dan?
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).
Kan standalone.yml worden gewijzigd door of opgedragen worden om beheerdersinstellingen te lezen binnen een draaiende instantie van Discourse?
Zo ja, dan zou dat een grote hulp zijn voor nieuwe gebruikers en degenen die domeinen willen migreren of aliassen willen toevoegen - één zorg minder om te onderzoeken en op te lossen.
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