Langfuse Security Guide: Self Hosted LLM Tracing

An LLM tracing platform collects every prompt, retrieved document, tool call and model answer an application produces, so a self-hosted Langfuse instance quickly holds some of the most sensitive data in the organisation, guarded by API keys that applications carry everywhere. Langfuse is an open source platform for LLM observability, prompt management and evaluation, offered as Langfuse Cloud and as a self-hosted deployment of a web container, a worker, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage. This guide covers how identity and roles work, how to scope API keys, which secrets protect the deployment, how to mask sensitive data before it leaves the application, retention and audit logs, and a hardening baseline for running it yourself. It is written for platform engineers, AI engineering leads and security reviewers who operate or approve Langfuse. For the discipline of tracing LLM applications in general, see the LLM Observability Guide.

This is an independent guide from NHI Mgmt Group, based on Langfuse's public documentation as of November 2026. It is not sponsored or reviewed by Langfuse. Product features change, so confirm settings against Langfuse's current documentation.

Key takeaways

Self-hosting makes you the operator of the whole stack. TLS, database encryption at rest, network isolation and backups are infrastructure tasks that sit with you; Langfuse documents the settings, you apply them.
Generate three strong secrets and guard them. NEXTAUTH_SECRET protects sessions, SALT hashes API keys and ENCRYPTION_KEY encrypts stored LLM provider credentials.
Scope every project key. Project API keys carry a fixed permission set chosen at creation (Full access, Viewer, Ingestion or Scores ingestion); applications that only send traces need Ingestion.
Mask in the application, before export. Langfuse masking runs client side in the SDKs, so redaction of personal data and secrets must be configured where traces are produced.
Set retention and use SSO. A per-project retention window deletes traces nightly, and SSO with AUTH_DISABLE_USERNAME_PASSWORD or domain enforcement ties access to your identity provider.

How identity and access work in Langfuse

Langfuse has a two-level model of organisations and projects. Users are members of an organisation with a role, and that role applies to every project in it unless a project-level role overrides it. API keys are not tied to a user: they belong to a project or to the organisation.

Role	What it allows (per Langfuse RBAC docs)	Typical holder
Owner	All permissions, including organisation API keys	Two named platform owners
Admin	Edit project settings and grant project access to others; manage project API keys	Team leads for a project
Member	View metrics and create scores, without configuring the project	Engineers and evaluators
Viewer	Read-only access, with most configuration hidden	Stakeholders and reviewers
None	No default access; used with project-level roles	Users who should see only specific projects
AI Gateway (organisation only)	Call the AI Gateway and manage its own gateway keys, with no project access	Gateway consumers

Users can only assign roles at or below their own. To keep sensitive projects separate, set a user's organisation role to None and grant project roles only where needed; a project is visible only to users whose effective role includes project:read. Availability: the RBAC documentation lists project-level roles on Enterprise and Self-Hosted Enterprise Edition, and on Pro with the Teams add-on.

Sign-in and SSO for self-hosted instances

Self-hosted Langfuse uses Auth.js and documents providers including Auth0, Authentik, AWS Cognito, Azure AD/Entra ID, GitHub, GitLab, Google, Keycloak, JumpCloud, Okta, OneLogin, WorkOS and a custom OAuth/OIDC provider. Each uses AUTH_<PROVIDER>_CLIENT_ID and AUTH_<PROVIDER>_CLIENT_SECRET, with the callback path /api/auth/callback/<provider> and NEXTAUTH_URL set to the public URL.

Variable	Effect	Recommended setting
`AUTH_DISABLE_USERNAME_PASSWORD`	Turns off email and password sign-in; SSO must be configured	`true` once SSO works
`AUTH_DOMAINS_WITH_SSO_ENFORCEMENT`	Users on listed domains can only sign in through SSO	Your corporate domains
`AUTH_DISABLE_SIGNUP`	Only existing users can sign in	`true` where provisioning is managed centrally
`AUTH_SESSION_MAX_AGE`	Session lifetime in minutes (default 43200, which is 30 days)	Align with your SaaS session standard, for example 720 to 1440
`AUTH_<PROVIDER>_ALLOW_ACCOUNT_LINKING`	Merges accounts that share an email address; the docs flag a risk where emails are unverified	Enable only for migration from password sign-in, with a provider that verifies email
`AUTH_GOOGLE_ALLOWED_DOMAINS`	Restricts Google sign-in by the `hd` claim	Your Google Workspace domains
`AUTH_EMAIL_VERIFICATION_REQUIRED`	Requires an emailed one-time code at password sign-up	`true` if password sign-in stays on

For joiners, the automated access provisioning variables LANGFUSE_DEFAULT_ORG_ID and LANGFUSE_DEFAULT_PROJECT_ID place new users into a default organisation and project; their roles default to VIEWER through LANGFUSE_DEFAULT_ORG_ROLE and LANGFUSE_DEFAULT_PROJECT_ROLE. Keep that default. For full lifecycle management, the documentation points to the SCIM and Organization Management API.

Admin roles and privileged access

