Langfuse selbst hosten: LLM-Observability und Audit-Logging für KI-Anwendungen
Langfuse ist die selbst gehostete Observability-Plattform für LLM-Anwendungen: vollständige Traces, Kosten- und Qualitätsmetriken sowie DSGVO-konformes Audit-Logging, als logische Ergänzung zu LiteLLM-Proxy und Ollama.
Werbung Mit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu
Wer KI-Anwendungen mit LLMs betreibt, weiß: Ohne Sichtbarkeit in das, was die Modelle tatsächlich tun, ist weder sinnvolles Debugging noch Compliance-Nachweis möglich. Genau hier setzt Langfuse an: eine im Kern MIT-lizenzierte Observability-Plattform, die als selbst gehostete Lösung vollständige Traces, Token-Kosten und Latenz-Metriken für jeden einzelnen LLM-Aufruf aufzeichnet und so jeden Aufruf nachvollziehbar protokolliert. Langfuse gehört seit Januar 2026 zu ClickHouse, Enterprise-Funktionen stehen unter einer eigenen Lizenz. Die Plattform lässt sich in bestehende Setups mit LiteLLM-Proxy oder Ollama einbinden und hält alle Daten in der eigenen Infrastruktur, ohne Cloud-Abhängigkeit.
Voraussetzungen
- Server/VM: Linux (Debian/Ubuntu empfohlen), mindestens 4 CPU-Kerne, 16 GB RAM, 100 GB SSD-Speicher
- Docker Engine ab Version 24.x mit Docker Compose Plugin installiert (nicht das veraltete
docker-compose-Binary) - Git für den Repository-Klon
- OpenSSL zur Secret-Generierung (auf allen gängigen Linux-Distributionen vorinstalliert)
- Offene Firewallports: 3000 (Web-UI) und optional 9090 (MinIO); alle anderen Dienste bleiben intern
- Domain oder statische IP für
NEXTAUTH_URL(bei Produktivbetrieb zwingend, bei lokalem Test reichtlocalhost) - Optional: Python 3.11 oder neuer für das Python-SDK 5 (Schritt 7)
- Optional: eine bestehende LiteLLM-Konfiguration (
litellm_config.yaml) für die Gateway-Integration
Schritt 1: Architektur verstehen
Vor der Installation lohnt ein Blick auf die Interna. Langfuse ist kein monolithischer Dienst, sondern ein koordinierter Stack aus sechs Komponenten mit klar getrennten Zuständigkeiten:
| Dienst | Port(s) | Rolle | Volume |
|---|---|---|---|
| langfuse-web | 3000 | Web-UI + REST-API-Endpunkt | kein Volume |
| langfuse-worker | 3030 | Async-Verarbeitung, LLM-Evaluierungen | kein Volume |
| PostgreSQL | 5432 | Transaktionsdaten: Nutzer, Projekte, Konfiguration (OLTP) | langfuse_postgres_data |
| ClickHouse | 8123 / 9000 | Observability-Daten: Traces, Metriken (OLAP) | langfuse_clickhouse_data, langfuse_clickhouse_logs |
| Redis / Valkey | 6379 | Caching und Job-Queue | langfuse_redis_data |
| MinIO | 9090 | S3-kompatibler Blob-Storage für Traces und Medien | langfuse_minio_data |
Die Trennung zwischen PostgreSQL (OLTP) und ClickHouse (OLAP) ist bewusst: PostgreSQL verwaltet strukturierte Stammdaten mit hohen Schreibkonsistenzanforderungen, während ClickHouse für die analytischen Abfragen über Millionen von Trace-Einträgen optimiert ist. Nach außen müssen nur zwei Ports erreichbar sein: Port 3000 für die Web-Oberfläche und Port 9090 für MinIO. PostgreSQL, ClickHouse, Redis und der Worker sind an 127.0.0.1 gebunden und dürfen nicht extern erreichbar sein.
free -h und nproc bestätigen mindestens 16 GB RAM und 4 Kerne; ss -tlnp | grep -E ':(3000|9090|5432|6379|8123|9000|3030) ' zeigt, dass keiner der benötigten Ports bereits belegt ist.
Schritt 2: Repository klonen und Secrets generieren
Langfuse wird direkt aus dem offiziellen GitHub-Repository bezogen. Das Repository enthält eine fertige docker-compose.yml mit allen sechs Diensten (Images docker.langfuse.com/langfuse/langfuse:4 und docker.langfuse.com/langfuse/langfuse-worker:4). Der Tag :4 folgt dem jeweils neuesten Release der Hauptversion 4; im Test zeigte er auf dasselbe Image wie :4.70.1:
# Repository klonen
git clone https://github.com/langfuse/langfuse.git
cd langfuse
# Secrets generieren: NEXTAUTH_SECRET und SALT (Base64)
openssl rand -base64 32
# ENCRYPTION_KEY: zwingend 256 Bit = exakt 64 Hex-Zeichen
openssl rand -hex 32Wichtig: Führen Sie openssl rand -base64 32 zweimal aus, einmal für NEXTAUTH_SECRET und einmal für SALT. Nur der ENCRYPTION_KEY kommt aus openssl rand -hex 32. Ein Base64-Wert als ENCRYPTION_KEY führt zu einem Startfehler. Erzeugen Sie außerdem je ein Passwort für PostgreSQL, ClickHouse, MinIO und Redis, etwa mit openssl rand -hex 16.
git -C langfuse log -1 --format=%cd zeigt ein aktuelles Datum, und grep -c CHANGEME langfuse/docker-compose.yml zählt die Stellen, für die Sie eigene Werte brauchen (im Test mit Release v4.70.1: 14).
Schritt 3: Umgebungsvariablen konfigurieren
Die docker-compose.yml liest alle Werte als ${VARIABLE:-Standardwert}. Sie müssen die Datei daher nicht bearbeiten, sondern legen daneben eine .env an; das erleichtert spätere Updates per git pull. Die Standardwerte (mysecret, miniosecret usw.) sind nur für lokale Tests gedacht. Die Pflichtfelder:
| Variable | Beispielwert | Hinweis |
|---|---|---|
| DATABASE_URL | postgresql://langfuse:PW@postgres:5432/langfuse | PostgreSQL-Verbindung |
| NEXTAUTH_URL | http://localhost:3000 | Bei VM-Betrieb: echte IP/Domain! |
| NEXTAUTH_SECRET | (openssl rand -base64 32) | Session-Validierung |
| SALT | (openssl rand -base64 32) | API-Key-Hashing |
| ENCRYPTION_KEY | (openssl rand -hex 32) | 256 Bit, exakt 64 Hex-Zeichen |
| CLICKHOUSE_MIGRATION_URL | clickhouse://clickhouse:9000 | TCP-Protokoll für Migrationen |
| CLICKHOUSE_URL | http://clickhouse:8123 | HTTP-Protokoll für Abfragen |
| CLICKHOUSE_CLUSTER_ENABLED | false | Pflicht für Single-Node! |
| REDIS_AUTH | (openssl rand -hex 16) | Gleicher Wert für Redis-Container und Langfuse |
| LANGFUSE_S3_EVENT_UPLOAD_FORCE_PATH_STYLE | true | Pflicht für MinIO-Kompatibilität |
Eine .env im Ordner langfuse mit allen Werten, die in der offiziellen Datei mit CHANGEME markiert sind:
# langfuse/.env (neben docker-compose.yml)
NEXTAUTH_URL=http://localhost:3000 # Bei VM: http://<server-ip>:3000
NEXTAUTH_SECRET=CHANGEME # openssl rand -base64 32
SALT=CHANGEME # openssl rand -base64 32
ENCRYPTION_KEY=CHANGEME # openssl rand -hex 32 (64 Hex-Zeichen!)
POSTGRES_PASSWORD=CHANGEME
DATABASE_URL=postgresql://postgres:CHANGEME@postgres:5432/postgres # gleiches Passwort
CLICKHOUSE_PASSWORD=CHANGEME
REDIS_AUTH=CHANGEME
MINIO_ROOT_PASSWORD=CHANGEME
# gleiches Passwort wie MINIO_ROOT_PASSWORD:
LANGFUSE_S3_EVENT_UPLOAD_SECRET_ACCESS_KEY=CHANGEME
LANGFUSE_S3_MEDIA_UPLOAD_SECRET_ACCESS_KEY=CHANGEME
LANGFUSE_S3_BATCH_EXPORT_SECRET_ACCESS_KEY=CHANGEMECLICKHOUSE_CLUSTER_ENABLED=false und LANGFUSE_S3_EVENT_UPLOAD_FORCE_PATH_STYLE=true sind in der offiziellen Datei bereits als Standard gesetzt.
Kritischer Hinweis zur Zeitzone: PostgreSQL und ClickHouse müssen in UTC laufen. Mit Europe/Berlin liefern ClickHouse-Abfragen leere oder falsche Ergebnisse, ohne Fehlermeldung im Log. Die offizielle Datei setzt für PostgreSQL TZ und PGTZ auf UTC, ClickHouse läuft standardmäßig in UTC. Übernehmen Sie keine abweichende Zeitzone aus eigenen Vorlagen.
docker compose config --quiet meldet keinen Fehler, und docker compose config | grep -cE 'mysecret|mysalt|miniosecret|myredissecret' liefert 0. Im Test lief genau diese Prüfung mit der offiziellen Datei (Release v4.70.1, Stand 27.10.2026) und der .env oben ohne Treffer.
Schritt 4: Stack starten
# Stack im Hintergrund starten
docker compose up -d
# Logs des Web-Containers verfolgen
docker compose logs -f langfuse-webDer Stack benötigt 2 bis 3 Minuten bis zur vollständigen Betriebsbereitschaft. Datenbankmigrationen für PostgreSQL und ClickHouse laufen beim ersten Start automatisch ab.
Sobald langfuse-web im Log Ready ausgibt, ist der Dienst erreichbar. http://localhost:3000 (oder http://<server-ip>:3000) zeigt die Anmeldeseite. Ein Standardkonto gibt es nicht: Über Sign up legen Sie den ersten Benutzer an. docker compose ps zeigt alle sechs Container mit Up, die Datenbanken zusätzlich mit (healthy). Beim allerersten Start stehen im Log einmalig Fehlermeldungen wie relation "monitors" does not exist, solange die Tabellen noch nicht angelegt sind; im Test kamen sie nach All migrations have been successfully applied. nicht wieder.
Schritt 5: Erstes Projekt einrichten (manuell oder automatisiert)
Nach dem ersten Login legen Sie eine Organisation und ein Projekt an. Langfuse erzeugt dann ein Public Key-/Secret Key-Paar (Format: pk-lf-... / sk-lf-...), das alle Integrationen benötigen.
Für Infrastructure-as-Code-Setups (CI/CD, automatisches Deployment) lässt sich die Ersteinrichtung auch vollständig über LANGFUSE_INIT_*-Umgebungsvariablen automatisieren:
# Headless-Initialisierung per Umgebungsvariablen
# WICHTIG: Werte NICHT in doppelte Anführungszeichen einschließen!
environment:
LANGFUSE_INIT_ORG_ID: meine-org
LANGFUSE_INIT_ORG_NAME: Meine Organisation
LANGFUSE_INIT_PROJECT_ID: mein-ki-projekt
LANGFUSE_INIT_PROJECT_NAME: Mein KI-Projekt
LANGFUSE_INIT_PROJECT_PUBLIC_KEY: pk-lf-...
LANGFUSE_INIT_PROJECT_SECRET_KEY: sk-lf-...
LANGFUSE_INIT_USER_EMAIL: admin@example.com
LANGFUSE_INIT_USER_PASSWORD: CHANGEMEMit der .env aus Schritt 3 tragen Sie diese Werte dort ein (LANGFUSE_INIT_ORG_ID=meine-org usw.); die offizielle Datei reicht sie an langfuse-web durch.
Unter Settings → API Keys des Projekts erscheint ein Schlüsselpaar mit pk-lf-. curl -u pk-lf-…:sk-lf-… http://localhost:3000/api/public/projects liefert das Projekt als JSON.
Schritt 6: LiteLLM-Proxy integrieren
Wer bereits einen LiteLLM-Proxy als LLM-Gateway betreibt, verbindet diesen mit einem einzigen Callback-Eintrag in der litellm_config.yaml. Traces werden asynchron gesendet, die Latenz der KI-Anwendung bleibt unberührt:
# litellm_config.yaml: Ergänzung für die Langfuse-Integration
model_list:
- model_name: gpt-4o
litellm_params:
model: openai/gpt-4o
api_key: sk-xxx
- model_name: ollama/llama3.2
litellm_params:
model: ollama/llama3.2
api_base: http://ollama:11434
litellm_settings:
callbacks: ["langfuse_otel"]Zusätzlich benötigt der LiteLLM-Container drei Umgebungsvariablen:
LANGFUSE_PUBLIC_KEY=pk-lf-...
LANGFUSE_SECRET_KEY=sk-lf-...
LANGFUSE_OTEL_HOST=http://langfuse-web:3000 # interne Docker-Netzwerk-URLSenden Sie nach der Konfiguration eine Testanfrage über den LiteLLM-Proxy. In der Langfuse-Web-UI unter „Traces“ sollte innerhalb weniger Sekunden ein neuer Eintrag erscheinen, der Prompt, Antwort, Token-Verbrauch und Latenz enthält.
Schritt 7: Python SDK für direkte Integration
Eigene Anwendungen senden Traces über das Python SDK, etwa in Agenten-Pipelines oder mit LangChain und LlamaIndex. Das aktuelle SDK (Version 5, seit Oktober 2026) arbeitet mit OpenTelemetry; die frühere Schreibweise lf.trace(…) aus SDK v2 gibt es nicht mehr, und Langfuse v4 lehnt Daten von SDK v2 ab. SDK v5 setzt laut Projektdokumentation Python 3.11 oder neuer und einen Langfuse-Server ab 4.59.0 voraus. Unter Python 3.10 installiert pip install langfuse die letzte Version 4 (im Test 4.18.0). Ist Ihr Server älter, aktualisieren Sie ihn zuerst oder bleiben vorerst mit pip install "langfuse<5" bei SDK v4. Das Beispiel lief im Test mit SDK 4.18.0 und 5.0.4 unverändert:
pip install langfuse
export LANGFUSE_PUBLIC_KEY="pk-lf-..."
export LANGFUSE_SECRET_KEY="sk-lf-..."
export LANGFUSE_BASE_URL="http://localhost:3000"# app.py
from langfuse import get_client
langfuse = get_client()
with langfuse.start_as_current_observation(as_type="span", name="mein-llm-aufruf") as span:
with langfuse.start_as_current_observation(
as_type="generation", name="openai-call", model="gpt-4o-mini"
) as generation:
generation.update(output="Hallo! Wie kann ich helfen?")
span.update(output="fertig")
langfuse.flush() # in kurzlebigen Skripten alle Daten sofort sendenLangfuse v4 arbeitet mit Observations (Span, Generation, Event): Eine Generation steht für einen LLM-Aufruf, ein Span für einen Verarbeitungsschritt (z. B. Retrieval), ein Event für eine Aktion ohne Dauer. Ein Trace ist die oberste Observation einer Kette, Sessions fassen mehrere Traces zusammen.
pip show langfuse zeigt Version 5.x (im Test 5.0.4, unter Python 3.10 die 4.18.0). Nach python app.py erscheint in der Oberfläche unter Observations ein Eintrag mein-llm-aufruf mit der Generation openai-call. Per API liefert curl -s -u pk-lf-…:sk-lf-… "http://localhost:3000/api/public/v2/observations?name=openai-call&fields=core,basic,model,io&limit=1" die Generation mit dem Modell gpt-4o-mini und der Ausgabe aus app.py.
Troubleshooting / Typische Fehler
ClickHouse liefert leere Ergebnisse: kein Fehler im Log
Ursache: PostgreSQL oder ClickHouse läuft nicht in UTC. Prüfen Sie mit docker compose exec clickhouse clickhouse-client --query "SELECT timezone()", das Ergebnis muss UTC sein (im Test: UTC). Lösung: TZ=UTC als Umgebungsvariable in allen Containern setzen und den Stack neu starten.
Start schlägt fehl mit „ENCRYPTION_KEY must be 64 hex characters“
Ursache: Der Key wurde mit openssl rand -base64 32 statt openssl rand -hex 32 generiert. Base64 erzeugt eine andere Zeichenanzahl. Im Test mit einem Base64-Schlüssel (44 Zeichen) startete langfuse-worker immer wieder neu (docker compose ps: Restarting), im Log stand ENCRYPTION_KEY must be 256 bits, 64 string characters in hex format, generate via: openssl rand -hex 32. Lösung: Neuen Key mit dem korrekten Befehl generieren, in der .env ersetzen und docker compose up -d ausführen; im Test war der Stack danach nach 15 Sekunden wieder bereit.
ClickHouse-Befehle schlagen alle fehl
Ursache: CLICKHOUSE_CLUSTER_ENABLED ist nicht auf false gesetzt. Der Standardwert ist true (Cluster-Modus), der für Single-Container-Setups nicht funktioniert. Lösung: Variable explizit auf false setzen.
OAuth-Authentifizierung schlägt fehl bei VM-Betrieb
Ursache: NEXTAUTH_URL zeigt auf localhost statt auf die tatsächliche IP oder Domain. Lösung: NEXTAUTH_URL=http://<server-ip>:3000 oder https://langfuse.example.com setzen.
MinIO-Bucket-Zugriff schlägt fehl mit „invalid endpoint“
Ursache: LANGFUSE_S3_EVENT_UPLOAD_FORCE_PATH_STYLE ist nicht gesetzt. MinIO erfordert Path-Style-Zugriff. Lösung: Variable auf true setzen.
API-Aufrufe schlagen nach dem Start fehl
Ursache: Der Stack fährt noch hoch (2 bis 3 Minuten). Erst wenn docker compose logs langfuse-web das Wort Ready enthält, ist der Dienst betriebsbereit.
LANGFUSE_INIT_* führt zu Parse-Fehlern
Ursache: Werte wurden in doppelte Anführungszeichen eingeschlossen (z. B. LANGFUSE_INIT_ORG_NAME: "Meine Org"). Docker Compose interpretiert diese anders als erwartet. Lösung: Anführungszeichen bei LANGFUSE_INIT_*-Variablen weglassen.
Häufige Fragen
Kann ich Langfuse komplett ohne Internetverbindung betreiben?
Ja. Nach dem einmaligen docker compose pull benötigt der Stack keine ausgehende Internetverbindung mehr. Langfuse unterstützt vollständig air-gapped-Betrieb: Alle Komponenten kommunizieren nur intern über das Docker-Netzwerk.
Wie verbinde ich meinen bestehenden LiteLLM-Proxy?
In litellm_config.yaml unter litellm_settings den Eintrag callbacks: ["langfuse_otel"] hinzufügen und die drei Umgebungsvariablen LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY und LANGFUSE_OTEL_HOST im LiteLLM-Container setzen. Kein Neustart der LLM-Backends notwendig.
Welche Datenbank speichert was?
PostgreSQL übernimmt alle Transaktionsdaten: Nutzer, Projekte, API-Keys, Konfiguration. ClickHouse speichert sämtliche Observability-Daten: Traces, Generierungen, Metriken und Evaluierungsergebnisse. Die Trennung hält analytische Abfragen über Millionen Einträge schnell, ohne die Transaktionsdatenbank zu belasten.
Wie funktioniert DSGVO-konforme Verarbeitung personenbezogener Daten in Traces?
Langfuse bietet drei Mechanismen: Data Masking (Verschleierung sensibler Felder vor der Speicherung), Data Retention (automatisches Löschen nach konfigurierbaren Zeiträumen) und Data Deletion (Löschen einzelner Traces, Sessions oder ganzer Projekte). Im Selbstbetrieb gilt laut Projektdokumentation: Masking im SDK vor dem Senden und Data Deletion sind ohne Lizenz nutzbar, serverseitiges Masking beim Empfang und Data Retention gehören zur Enterprise Edition. Seit Version 4.54.0 wendet der Worker Aufbewahrungsfristen ohne Enterprise-Lizenz nicht mehr an. Auch die Funktion Audit Logs (Änderungsprotokoll innerhalb von Langfuse) ist im Selbstbetrieb Teil der Enterprise Edition. Ohne Lizenz brauchen Sie für Speicherbegrenzung nach Art. 5 DSGVO deshalb ein eigenes Löschkonzept, etwa regelmäßiges Löschen über die API. Ein Auftragsverarbeitungsvertrag (DPA) gibt es für Langfuse Cloud; beim Selbst-Hosting sind Sie selbst Verantwortlicher.
Wann sollte ich von Docker Compose auf Kubernetes wechseln?
Docker Compose eignet sich ausdrücklich nur für Test- und Low-Scale-Betrieb: Es gibt keine Hochverfügbarkeit, kein automatisches Scaling und kein eingebautes Backup-Management. Sobald Langfuse geschäftskritisch wird oder mehr als eine Handvoll Nutzer bedient, empfiehlt Langfuse den Wechsel auf Kubernetes via Helm-Chart oder Terraform-Templates für AWS, Azure oder GCP.
Wie aktualisiere ich auf eine neue Version?
Im geklonten Repository git pull ausführen, dann docker compose pull && docker compose up -d. Die Image-Tags :4 bleiben dabei innerhalb der Hauptversion 4. Im Test lief so das Update von 4.50.0 auf 4.67.0: Nutzer, Anmeldungen, API-Schlüssel, Prompts und Traces blieben erhalten. Am 24.10.2026 lief ebenso das Update von 4.67.0 auf 4.69.0 mit der jeweils offiziellen docker-compose.yml des Release-Tags: Die Datenbankmigrationen liefen beim Start durch, ein vor dem Update per OpenTelemetry-Endpunkt /api/public/otel/v1/traces gesendeter Trace war danach weiter abrufbar, ein neuer Trace kam an, die Anmeldung des Init-Benutzers gelang, und die API antwortete ohne oder mit falschem Schlüssel mit HTTP 401. 4.69.0 ergänzt in der Compose-Datei die optionale Variable LANGFUSE_BLOB_STORAGE_ENDPOINT_ALLOWED_HOSTS, eine Liste erlaubter Ziele für Blob-Storage-Exporte; ohne Wert bleibt das Verhalten unverändert. Ein git pull holt diese Änderung mit. Die Compose-Datei von v4.70.1 ist mit der von v4.69.0 identisch. Am 27.10.2026 lief das Update von 4.69.0 auf 4.70.1 ebenso: /api/public/health meldete danach 4.70.1, das Log „No pending migrations to apply.“, ein vorher angelegter Prompt war über die API lesbar, die Anmeldung des Init-Benutzers gelang, ein falsches Passwort ergab keine Sitzung, und die API antwortete ohne oder mit falschem Schlüssel mit HTTP 401. 4.70.0 fordert laut Release Notes beim Ändern eines Webhook- oder PostHog-Ziels die Geheimnisse erneut an und hebt dompurify und nodemailer an, 4.70.1 bringt kleinere Fehlerbehebungen und Node 24.22.1. Hinweis zum Test mit eigenen Skripten: Neue Organisationen nehmen über die alte Batch-Schnittstelle /api/public/ingestion seit 4.68.0 nur noch Scores an und antworten bei Traces mit HTTP 207 und einem Hinweis auf den v4-Migrationsmodus. Senden Sie Traces wie in Schritt 7 über das SDK oder den OpenTelemetry-Endpunkt. Aktualisieren Sie erst den Server (für das Python-SDK 5 mindestens 4.59.0) und danach das SDK in Ihren Anwendungen, Details im Leitfaden Python-SDK v4 auf v5. Im Test kam der Trace aus Schritt 7 mit SDK 5.0.4 zwar auch bei Server 4.50.0 an, laut Kompatibilitätsmatrix ist diese Kombination aber nicht unterstützt. Bestehende v3-Installationen folgen dem offiziellen Migrationsleitfaden v3 → v4 (ClickHouse-Aktualisierung, neues Datenmodell); v3 erhält Sicherheitsupdates bis Ende Januar 2027. Datenbankmigrationen für PostgreSQL und ClickHouse laufen beim Start automatisch ab, außer die Automigration wurde mit LANGFUSE_AUTO_POSTGRES_MIGRATION_DISABLED=true oder LANGFUSE_AUTO_CLICKHOUSE_MIGRATION_DISABLED=true deaktiviert.
Fazit
Langfuse zeigt, was die Modelle in selbst gehosteten KI-Stacks tun, was sie kosten und ob die Antwortqualität genügt. Als im Kern MIT-lizenzierte Plattform, die seit Januar 2026 zu ClickHouse gehört, ist sie eine natürliche Ergänzung zu Ollama und LiteLLM und liefert mit ihren Traces eine Grundlage für die Protokollierung von KI-Aufrufen nach DSGVO und EU AI Act. Wer im Selbstbetrieb automatische Aufbewahrungsfristen oder das Änderungsprotokoll Audit Logs braucht, plant die Enterprise-Lizenz oder ein eigenes Löschkonzept ein. Die Fallstricke rund um UTC-Zeitzone, ENCRYPTION_KEY-Format und ClickHouse-Cluster-Modus sind bekannt und lassen sich mit den Hinweisen aus dieser Anleitung zuverlässig vermeiden. Für produktive Deployments mit Hochverfügbarkeitsanforderungen ist der Weg zu Kubernetes der nächste logische Schritt.
Weiterführende Anleitungen und Quellen
- Docker und Docker Compose auf Linux installieren (Ubuntu/Debian): die Self-Hosting-Grundlage
- LiteLLM mit Docker installieren: zentrales LLM-Gateway für alle Modelle
- Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell ohne Cloud
- Lokale KI datenschutzkonform betreiben: DSGVO-Checkliste für On-Premise-LLM-Deployments
- RAG produktiv betreiben: Chunking, Hybrid-Search, Reranking und Antwortqualität messen
- Langfuse Self-Hosting Dokumentation (offiziell)
- Langfuse Docker Compose Deployment (offiziell)
- Langfuse Environment Variables Configuration (offiziell)
- Langfuse DSGVO / GDPR (offiziell)
- Langfuse Release v4.70.1 (GitHub)
- Leitfaden Python-SDK v4 auf v5 (offiziell)
- Versionen und Kompatibilität von Server und SDKs (offiziell)
- Data Retention (offiziell)
- Audit Logs (offiziell)
- Langfuse joins ClickHouse (Blog, 16.01.2026)
