Which Let’s Encrypt variable name is correct in app.yml?

Product Support Self-hosting
2

Thanks for the replies so far — I’ve investigated a bit more and want to check that I’ve understood this correctly.

My install was originally created with ./discourse-setup, which added

LETSENCRYPT_ACCOUNT_EMAIL: myemail@example.com

under env: in app.yml.

Let’s Encrypt has been issuing and renewing certificates successfully ever since, and the current web.letsencrypt.ssl.template.yml still appears to use LETSENCRYPT_ACCOUNT_EMAIL as the env var it relies on. During a fresh test install today I saw the usual bootstrap output:

I, [2025-12-07T12:29:22.272059 #1]  INFO -- : Replacing # after ssl with if [ -n "$LETSENCRYPT_ACCOUNT_EMAIL" ]; then
  if [[ ! "$LETSENCRYPT_ACCOUNT_EMAIL" =~ ([^@]+)@([^\.]+) ]]; then
    echo "LETSENCRYPT_ACCOUNT_EMAIL is not a valid email address"
    exit 1
  fi
  /usr/local/bin/configure-ssl
  exec /usr/local/bin/configure-letsencrypt
else
  echo "LETSENCRYPT_ACCOUNT_EMAIL ENV not set. Skipping Let's Encrypt setup."
fi
# after ssl in /etc/runit/1.d/install-ssl

which matches what’s in the template.

However, when I run ./launcher rebuild app I now see a warning along the lines of “Let’s Encrypt email not set”. From reading the launcher and related docs, that seems to come from a newer configuration check that looks for a letsencrypt_email key in the merged config, rather than the older LETSENCRYPT_ACCOUNT_EMAIL env var.

So I think the current situation is:

  1. The Docker Let’s Encrypt template still uses LETSENCRYPT_ACCOUNT_EMAIL as the env var that drives acme.sh and renewal.
  2. Some newer checks (e.g. the one that prints “Let’s Encrypt email not set”) only look for letsencrypt_email in the config.
  3. That would explain why cert issuance/renewal works fine while the rebuild still prints a warning.

A couple of clarifications I’d love to get from the team:

  1. For standard ./discourse-setup installs, is LETSENCRYPT_ACCOUNT_EMAIL still the intended variable name in app.yml, or should we now be using letsencrypt_email instead?
  2. Is LETSENCRYPT_ACCOUNT_EMAIL considered legacy-but-supported at this point, or is there a plan to migrate the templates to a new key?
  3. For existing installs that currently use LETSENCRYPT_ACCOUNT_EMAIL and have working renewals, is the recommended approach:
    • (a) do nothing and safely ignore the launcher warning, or
    • (b) add a letsencrypt_email: entry to env: (with the same address) purely to satisfy the newer check?

I’m mainly trying to keep the config aligned with whatever the “official” direction is, and to avoid surprises if the Let’s Encrypt integration is refactored in future.

Thanks again for the guidance, and for confirming what’s expected here.