Langfuse encryption in transit and at rest

Encryption in transit for a self-hosted Langfuse starts at the edge, not inside the application. Langfuse does not terminate HTTPS itself. Its self-hosting documentation describes TLS termination at a load balancer or at a service mesh sidecar such as Istio or Linkerd. Browsers and SDKs connect to that TLS endpoint over HTTPS, and the endpoint forwards the decrypted request to Langfuse Web, which serves the UI and the public APIs. Your first decision is which component owns the certificate, how it is issued and renewed, and whether the TLS endpoint is the only place where clients can reach the instance.

Set LANGFUSE_CSP_ENFORCE_HTTPS=true so that browsers are restricted to HTTPS for the UI. Confirm this on a test deployment before you rely on it, because a mixed-content or redirect problem between the TLS endpoint and Langfuse Web will show up as a broken login or blank page rather than a clear error. Also confirm how your proxy sets forwarding headers, since the application must see the original scheme and host to build correct links and cookies. The exact header behavior and any required proxy settings should be checked against the Langfuse self-hosting docs for your version.

Trace ingestion needs the same care. Langfuse accepts OpenTelemetry traces over OTLP at the /api/public/otel endpoint, so OTEL-instrumented applications can send traces to it. That path carries prompts, outputs and metadata, which are often the most sensitive data in the system. It must sit behind the same TLS endpoint as the UI and public API, with no plaintext listener exposed to application networks. Inventory every service, batch exporter and sidecar that sends traces, and confirm that each one is configured with an https URL and a certificate chain it trusts. A common failure is an internal collector still pointed at a plain HTTP address after the UI has moved to HTTPS.

Langfuse Worker processes asynchronous events and talks to PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Those internal hops are not covered by the edge TLS endpoint. You must decide whether traffic between the TLS endpoint and the containers, and between the containers and each data store, is also encrypted. Many organizations encrypt these links with mutual TLS through a service mesh, with TLS enabled on the database connections, or with a network policy that keeps the traffic on a segment they control. Confirm the choice against your own network policy and the Langfuse self-hosting docs, and verify each client setting, since some connection options are per data store and are not switched on by one global flag.

Record the decision as a table of paths: client to TLS endpoint, TLS endpoint to Langfuse Web, OTLP sources to the TLS endpoint, Langfuse Web and Worker to each data store, and blob storage access. For each path, name the protocol, the certificate owner, the trust store, and the test that proves encryption is active, such as a handshake check from inside the cluster. Re-run these checks after certificate renewal, proxy changes and Langfuse upgrades, because a version change can alter how the application connects to its stores.

Three application-level secrets sit on top of the transport and storage controls covered elsewhere on this page. Each one protects a different asset, so a leak or loss of each has a different blast radius. SALT is used to hash API keys, so the key material stored in PostgreSQL can be checked without being kept in readable form. NEXTAUTH_SECRET is used to encrypt console JWTs, the session tokens that keep people signed in to the Langfuse UI. ENCRYPTION_KEY encrypts the LLM provider API keys and integration credentials that Langfuse stores so it can call those services on your behalf. Before deployment, map each secret to the component that reads it, because the Web and Worker containers both depend on these values.

If NEXTAUTH_SECRET leaks, anyone holding it may be able to forge or tamper with console session tokens, so the team should plan a rotation that ends existing sessions. Ask the Langfuse encryption documentation and your own test environment what happens to active sessions when the value changes. If ENCRYPTION_KEY leaks alongside a database copy, stored provider and integration credentials can be decrypted, which exposes spend, model access and data at those external systems. Losing ENCRYPTION_KEY is a different failure: stored credentials cannot be read after a restore unless the same value is available, so an otherwise healthy restore can leave integrations broken until the credentials are re-entered.

Operator error is the more likely route to trouble. Common causes include regenerating a value during a Helm or Terraform redeploy, committing a values file with a secret to version control, pasting a value into a ticket, or restoring PostgreSQL while the matching secret is missing or from a different point in time. Confirm the required length, character set and generation method in the encryption documentation before you generate anything, since this guide does not specify them. Use a cryptographically secure generator, store each value as its own entry in your secrets manager, give the deployment pipeline read access and limit human access to a named owner group. Record which value belongs to which environment so no one has to guess during an incident.

Backup needs the same discipline as the data. Keep versioned copies of all three values in the secrets manager, and record which secret version pairs with which PostgreSQL and ClickHouse backup set. Include a restore test in a non-production environment that brings up the database and the matching secrets together, then confirms that a stored integration credential still works and that a console login succeeds. Before go-live, ask your DeployOpen team or the Langfuse documentation whether changing SALT affects existing API keys, and write down the rotation procedure for each secret so the on-call team can follow it without the original builders present.

Treat each of the three application secrets as a separate change with its own window and its own rollback path. The reason is that each one protects different data. SALT is used to hash API keys, NEXTAUTH_SECRET is used to encrypt console JWTs (the sessions people use to sign into the Langfuse UI), and ENCRYPTION_KEY is used to encrypt the LLM API and integration credentials you store inside Langfuse. A change to one does not have the same consequences as a change to another, so a single combined rotation plan is the wrong unit of work.

Before you schedule any change, read the encryption documentation for the exact Langfuse version you run. Confirm three things in writing with your vendor or from that page: what happens to existing hashed API keys after SALT changes, whether existing console sessions survive a NEXTAUTH_SECRET change, and what happens to stored encrypted credentials after an ENCRYPTION_KEY change. Also confirm whether any of these values can be changed without re-entering credentials, such as the LLM provider keys or integration secrets configured in the UI. If the answer for ENCRYPTION_KEY is that stored credentials must be re-entered, that work belongs in the change plan, with a named owner and a list of every credential affected.

Write the rollback path before the change, not after it. Keep the previous values in your secrets manager under version control, record which deployment artifacts read each variable, and decide in advance how you will restore the old value and restart Langfuse Web and Langfuse Worker, since both containers read the same configuration. Take a backup of PostgreSQL first, because the backup is your restore point for data the application writes during the window. Plan the change during a period when project API key use and sign-ins are low, and tell the teams that run SDK integrations that they may need to check their keys afterwards.

Test every rotation in a non-production instance that mirrors your production configuration, including the same secret store, the same ENCRYPTION_KEY history and a representative set of stored credentials. Run the full sequence there: rotate, restart, sign in with an existing account, send a trace with an existing project API key, open a configured integration and confirm it still connects. Record what you observed for each step. If the test shows that a value cannot be rotated without re-entry, you have learned that before production, and you can size the work accordingly.

Keep a short runbook for the production change with the pre-checks, the rotation order, the verification steps and the rollback trigger. Name who decides to roll back and how long you will watch for failures before closing the change. Retain the test record as change evidence for your internal review, since it shows which behavior you confirmed for your version rather than assumed.