QA_SMTP_HOST, QA_SMTP_PORT and QA_SMTP_SECURE are set on the stack but nothing reads them #258

New Issue

2026-09-01T11:46:30-05:00

bermudalamb commented

2026-09-01 11:46:30 -05:00

Three stack variables are set on the QA stack that the compose file never references:

QA_SMTP_HOST
QA_SMTP_PORT
QA_SMTP_SECURE

docker-compose.qa.yml hardcoded all three (smtp-relay.brevo.com, 587, false), so setting them in Portainer had no effect and nothing said so. The credentials beside them — QA_SMTP_USER, QA_SMTP_PASSWORD, QA_SMTP_FROM — do interpolate, which makes the inert three easy to mistake for working configuration.

Fixed by interpolating them like the rest, each keeping its Brevo value as a default:

- SMTP_HOST=${QA_SMTP_HOST:-smtp-relay.brevo.com}
- SMTP_PORT=${QA_SMTP_PORT:-587}
- SMTP_SECURE=${QA_SMTP_SECURE:-false}

The defaults matter. The mailer's own fallbacks are Gmail's — smtp.gmail.com, 465, implicit TLS — and Brevo is STARTTLS on 587. Interpolating with no default would mean an unset variable silently aims QA at Gmail and fails at send time rather than at boot, which is the exact failure the original hardcoding was there to prevent. :- applies only when the variable is unset or empty, so setting one still wins.

Verified with docker compose config in both directions, and the #107 compose guard still passes.

Production is left alone. It hardcodes the same three, nobody has asked to vary them there, and a needless change to the production stack is not worth the deploy. Worth revisiting only if QA and production configuration drifting apart becomes a problem.

Three stack variables are set on the QA stack that the compose file never references: - `QA_SMTP_HOST` - `QA_SMTP_PORT` - `QA_SMTP_SECURE` `docker-compose.qa.yml` hardcoded all three (`smtp-relay.brevo.com`, `587`, `false`), so setting them in Portainer had no effect and nothing said so. The credentials beside them — `QA_SMTP_USER`, `QA_SMTP_PASSWORD`, `QA_SMTP_FROM` — do interpolate, which makes the inert three easy to mistake for working configuration. Fixed by interpolating them like the rest, each keeping its Brevo value as a default: ```yaml - SMTP_HOST=${QA_SMTP_HOST:-smtp-relay.brevo.com} - SMTP_PORT=${QA_SMTP_PORT:-587} - SMTP_SECURE=${QA_SMTP_SECURE:-false} ``` The defaults matter. The mailer's own fallbacks are Gmail's — `smtp.gmail.com`, 465, implicit TLS — and Brevo is STARTTLS on 587. Interpolating with no default would mean an unset variable silently aims QA at Gmail and fails at send time rather than at boot, which is the exact failure the original hardcoding was there to prevent. `:-` applies only when the variable is unset or empty, so setting one still wins. Verified with `docker compose config` in both directions, and the #107 compose guard still passes. Production is left alone. It hardcodes the same three, nobody has asked to vary them there, and a needless change to the production stack is not worth the deploy. Worth revisiting only if QA and production configuration drifting apart becomes a problem.

bermudalamb referenced this issue from a commit

2026-09-01 11:49:13 -05:00

build(qa): take the SMTP host, port and TLS flag from QA_ stack variables (#258)

bermudalamb referenced a pull request that will close this issue

2026-09-01 11:50:58 -05:00

build(qa): take the SMTP host, port and TLS flag from QA_ stack variables (#258) #259

bermudalamb closed this issue

2026-09-01 11:51:15 -05:00

bermudalamb referenced this issue from a commit

2026-09-01 11:51:16 -05:00

Merge pull request 'build(qa): take the SMTP host, port and TLS flag from QA_ stack variables (#258)' (#259) from chore/258-qa-smtp-stack-vars into main

Sign in to join this conversation.