Encryption

This guide covers the different encryption methods and considerations. It is assumed that you are familiar with the architecture of Langfuse.

Encryption in transit (HTTPS)

For encryption in transit, HTTPS is strongly recommended. Langfuse itself does not handle HTTPS directly. Instead, HTTPS is typically managed at the infrastructure level. There are two main approaches to handle HTTPS for Langfuse:

1. Load Balancer Termination: In this approach, HTTPS is terminated at the load balancer level. The load balancer handles the SSL/TLS certificates and encryption, then forwards the decrypted traffic to the Langfuse container over HTTP. This is a common and straightforward method, especially in cloud environments.

• Pros: Simplifies certificate management as it is usually a fully managed service (e.g. AWS ALB), offloads encryption overhead from application servers.
• Cons: Traffic between load balancer and Langfuse container is unencrypted (though typically within a secure network).

2. Service Mesh Sidecar: This method involves using a service mesh like Istio or Linkerd. A sidecar proxy is deployed alongside each Langfuse container, handling all network traffic including HTTPS.

• Pros: Provides end-to-end encryption (mutual TLS), offers advanced traffic management and observability.
• Cons: Adds complexity to the deployment, requires understanding of service mesh concepts.

Once HTTPS is enabled, you can configure add LANGFUSE_CSP_ENFORCE_HTTPS=true to ensure browser only allow HTTPS connections when using Langfuse.

Encryption at rest (database)

All Langfuse data is stored in your Postgres database, Clickhouse, Redis, or S3/Blob Store. Database-level encryption is recommended for a secure production deployment and available across cloud providers.

Additional application-level encryption

In addition to in-transit and at-rest encryption, sensitive data is also encrypted or hashed at the application level.