fix(manage-server): pass TRITON_MANAGE_DISABLE_TLS through to the container #13

Merged

amiryahaya merged 1 commit from fix-manageserver-disable-tls-passthrough into main

2026-08-09 04:49:07 +02:00

amiryahaya commented

2026-08-06 17:31:45 +02:00

Owner

Summary

Sync from the triton source-of-truth repo's scripts/deploy/manage-server/compose.yaml fix — this is the distribution copy served via curl | bash, and CLAUDE.md's dual-maintenance rule requires keeping them in sync.

env.template defines TRITON_MANAGE_DISABLE_TLS and install.sh --no-tls correctly writes TRITON_MANAGE_DISABLE_TLS=true into .env, but compose.yaml's manage-server service never referenced ${TRITON_MANAGE_DISABLE_TLS} in its environment: block — the value silently never reached the container, which fell back to its Go zero-value (DisableTLS=false).

Symptom: after completing the setup wizard, the server's own auto-TLS-restart logic (scheduleTLSRestart) checks DisableTLS, sees it false, and restarts to auto-generate a self-signed cert and switch the admin listener to HTTPS — exactly what --no-tls was supposed to prevent. Any reverse proxy (Caddy, nginx) configured to proxy plain HTTP per --no-tls's own documented contract then gets 400/"client sent an HTTP request to an HTTPS server" from what is now a TLS-only backend.

Test plan

Reproduced and fixed live against a real --no-tls install behind Caddy: before the fix, plain HTTP to the admin listener returned 400; after adding the env var and recreating the container, the server logged "WARNING: TLS is not configured on admin listener (TRITON_MANAGE_DISABLE_TLS=true); running plain HTTP" and the site was reachable again with no further restart.
Matches the fix already applied to scripts/deploy/manage-server/compose.yaml in the triton repo (source of truth).

## Summary Sync from the `triton` source-of-truth repo's `scripts/deploy/manage-server/compose.yaml` fix — this is the distribution copy served via `curl | bash`, and CLAUDE.md's dual-maintenance rule requires keeping them in sync. `env.template` defines `TRITON_MANAGE_DISABLE_TLS` and `install.sh --no-tls` correctly writes `TRITON_MANAGE_DISABLE_TLS=true` into `.env`, but `compose.yaml`'s `manage-server` service never referenced `${TRITON_MANAGE_DISABLE_TLS}` in its `environment:` block — the value silently never reached the container, which fell back to its Go zero-value (`DisableTLS=false`). **Symptom:** after completing the setup wizard, the server's own auto-TLS-restart logic (`scheduleTLSRestart`) checks `DisableTLS`, sees it false, and restarts to auto-generate a self-signed cert and switch the admin listener to HTTPS — exactly what `--no-tls` was supposed to prevent. Any reverse proxy (Caddy, nginx) configured to proxy plain HTTP per `--no-tls`'s own documented contract then gets `400`/"client sent an HTTP request to an HTTPS server" from what is now a TLS-only backend. ## Test plan - [x] Reproduced and fixed live against a real `--no-tls` install behind Caddy: before the fix, plain HTTP to the admin listener returned `400`; after adding the env var and recreating the container, the server logged `"WARNING: TLS is not configured on admin listener (TRITON_MANAGE_DISABLE_TLS=true); running plain HTTP"` and the site was reachable again with no further restart. - [x] Matches the fix already applied to `scripts/deploy/manage-server/compose.yaml` in the `triton` repo (source of truth).

amiryahaya added 1 commit

2026-08-06 17:31:45 +02:00

fix(manage-server): pass TRITON_MANAGE_DISABLE_TLS through to the container 6f16a0440b

Sync from triton source of truth (scripts/deploy/manage-server/compose.yaml).
env.template defines TRITON_MANAGE_DISABLE_TLS and install.sh --no-tls
correctly writes it into .env, but compose.yaml's manage-server service
never referenced it in its environment: block, so the value silently
never reached the container.

Symptom: after completing the setup wizard, the server's own
auto-TLS-restart logic sees DisableTLS=false (its Go zero-value, since the
env var never arrived) and restarts to switch the admin listener to a
self-signed HTTPS cert -- exactly what --no-tls was supposed to prevent.
Any reverse proxy configured to proxy plain HTTP per --no-tls's own
contract then gets rejected by the now-TLS-only backend.

Reproduced and fixed live against a --no-tls install behind Caddy.

amiryahaya merged commit 220820713c into main

2026-08-09 04:49:07 +02:00

amiryahaya referenced this pull request from a commit

2026-08-09 04:49:08 +02:00

Merge pull request 'fix(manage-server): pass TRITON_MANAGE_DISABLE_TLS through to the container' (#13) from fix-manageserver-disable-tls-passthrough into main