> ## Documentation Index
> Fetch the complete documentation index at: https://lightdash-refactor-full-audit-reorg.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Secure Lightdash with HTTPS

> To run Lightdash in production it is highly recommended to secure it with HTTPS. This is usually done using your cloud provider's load balancer or ingress controller. Optionally you could use a proxy service like [nginx](https://www.nginx.com/) or [traefik](https://traefik.io).

## Configuration options for HTTPS

```yaml theme={null}
# values.yaml
configMap:
  # Ensures all Lightdash links use https
  SITE_URL: https://lightdash.mycompany.com

  # Only allow cookies to be sent over HTTPS
  SECURE_COOKIES: 'true'

  # (optional) allow http traffic behind a https enabled proxy
  TRUST_PROXY: 'true'

# Depending on your ingress implementation you may need to set the following
service:
  type: NodePort

# Example ingress controller configuration
ingress:
  enabled: true
  annotations: {}
  hosts:
    - host: lightdash.mycompany.com
      paths:
        - path: /*
          pathType: ImplementationSpecific
  tls:
    - hosts:
        - lightdash.mycompany.com
      secretName: lightdash-tls
```

## SECURE\_COOKIES and TRUST\_PROXY

Both default to `false`. A production instance behind a TLS-terminating load balancer or ingress needs both set to `"true"`:

* `SECURE_COOKIES: "true"` tells Lightdash to only send its session cookies over HTTPS. Lightdash uses cookies to keep users signed in, so this keeps sessions from traveling over plain HTTP.
* `TRUST_PROXY: "true"` tells Lightdash to trust the `X-Forwarded-Proto` header from your proxy. When TLS terminates at the load balancer, requests reach Lightdash over HTTP with that header set — without `TRUST_PROXY`, Lightdash treats the request as insecure and refuses to set secure cookies.

Set both together: `SECURE_COOKIES` without `TRUST_PROXY` behind a terminating proxy locks users out. Changing `SITE_URL` later means reconfiguring every OAuth integration, so set the final `https://` URL before first boot.

## Load balancer and networking

Match what Lightdash Cloud configures at the load balancer:

* **Redirect HTTP → HTTPS**, minimum **TLS 1.2**.
* **Backend/LB timeout ≥ 300s** — long-running exports and queries are killed by the common 30–60s defaults.
* **Health check** on `GET /api/v1/health`.
* Request body size limit at the ingress ≥ your `LIGHTDASH_MAX_PAYLOAD` (dbt manifests for large projects are tens of MB).
* Optional: IP allowlisting, WAF, or rate limiting at the load balancer.
* On GKE, the chart can create a `BackendConfig` (`backendConfig.create: true`, `backendConfig.spec`) to attach timeouts, CDN, and Cloud Armor policies — this is how they're configured on Lightdash Cloud.

If backend pods can't reach `SITE_URL` from inside the cluster (hairpin/NAT), set `INTERNAL_LIGHTDASH_HOST` to the in-cluster service URL — the headless browser and internal calls use it.