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

**URL:** https://meta.discourse.org/t/which-let-s-encrypt-variable-name-is-correct-in-app-yml/390620
**Category:** Self-hosting
**Tags:** letsencrypt
**Created:** [December 7, 2025, 9:21am UTC](https://meta.discourse.org/t/which-let-s-encrypt-variable-name-is-correct-in-app-yml/390620 "2025-12-07T09:21:07Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [December 7, 2025, 9:21am UTC](https://meta.discourse.org/t/which-let-s-encrypt-variable-name-is-correct-in-app-yml/390620/1 "2025-12-07T09:21:07Z")

</div>

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:

```plaintext
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:

```plaintext
letsencrypt_email:

```

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

Thanks!

---

<div class="post-metadata">

### Author: ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [December 7, 2025, 12:37pm UTC](https://meta.discourse.org/t/which-let-s-encrypt-variable-name-is-correct-in-app-yml/390620/2 "2025-12-07T12:37:42Z")

</div>

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:

```plaintext
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.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [December 7, 2025, 12:43pm UTC](https://meta.discourse.org/t/which-let-s-encrypt-variable-name-is-correct-in-app-yml/390620/3 "2025-12-07T12:43:56Z")

</div>

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

> **[Ending Support for Expiration Notification Emails](https://letsencrypt.org/2025/01/22/ending-expiration-emails)**
>
> Since its inception, Let’s Encrypt has been sending expiration notification emails to subscribers that have provided an email address to us. We will be ending this service on June 4, 2025. The decision to end this service is the result of the...

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [January 6, 2026, 12:44pm UTC](https://meta.discourse.org/t/which-let-s-encrypt-variable-name-is-correct-in-app-yml/390620/4 "2026-01-06T12:44:24Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
