Вряд ли. Это тот случай, когда вы, скорее всего, сделаете это ровно один раз, и сделаете это, когда уже будете возиться с app.yml.
Однако я посмотрю возможность создания PR, который добавит это в standalone.yml.
И с этим в наличии всё становится гораздо проще!
Спасибо за это! Я локально модифицировал templates/web.letsencrypt.ssl.template.yml, но это значительно упростило мне жизнь!
Нужно ли включать в это (основное) имя хоста или только алиасы?
Только алиасы. Имя хоста — это имя хоста.
Значит, так?
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
Вступая в философский спор о значении слова «алиас», я указал оба URL-адреса, которые должны вести на мой сайт: nzarchitecure.net.nz и www.nzarchitecture.net.nz, без каких-либо очевидных негативных последствий (и, предположительно, без какой-либо пользы).
Может ли файл standalone.yml быть изменён или запрошен для чтения настроек администратора в работающем экземпляре Discourse?
Если да, это стало бы большой помощью для новых пользователей и тех, кто планирует перенос доменов или добавление алиасов — одна головная боль при исследовании и устранении неполадок меньше.
Нет. Было бы очень плохо, если бы задачи, выполняющиеся в контейнере, могли изменять такие файлы, как app.yml. На самом деле, хорошей практикой безопасности является размещение таких данных, как ключи S3, в yml-файле, чтобы они были скрыты от интерфейса Discourse.
Опять же, изменения вроде настройки перенаправления доменов крайне редки, и они требуют других действий, например, настройки DNS. Время для этого — этап установки Discourse, и когда вы устанавливаете Discourse, вы как раз работаете с yml-файлом.
Этот вопрос уже задавали и на него отвечали, но, похоже, требуется не просто алиас в виде DISCOURSE_HOSTNAME_ALIASES: other.domain.com, а полное значение DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com.
Может ли кто-нибудь это подтвердить?
Также похоже, что PR от @pfaffman не был принят, поэтому в образцы шаблонов нужно внести изменения вручную, верно?
Нет. Пример запутывает. В DISCOURSE_HOSTNAME_ALIASES нужно указывать только дополнительные имена.
Вам вообще не нужен DISCOURSE_HOSTNAME_ALIASES, если только вашему сайту не требуется сертификат для другого имени (как вчера, когда я перенёс кого-то с forum.example.com на fancyword.example.com).
Так что я сделал:
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: forum.example.com
Перед внесением изменений я сделал резервную копию форума, внёс изменения, пересобрал, восстановил резервную копию (инструмент восстановления сам исправляет ссылки на хостнейм), и теперь, если перейти на forum.example.com, вы получите валидный сертификат и будете перенаправлены на новый поддомен.
Да, похоже, никто не заметил этот PR. Мне всегда приходится искать эту информацию. Конечно, DISCOURSE_HOSTNAME_ALIASES «очевиден», но только когда я сам на него смотрю. 
Спасибо вам, @pfaffman.
В моём случае это необходимо для корректной работы кэширования с AWS CDN и AWS S3 CDN:
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
Создание нескольких сертификатов — именно то, что нам было нужно. К сожалению, вчера мы слишком часто обращались к аккаунту через certbot, поэтому сайт попал в временную блокировку. Сейчас попробую с другим сайтом, теперь, когда вы подтвердили правильное использование DISCOURSE_HOSTNAME_ALIASES.
Тогда вам нужно настроить это в AWS.
Если вы добавите ещё один псевдоним, система позволит запросить новый сертификат (если только вы не сделали чего-то, что привело к полной блокировке домена).
Похоже, что это может и не потребоваться. Кэширование, кажется, работает. Я обновлю информацию с деталями по адресу Issues with AWS CDN and S3