Privilege in Langfuse sits in three places, and each needs its own control.

Organisation Owners: hold all permissions and are the only role that manages organisation API keys for the Organization Management API. Limit to two or three named people, sign in through SSO with phishing-resistant MFA at the identity provider, and review quarterly.
Project Admins: can grant project access and create project API keys, including Full access keys. Review who holds Admin on production projects and keep it to the owning team.
Infrastructure operators: anyone who can read the deployment's environment variables or database credentials has more power than any in-app role, because they hold ENCRYPTION_KEY, SALT, NEXTAUTH_SECRET and direct access to trace data in ClickHouse and S3. Treat Kubernetes namespace admin and database admin for Langfuse as privileged access. See the Kubernetes Secrets Security Guide.

Role changes require the organizationMembers:CUD permission, and the audit log (Enterprise Edition) records membership changes with before and after state, which makes access reviews evidence-based.

Integrations, API tokens and service accounts

Langfuse has several non-human credentials. Each should have an owner, a scope, a storage location and a rotation plan.

Credential	Scope and storage	How to handle it
Project API key pair (`pk-lf-` public, `sk-lf-` secret)	One project; permission set fixed at creation; secret shown once and hashed with `SALT`	Use Ingestion for applications that only send traces, Scores ingestion for evaluation jobs, Viewer for read-only tooling. One key pair per application and environment, stored in your secrets manager.
Organisation API key	Whole organisation, Organization Management API; managed by Owners	Reserve for provisioning automation; store in a vault with restricted access and rotate on owner change.
LLM connection credentials (provider API keys for playground and evaluations)	Stored encrypted with `ENCRYPTION_KEY`	Use a dedicated provider key with a spend limit, separate from production application keys. See the AI model provider API keys guide.
Integration credentials (for example analytics exports)	Encrypted with `ENCRYPTION_KEY`	Grant the receiving system write-only access where it allows.
Data store credentials (`DATABASE_URL`, `CLICKHOUSE_USER`/`PASSWORD`, `REDIS_AUTH`, `LANGFUSE_S3_*` access keys)	Container environment	Inject from a secrets store, use separate credentials per store, and grant S3 keys only the List, Get and Put permissions the docs require (plus `s3:DeleteObject` where retention runs).

The three deployment secrets

The configuration documentation describes how to generate each secret: NEXTAUTH_SECRET and SALT with openssl rand -base64 32, and ENCRYPTION_KEY as 256 bits written as 64 hex characters with openssl rand -hex 32. Never reuse the example values from quick-start files. Store them in your secrets manager, back them up with the database backups they unlock, and plan rotation carefully and confirm the current procedure in Langfuse's documentation. Because SALT hashes API keys and ENCRYPTION_KEY encrypts stored credentials, NHI Mgmt Group's advice is to test any change in a staging copy first. For the wider practice see the API Key Management Guide.

Logging and detection

Audit logs: Langfuse audit logs are immutable records of significant activity. Each entry records the actor (user or API key), the action, the time, the organisation and project, and before and after state for updates. Auditable resources include prompts, traces, scores, datasets, API keys and memberships. The viewer is project-scoped and needs auditLogs:read, and entries can be exported from the table. Availability: Enterprise Edition, including self-hosted Enterprise Edition.

Infrastructure logs: collect web and worker container logs, load balancer access logs and database audit logs in your SIEM. LANGFUSE_LOG_PROPAGATED_HEADERS copies named HTTP headers into logs; add only headers that carry no credentials.

Signal	Why it matters	Source
API key created with Full access	Broadest project credential	Audit log (API keys)
Membership or role change on a production project	Access expansion	Audit log (memberships)
Bulk trace export or deletion	Possible data extraction or evidence loss	Audit log, blob storage access logs
Ingestion from an unexpected network	Possible leaked key	Load balancer logs
Direct queries to ClickHouse or S3 outside the Langfuse service identity	Bypass of application access control	Database and storage audit logs

Metrics that show it is working: share of project keys with a narrower permission set than Full access (target: every application key); projects with a retention window set (target: 100% of production projects); share of sign-ins through SSO (target: 100%); keys older than your rotation period (target: 0); and number of Owners (target: 2 or 3).

Hardening baseline

