ingress.appHost drives both WEB_URL and CORS_ALLOWED_ORIGINS, which breaks with externally terminating HTTPS

[gammaray-co]

Summary

ingress.appHost is overloaded to drive WEB_URL and CORS_ALLOWED_ORIGINS, but neither the hostname value nor these downstream env vars can correctly express an HTTPS scheme. For deployments where TLS is terminated externally (at a reverse proxy or ingress controller, not by the chart's own ingress: templates — e.g. when ingress.enabled: false and a hand-written Ingress is used, per the README's "Custom Ingress Routes" pattern), this leaves WEB_URL permanently wrong with no way to fix it via values.

Environment: K3s, Traefik ingress controller, cert-manager-issued TLS terminated at a hand-written Ingress (chart's own ingress: templates disabled).

---

Problem 1: WEB_URL is hardcoded to http://, with no override

File: charts/plane-ce/templates/config-secrets/app-env.yaml

WEB_URL: "http://{{ .Values.ingress.appHost }}"

This is a literal http:// prefix with no conditional and no values-level override anywhere in the chart — confirmed via helm show values and a full-text search (grep -rn WEB_URL) of the untarred chart source. There is no env.web_url or equivalent key.

Impact: any deployment terminating TLS externally ends up with WEB_URL reporting the wrong scheme, with no values-based way to correct it. This will affect anything reading WEB_URL to construct absolute links (emails, webhooks, OAuth callback URLs, etc.).

---

Problem 2: ingress.appHost can't express a scheme, and prefixing one breaks the value

We tried working around Problem 1 by setting ingress.appHost: "https://plane.example.com" directly. This breaks, because appHost is treated as a bare hostname everywhere else it's consumed (e.g. the CORS_ALLOWED_ORIGINS template), so the value gets double-prefixed:

WEB_URL: "http://https://plane.example.com"
CORS_ALLOWED_ORIGINS: "http://https://plane.example.com,https://https://plane.example.com"

Confirmed via helm template ... --set ingress.appHost=https://TRACER-TEST-VALUE.

---

Suggested fix

Add a dedicated values key (e.g. env.web_url) that, if set, overrides the derived WEB_URL value outright; otherwise fall back to the current http://{{ .Values.ingress.appHost }} behavior for backward compatibility. This sidesteps trying to make appHost itself scheme-aware, which — as shown in Problem 2 — doesn't compose cleanly with how appHost is used elsewhere in the chart.

A user would set it the same way as any other env.* key (e.g. secret_key, cors_allowed_origins), either via --set:

helm upgrade -i plane-app makeplane/plane-ce \
  --set ingress.appHost=plane.example.com \
  --set env.web_url=https://plane.example.com \
  -f values.yaml

or in values.yaml:

ingress:
  appHost: plane.example.com

env:
  web_url: https://plane.example.com

Suggested implementation

values.yaml — add alongside the existing env: defaults:

env:
  web_url: ""   # if set, overrides the derived WEB_URL below

templates/config-secrets/app-env.yaml — change:

WEB_URL: "http://{{ .Values.ingress.appHost }}"

to something like:

WEB_URL: {{ .Values.env.web_url | default (printf "http://%s" .Values.ingress.appHost) | quote }}

Empty-by-default, so existing deployments not using the new key see no behavior change. Note we haven't verified this exact Helm template syntax against the actual chart — treat it as a starting suggestion for shape/approach, not a tested patch.

Happy to share our current workaround (a post-install kubectl patch on the rendered Secret plus a rollout-restart, since Secret changes don't trigger a rollout on their own) if useful for reference, though it's very much a workaround rather than something we'd suggest upstreaming as-is.