diff --git a/apps/gitlab/values.yaml b/apps/gitlab/values.yaml
index a76c3bc..e105c91 100644
--- a/apps/gitlab/values.yaml
+++ b/apps/gitlab/values.yaml
@@ -77,13 +77,26 @@ global:
   # already proven for Postgres and Gitaly's own node addresses: home's
   # 3 Gitaly nodes resolve this locally (no WAN round-trip), the VPS's
   # 4th node resolves it via the UniFi WAN forward - one consistent
-  # https:// URL for every node regardless of site, rather than trying
-  # to TLS-certify an unpublishable *.svc.cluster.local name (which
-  # Let's Encrypt fundamentally can't issue for).
+  # URL for every node regardless of site.
+  #
+  # tls.enabled REVERTED 2026-08-22 - broke the live site (HTTP 400
+  # "Client sent an HTTP request to an HTTPS server" on
+  # gitlab.kube.huskypup.net). Root cause: port 8181 is NOT internal-API
+  # -only - confirmed live via `kubectl get httproute gitlab-web` that
+  # ALL public traffic (gitlab.kube.huskypup.net, routed through Envoy/
+  # Istio edge gateway) also targets gitlab-webservice-default:8181.
+  # global.workhorse.tls.enabled replaces the plaintext listener with
+  # TLS on that SAME port chart-wide, for both the public site AND the
+  # internal API - there's no chart-native way to TLS one without the
+  # other. Envoy terminates public HTTPS and proxies to the pod in
+  # plaintext, so a TLS-only pod listener 400s every public request.
+  # host: left in place (harmless without tls.enabled - only used for
+  # the [gitlab] url string, not port selection). Internal-API-over-WAN
+  # transport security for the VPS's future Gitaly node needs a
+  # different mechanism (e.g. network-layer TLS/mTLS via Istio, or a
+  # second dedicated port if the chart ever adds one) - not solved here.
   workhorse:
     host: gitlab-internal-api.ha.huskypup.net
-    tls:
-      enabled: true
 
   # Praefect configuration
   praefect: