Não é provável. É o tipo de coisa que você provavelmente fará exatamente uma vez, e fará isso quando já estiver mexendo com o app.yml.
Vou ver se faço um PR que o adicione ao standalone.yml, embora.
E com isso implementado, isso é muito mais simples!
obrigado por isso, eu tenho modificado localmente templates/web.letsencrypt.ssl.template.yml, mas isso torna minha vida muito mais fácil!
Precisamos incluir o nome de host (OG) nisso, ou apenas os aliases?
Apenas os aliases. O nome do host é o nome do host.
Então, assim?
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
Refletindo filosoficamente sobre o significado de ‘alias’, incluí ambos os URLs que quero que levem ao meu site: nzarchitecure.net.nz e www.nzarchitecture.net.nz sem efeitos negativos óbvios (e presumivelmente nenhum benefício também).
O standalone.yml pode ser alterado ou configurado para ler as configurações do administrador em uma instância em execução do Discourse? Se sim, isso seria uma grande ajuda para novos usuários e para aqueles que buscam migrar domínios ou adicionar aliases - menos uma dor de cabeça para pesquisar e solucionar problemas.
Não. Seria muito ruim se os trabalhos em execução no contêiner pudessem alterar coisas como app.yml. Na verdade, uma boa prática de segurança é colocar coisas como chaves S3 no arquivo yml para que elas fiquem ocultas da interface do Discourse.
Novamente, é muito raro que você faça alterações como quais domínios precisam ser redirecionados, e eles exigem outras coisas, como configurações de DNS. A hora de fazer isso é quando você configura o Discourse, e quando você configura o Discourse, você mexe com o arquivo yml.
Isto foi perguntado e respondido, mas parece que DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com é necessário e não apenas o alias como em DISCOURSE_HOSTNAME_ALIASES: other.domain.com
Alguém pode confirmar, por favor?
Além disso, parece que o PR de @pfaffman não foi mesclado, então os modelos de exemplo precisam de uma alteração manual, certo?
Não. O exemplo é confuso. Apenas os nomes EXTRAS precisam estar em DISCOURSE_HOSTNAME_ALIASES.
Você não precisa de DISCOURSE_HOSTNAME_ALIASES a menos que precise que seu site tenha um certificado para outro nome (como ontem, quando mudei alguém de forum.example.com para fancyword.example.com.
Então eu fiz
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: forum.example.com
E fiz backup do fórum antes de fazer as alterações, fiz as alterações, reconstruí, restaurei o backup (o restaurador cuida de corrigir as referências de nome de host) e agora se você acessar forum.example.com você obtém um certificado válido e é redirecionado para o novo subdomínio.
Sim, parece que ninguém notou o PR. Eu sempre tenho que procurar por isso. Claro, DISCOURSE_HOSTNAME_ALIASES é “óbvio”, mas só quando estou olhando para ele. 
Obrigado por isso @pfaffman
No meu caso, preciso disso para fazer o AWS CDN e o AWS S3 CDN funcionarem corretamente com o cache
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
Criar múltiplos certificados é exatamente o que precisávamos/ Infelizmente, sobrecarregamos a conta com o certbot muitas vezes ontem, então é hora de prisão para aquele site. Vou tentar com um site diferente agora que você confirmou o uso correto de DISCOURSE_HOSTNAME_ALIASES
Então você precisa fazer isso na AWS.
Se você adicionar outro alias, isso permitirá que você solicite um novo (a menos que você tenha feito algo para bloquear o domínio inteiro)
Parece que isso pode não ser necessário, afinal. O cache parece estar funcionando. Vou atualizar com os detalhes em Issues with AWS CDN and S3