Is your feature request related to a problem? Please describe.
The temporal CLI and every Temporal SDK (Go, Python, TypeScript, Java, .NET) share a standardized "environment configuration" convention for client connection settings, including TLS — TEMPORAL_ADDRESS, TEMPORAL_NAMESPACE, TEMPORAL_TLS, TEMPORAL_TLS_CLIENT_CERT_PATH, TEMPORAL_TLS_CLIENT_KEY_PATH, TEMPORAL_TLS_SERVER_CA_CERT_PATH, TEMPORAL_TLS_SERVER_NAME, TEMPORAL_TLS_DISABLE_HOST_VERIFICATION (see the CLI's option definitions: cliext/option-sets.yaml#L136-L179, and e.g. the Python SDK's temporalio.envconfig module).
ui-server's Docker config template (server/config/docker.yaml) uses an older, unrelated set of names for the same settings — TEMPORAL_TLS_CA, TEMPORAL_TLS_CERT, TEMPORAL_TLS_KEY (plus _DATA variants), TEMPORAL_TLS_ENABLE_HOST_VERIFICATION. It doesn't recognize the standard names at all, verified locally on temporalio/ui:2.52.0: garbage PEM data under the old names fails fast (Unable to load server CA certificate, proving they're read), the same garbage under the standard names is silently ignored (server starts clean, proving they're never read).
This means anyone deploying Temporal with mTLS across the CLI, SDKs, and the Web UI has to maintain two parallel sets of TLS env vars pointing at the same certificate files — mismatches produce no error, so it's easy to get wrong silently.
Describe the solution you'd like
Have ui-server's config loader also accept the standard envconfig names (TEMPORAL_TLS_CLIENT_CERT_PATH/_DATA, TEMPORAL_TLS_CLIENT_KEY_PATH/_DATA, TEMPORAL_TLS_SERVER_CA_CERT_PATH/_DATA, TEMPORAL_TLS_DISABLE_HOST_VERIFICATION) — ideally via the same shared envconfig implementation the SDKs and CLI already use — so one env block can configure the UI alongside every other client.
Describe alternatives you've considered
Keeping both sets of names indefinitely and documenting the mapping — works, but every deployment has to know about and maintain the duplication rather than it being handled once in ui-server itself.
Additional context
temporalio/ui 2.52.0 (also affects earlier versions using the same config scheme, and likely current main).
Is your feature request related to a problem? Please describe.
The
temporalCLI and every Temporal SDK (Go, Python, TypeScript, Java, .NET) share a standardized "environment configuration" convention for client connection settings, including TLS —TEMPORAL_ADDRESS,TEMPORAL_NAMESPACE,TEMPORAL_TLS,TEMPORAL_TLS_CLIENT_CERT_PATH,TEMPORAL_TLS_CLIENT_KEY_PATH,TEMPORAL_TLS_SERVER_CA_CERT_PATH,TEMPORAL_TLS_SERVER_NAME,TEMPORAL_TLS_DISABLE_HOST_VERIFICATION(see the CLI's option definitions:cliext/option-sets.yaml#L136-L179, and e.g. the Python SDK'stemporalio.envconfigmodule).ui-server's Docker config template (server/config/docker.yaml) uses an older, unrelated set of names for the same settings —TEMPORAL_TLS_CA,TEMPORAL_TLS_CERT,TEMPORAL_TLS_KEY(plus_DATAvariants),TEMPORAL_TLS_ENABLE_HOST_VERIFICATION. It doesn't recognize the standard names at all, verified locally ontemporalio/ui:2.52.0: garbage PEM data under the old names fails fast (Unable to load server CA certificate, proving they're read), the same garbage under the standard names is silently ignored (server starts clean, proving they're never read).This means anyone deploying Temporal with mTLS across the CLI, SDKs, and the Web UI has to maintain two parallel sets of TLS env vars pointing at the same certificate files — mismatches produce no error, so it's easy to get wrong silently.
Describe the solution you'd like
Have
ui-server's config loader also accept the standardenvconfignames (TEMPORAL_TLS_CLIENT_CERT_PATH/_DATA,TEMPORAL_TLS_CLIENT_KEY_PATH/_DATA,TEMPORAL_TLS_SERVER_CA_CERT_PATH/_DATA,TEMPORAL_TLS_DISABLE_HOST_VERIFICATION) — ideally via the same sharedenvconfigimplementation the SDKs and CLI already use — so one env block can configure the UI alongside every other client.Describe alternatives you've considered
Keeping both sets of names indefinitely and documenting the mapping — works, but every deployment has to know about and maintain the duplication rather than it being handled once in
ui-serveritself.Additional context
temporalio/ui2.52.0 (also affects earlier versions using the same config scheme, and likely currentmain).