Self-hosted Langfuse for GDPR storage limitation and erasure

Without a retention policy, self-hosted Langfuse keeps traces, observations, scores and media indefinitely. Nothing in the default configuration removes a trace once it is ingested, so every prompt, completion and metadata field written during the instance's lifetime stays in the store. That matters because personal data in LLM traces rarely arrives as a deliberate field. A user pastes an email address or an account number into a chat, a retrieval step returns a customer record, and a session identifier tied to a named account is attached as metadata. Teams often expect traces to behave like short-lived debugging logs. In practice they accumulate into a long history of identifiable records, and each day of ingestion adds to the volume the controller must later justify, search and erase.

Article 5(1)(e) of the GDPR requires personal data to be kept in a form that permits identification for no longer than is necessary for the purposes of the processing. Article 25(2) adds that, by default, only the personal data necessary for each specific purpose are processed, including with respect to the period of their storage. Together they turn the indefinite default into a decision the controller must make and record. The period is set per purpose, so one number for the whole instance rarely fits. As an illustrative case only, traces used to investigate production incidents in a support assistant may need a short period, an evaluation dataset kept for regression testing may need a different one, and a usage report may only need aggregated counts. Each period needs a stated justification, an owner and a documented trigger for review.

In self-hosted Langfuse, the retention policy is the technical mechanism for that decision. According to the Langfuse documentation, retention policies are part of the Enterprise Edition and need a license key, and they delete data older than a configured number of days each night. Confirm with Langfuse which object types the policy covers in your version, including scores and media, because the storage period you document must match what the platform actually deletes. Individual erasure requests follow a separate path. The API can delete a single trace, a batch of traces, all traces in a session (Langfuse v4 or later when self-hosted), traces matching a filter, a project, an organization or a user account. Trace deletion also removes related observations and scores, but it runs asynchronously, so test how long it takes to complete in your environment.

Plan this work before the first production trace arrives. Inventory which fields in prompts, completions, metadata and attachments can contain personal data, and map each field to a purpose. Decide which retention period applies to each purpose, then check whether the enterprise license needed for an automated policy is included in your quote. Where the platform cannot express a period, confirm whether a scheduled deletion job against the API is acceptable and who will operate it. Test the chain end to end: create a synthetic trace containing a marker value, run the retention or deletion job, and confirm that the marker is gone from the UI, the API and the storage layer. Also confirm how backups and exports are handled, since a live deletion does not necessarily reach copies taken earlier. Record the decision and the test evidence in your records of processing, because the controller must be able to demonstrate the decision.

Map each erasure request to the narrowest Langfuse deletion scope that covers the personal data it names. Langfuse supports deleting a single trace, a batch of traces, all traces in a session, traces matching a filter, a project, an organization and a user account. Deleting traces also removes the observations and scores attached to them. A request that names one conversation maps to a trace or session scope. A request that spans a product or tenant maps to a filtered set or project scope. Those actions should pass a documented approval step, because a wrong filter or project selection removes more records than the data subject's own. Write the mapping down before the first request arrives, so the on-call engineer is not choosing scope under time pressure.

Session deletion needs particular care. The Langfuse data deletion documentation describes deleting all traces in a session through the API as available in Langfuse v4 or later when self-hosted. If your instance runs an earlier version, a session-shaped request has to be translated into batch or filtered deletion by trace identifier, and you should test that translation on a non-production project first. Confirm with the API reference for your exact version which scopes are exposed through the API and which appear in the UI, because the two surfaces may not offer the same options. Record the Langfuse version, the scope list you confirmed and the date you confirmed it, since the answer can change with each upgrade.

Deletion runs asynchronously. A successful API response or a UI confirmation shows that the request was accepted, but it does not confirm that every copy has gone. Run a completion check after the Langfuse Worker has processed the job, and attach its output to the erasure record. Check each store that can hold the data: ClickHouse for trace, observation and score rows, PostgreSQL for metadata that references the trace or project, and S3-compatible blob storage for media attachments. Query by the identifiers you deleted and keep the results as evidence. Worker logs and queue status show whether jobs are still pending, but a query against the stores themselves is the check that confirms removal.

Deletion from live stores does not reach backups by itself. The EDPB's 2025 coordinated enforcement action on the right to erasure listed deletion of personal data in backups among its recurring challenges, so your backup retention and restore procedure needs a written position. State which backups hold the data, how long they persist, and what you do if a restore brings back an erased record. Account and organization deletions remove more than traces, so confirm with your version what they cover and whether they can be reversed. Treat the whole mapping as a controlled procedure and review it at every Langfuse upgrade.

Self-hosting keeps stored traces in your infrastructure, but it does not by itself settle transfer questions. Under EDPB Guidelines 05/2021 (version 2.0), remote access from a third country is a transfer even when the person only views data on a screen for support or administration, and so is storage in a cloud outside the EEA. For a self-hosted Langfuse, map each place trace content can be seen or stored: any vendor engineer who connects to your environment, any screen-sharing session during an incident, and any cloud region or backup target chosen for PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Record each one in your records of processing before go-live.

Article 44 requires every transfer of personal data to a third country, including onward transfers, to meet the Chapter V conditions. In practice, that means an adequacy decision under Article 45 or an Article 46 safeguard such as the standard contractual clauses adopted by Commission Implementing Decision (EU) 2021/914, supported by a transfer impact assessment. In Schrems II (Case C-311/18, judgment of 16 July 2020), the Court invalidated the Privacy Shield but held that standard contractual clauses remained valid, provided the destination's law allows the clauses to be complied with. EDPB Recommendations 01/2020 go further: where a provider needs data in the clear and third-country public authority powers exceed what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Encryption keys you hold do not fix access to clear-text traces.

The EU-US Data Privacy Framework covers less than many teams assume. Commission Implementing Decision (EU) 2023/1795 finds adequate protection only for US organizations on the Data Privacy Framework List. A US support provider that is not on that list cannot be relied on under the decision, and a listed organization still needs its certified scope checked against the data involved. An appeal against the General Court's September 2025 judgment upholding the decision is pending as Case C-703/25 P. Confirm the status at signing, and prepare a fallback under the standard contractual clauses in case the decision changes.

The US CLOUD Act is the main reason the choice of processor matters, even for an EU-based company. 18 U.S.C. 2713, added on 23 March 2018, requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether it is inside or outside the United States. EDPB Guidelines 05/2021 (Example 12) say that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be. Assess that exposure before engaging such a processor. Article 48 also limits recognition of third-country disclosure orders to those based on an international agreement, such as a mutual legal assistance treaty.

Ask your Langfuse support provider for a written list of every location, account and person able to view trace content, including screen-sharing during incidents. Limit remote access to named jump hosts inside the EEA, log each session, and require tickets to carry metadata rather than raw trace payloads. Record the Chapter V basis for each remaining transfer, and rerun the assessment when the Data Privacy Framework status or Case C-703/25 P changes. DeployOpen implements and documents these controls in your infrastructure, but it does not issue transfer attestations. Your legal counsel and your supervisory authority's guidance determine whether the position is compliant.