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

Product Support Self-hosting

AI-generated summary

In a discussion about Let’s Encrypt configuration in Discourse’s app.yml, Ethsim2 reports seeing a warning “Let’s Encrypt email not set” despite having LETSENCRYPT_ACCOUNT_EMAIL defined. They ask whether this variable is legacy and if the modern replacement is letsencrypt_email. In a follow-up post, Ethsim2 confirms that the Docker template still uses LETSENCRYPT_ACCOUNT_EMAIL for actual certificate issuance and renewal via acme.sh, but newer launcher checks (e.g., during ./launcher rebuild app) now look for letsencrypt_email in the config, causing the warning. They seek clarification from the team on whether: (1) LETSENCRYPT_ACCOUNT_EMAIL remains the official variable for ./discourse-setup installs, (2) it’s considered legacy-but-supported, and (3) existing users should ignore the warning or add letsencrypt_email to suppress it. pfaffman notes that Let’s Encrypt no longer sends expiration emails, implying the email field may be less critical — though this doesn’t resolve the config inconsistency. The core issue is a mismatch between legacy env var usage and newer config validation logic, with users advised to align with official guidance to avoid future breakage.

1

Hi all,

During a rebuild I saw the warning:

“Let’s Encrypt email not set”

But in my app.yml I already have this line:

LETSENCRYPT_ACCOUNT_EMAIL: myemail@example.com

My certificate is valid and issuing is skipped. The launcher prints the correct warning.

Before I update anything, can someone confirm:

  • Is LETSENCRYPT_ACCOUNT_EMAIL an old/legacy variable?

  • Is the correct modern variable name now:

letsencrypt_email:

Should I remove the old variable and switch to the new one to avoid warnings and ensure auto-renew works?

Thanks!

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.

3

I’m pretty sure that it does not matter. Let’s encrypt doesn’t send notifications anymore.