Put only the web container on the network edge. The networking documentation states that only the web container needs to be reachable by users, the API and SDKs (port 3000 by default, set with PORT), and that it can sit behind a firewall, proxy or VPN. Keep the worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage on private networks.
Terminate TLS and enforce HTTPS. Langfuse relies on infrastructure for HTTPS: a load balancer, or a service mesh with mutual TLS for traffic inside the cluster. Then set LANGFUSE_CSP_ENFORCE_HTTPS=true. Enable TLS to Redis (REDIS_TLS_ENABLED) and to ClickHouse migrations (CLICKHOUSE_MIGRATION_SSL) where your deployment supports it.
Encrypt the stores at rest. Use managed PostgreSQL, Redis and S3 services with encryption on, and follow ClickHouse's encryption documentation for that store. Langfuse Cloud states AES-256 across its databases; on self-hosted, this is your setting.
Restrict egress. Langfuse does not require internet access. Allow only the LLM endpoints used by the playground and evaluations, and the hostnames listed in the telemetry documentation that you choose to permit. Route LLM traffic through a forward proxy with HTTPS_PROXY where you need inspection.
Turn on SSO and turn off passwords. Configure your identity provider, then set AUTH_DISABLE_USERNAME_PASSWORD=true or list your domains in AUTH_DOMAINS_WITH_SSO_ENFORCEMENT, and set AUTH_DISABLE_SIGNUP=true if provisioning is central.
Run evaluator code safely. The documentation recommends LANGFUSE_CODE_EVAL_DISPATCHER=aws-lambda for production and reserves insecure-local for fully trusted evaluator code. Review LANGFUSE_EVALUATOR_MEDIA_TRANSPORT (default inline, which sends attachment bytes to the model provider) against your data rules.
Use FIPS mode where required. LANGFUSE_REQUIRE_FIPS makes containers refuse to start unless FIPS conditions are met.
Set retention per project. Retention (minimum 3 days) runs a nightly job that deletes traces, observations, scores and media older than the window; the docs state that deleted assets are permanently removed. Without a policy, self-hosted data is kept indefinitely. Use Blob Storage Export first if you must archive. Availability: Pro and Enterprise on Cloud, Enterprise Edition self-hosted.
Mask at the source. In Python use the mask_otel_spans hook, which runs at export on batches of OpenTelemetry spans; in JavaScript and TypeScript configure a mask function on LangfuseSpanProcessor. For pure OpenTelemetry pipelines the documentation suggests a Collector with redaction or transform processors. See the Generative AI Data Loss Prevention Guide for what to redact.
Keep current. Apply Langfuse releases promptly and report issues through the vendor's responsible disclosure route on its security page.

Testing and rollback: stand up a staging instance with the same variables, send synthetic traces containing fake card numbers and emails to prove masking, confirm SSO before turning off passwords (keep one break-glass Owner until it works), and run retention on a test project first because deletion is final. Roll back configuration through your deployment tool; data removed by retention is gone for good.

Common misconfigurations

Quick-start secrets in production: example values for NEXTAUTH_SECRET, SALT or ENCRYPTION_KEY copied from a compose file. Generate fresh values per environment.
Full access keys in every application: a tracing client holding a key that can read all traces. Create Ingestion keys for producers.
Datastores on public addresses: ClickHouse, Redis or a bucket reachable from the internet bypasses every in-app role. Keep them private and authenticated.
No retention window: traces with personal data accumulate indefinitely on self-hosted instances. Set a window per project.
Masking assumed to be server side: Langfuse masking runs in the SDK, so a service without the hook sends raw data. Add masking to every producing service and test it.
Account linking left on: ALLOW_ACCOUNT_LINKING kept after migration can merge accounts by email. Turn it off once users have moved to SSO.

Framework mapping

Control area	Langfuse setting	NIST SP 800-53 Rev 5	NIST CSF 2.0	Other
Roles and least privilege	Organisation and project roles, None role	AC-2, AC-6	PR.AA-05	ISO/IEC 27001:2022 A.5.15
Keys and secrets	Scoped project keys, deployment secrets	IA-5	PR.AA-05	ISO/IEC 27001:2022 A.5.17
Encryption	TLS, at-rest encryption, `ENCRYPTION_KEY`	SC-8, SC-28	PR.DS-01, PR.DS-02	ISO/IEC 27001:2022 A.8.24
Sensitive data in traces	SDK masking	SI-12	PR.DS-01	OWASP LLM02:2025 Sensitive Information Disclosure
Retention	Project data retention	SI-12	PR.DS-01	GDPR Art. 5(1)(e) storage limitation
Audit	Audit logs, infrastructure logs	AU-2, AU-6	DE.CM-03	ISO/IEC 27001:2022 A.8.15
Hardening	Network exposure, egress, FIPS	CM-7, SC-7	PR.PS-01	CIS Controls v8.1 Control 4

Practitioner checklist

Expose only the web container; keep worker, PostgreSQL, ClickHouse, Redis and blob storage private.
Generate fresh NEXTAUTH_SECRET, SALT and ENCRYPTION_KEY per environment and store them in a secrets manager.
Terminate TLS, set LANGFUSE_CSP_ENFORCE_HTTPS=true and encrypt every store at rest.
Configure SSO, then set AUTH_DISABLE_USERNAME_PASSWORD or AUTH_DOMAINS_WITH_SSO_ENFORCEMENT, and shorten AUTH_SESSION_MAX_AGE.
Issue Ingestion keys to trace producers, one per application and environment, and keep Full access keys for administration.
Add mask_otel_spans or a mask function to every producing service and test it with synthetic data.
Set a retention window on every production project and archive first where needed.
Limit Owners to two or three, use the None role with project roles for sensitive projects, and review the audit log monthly.
Restrict egress to the LLM endpoints you use and run code evaluators through the production dispatcher.

Langfuse Security Guide: Hardening Self Hosted LLM Tracing