Skip to content

docs: clarify cloud security model #3197

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
AkioNuernberger wants to merge 1 commit into
base: main
Choose a base branch
from
+45 −13
Open

docs: clarify cloud security model #3197

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 12 additions & 2 deletions content/security/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,16 @@

<CredibilitySentence />

## Langfuse Cloud security model

Langfuse Cloud is a fully managed, multi-tenant SaaS deployment. The security model combines three layers:

- **Security posture:** The production service is based on the same open-source Langfuse codebase, is covered by SOC 2 Type II and ISO 27001 audits, and undergoes annual third-party penetration tests. You can request the latest reports [here](/request-security-docs).
- **Tenant isolation:** All product data is scoped to a project. Every record is associated with a `projectId`, API keys are project-scoped, and authenticated requests are authorized through RBAC before queries are made. See the [Security FAQ](/security/security-faq) and [RBAC docs](/docs/administration/rbac).
- **Customer controls:** Teams can reduce what reaches Langfuse and how long it stays there with [masking](/docs/observability/features/masking), [data retention](/docs/administration/data-retention), [data deletion](/docs/administration/data-deletion), region selection, SSO/SCIM, and audit logs.

Langfuse Cloud runs on AWS and ClickHouse Cloud in isolated regional environments. Supporting services such as Postgres, ClickHouse, Redis, and S3 are covered by the same cloud security program: private network placement, least-privilege service access, encryption at rest and in transit, monitoring, and vendor/compliance review. If your requirements mandate infrastructure-level isolation in your own account or VPC, use [self-hosted Langfuse](/self-hosting) or contact us about Enterprise options.

Check warning on line 32 in content/security/index.mdx

View check run for this annotation

Claude / Claude Code Review

Inconsistent SOC 2 / ISO 27001 spelling in same document 

Nit: this doc now uses two different spellings of the same certifications. The new section at line 28 uses the canonical "SOC 2 Type II and ISO 27001" (matching the Cards block at lines 43/49), but the pre-existing intro paragraph at line 11 still reads "SOC2 Type 2 and ISO27001". Consider updating line 11 to the canonical form for consistency within the same document.

@greptile-apps greptile-apps Bot Jun 27, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 ClickHouse is listed twice in the same sentence — first as a primary platform ("AWS and ClickHouse Cloud") and then again in the "supporting services" enumeration ("Postgres, ClickHouse, Redis, and S3"). This is internally contradictory and may confuse readers about ClickHouse's role. Since ClickHouse Cloud is already highlighted as a primary platform component, it should be omitted from the supporting services list.

Suggested change
Langfuse Cloud runs on AWS and ClickHouse Cloud in isolated regional environments. Supporting services such as Postgres, ClickHouse, Redis, and S3 are covered by the same cloud security program: private network placement, least-privilege service access, encryption at rest and in transit, monitoring, and vendor/compliance review. If your requirements mandate infrastructure-level isolation in your own account or VPC, use [self-hosted Langfuse](/self-hosting) or contact us about Enterprise options.
Langfuse Cloud runs on AWS and ClickHouse Cloud in isolated regional environments. Supporting services such as Postgres, Redis, and S3 are covered by the same cloud security program: private network placement, least-privilege service access, encryption at rest and in transit, monitoring, and vendor/compliance review. If your requirements mandate infrastructure-level isolation in your own account or VPC, use [self-hosted Langfuse](/self-hosting) or contact us about Enterprise options.
Prompt To Fix With AI 
This is a comment left during a code review.
Path: content/security/index.mdx
Line: 32

Comment:
ClickHouse is listed twice in the same sentence — first as a primary platform ("AWS and ClickHouse Cloud") and then again in the "supporting services" enumeration ("Postgres, ClickHouse, Redis, and S3"). This is internally contradictory and may confuse readers about ClickHouse's role. Since ClickHouse Cloud is already highlighted as a primary platform component, it should be omitted from the supporting services list.

```suggestion
Langfuse Cloud runs on AWS and ClickHouse Cloud in isolated regional environments. Supporting services such as Postgres, Redis, and S3 are covered by the same cloud security program: private network placement, least-privilege service access, encryption at rest and in transit, monitoring, and vendor/compliance review. If your requirements mandate infrastructure-level isolation in your own account or VPC, use [self-hosted Langfuse](/self-hosting) or contact us about Enterprise options.
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Comment on lines +24 to +32

@claude claude Bot Jun 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Nit: this doc now uses two different spellings of the same certifications. The new section at line 28 uses the canonical "SOC 2 Type II and ISO 27001" (matching the Cards block at lines 43/49), but the pre-existing intro paragraph at line 11 still reads "SOC2 Type 2 and ISO27001". Consider updating line 11 to the canonical form for consistency within the same document.

Extended reasoning...

What the inconsistency is

After this PR, content/security/index.mdx contains two different spellings of the same compliance certifications within ~15 lines of each other:

  • Line 11 (unchanged by this PR): "annual SOC2 Type 2 and ISO27001 audits"
  • Line 28 (added by this PR): "covered by SOC 2 Type II and ISO 27001 audits"
  • Lines 43/49 (pre-existing Cards block): "SOC 2 Type II" and "ISO 27001"

The new section the PR adds uses the same canonical form as the Cards block and as security-faq.mdx, so this PR creates a within-document inconsistency between two adjacent paragraphs describing the exact same certifications.

Step-by-step proof

  1. Open content/security/index.mdx after this PR is applied.
  2. Read line 11: "annual SOC2 Type 2 and ISO27001 audits as well as External Penetration Tests".
  3. Scroll ~15 lines down to the new "Langfuse Cloud security model" section (line 28): "covered by SOC 2 Type II and ISO 27001 audits".
  4. Scroll down to the Cards block (lines 43, 49): titles read "SOC 2 Type II" and "ISO 27001".
  5. Result: same document, same certifications, two different spellings.

Addressing the refutation

A verifier argued that this is out of scope because the PR did not create the inconsistency (line 11 was already inconsistent with the pre-existing Cards block). That is technically correct, but the PR does surface and worsen the inconsistency by adding a third occurrence within the same file, in a brand-new paragraph located just above the older one. A reader skimming the security overview will now see "SOC2 Type 2" and "SOC 2 Type II" in close visual proximity, which looks careless even though both forms are understandable. A one-line edit to line 11 (changing "SOC2 Type 2 and ISO27001" to "SOC 2 Type II and ISO 27001") would resolve the issue and align the entire file with the canonical form already used elsewhere.

Impact and fix

Impact is purely cosmetic — there is no factual or functional issue, and a reader will understand both forms identically. The fix is a one-line edit to the pre-existing intro paragraph (line 11) to use the canonical spelling. This is flagged as a nit, not a blocker.


## Compliance

We maintain [internal policies](/security/policies) and adhere to several industry-standard compliance frameworks. Please check [Security FAQs](/security/security-faq) for more details.
Expand Down Expand Up @@ -67,13 +77,13 @@

### What deployment models are available?

- **Langfuse Cloud** – fully‑managed SaaS (multi‑tenant) with US, EU and HIPAA data regions
- **Langfuse Cloud** – fully‑managed SaaS (multi‑tenant) with US, EU, Japan, and HIPAA data regions
- **Self‑hosted OSS** – MIT‑licensed software that you can deploy on your own infrastructure
- **Self‑hosted Enterprise Edition** – commercial license with additional security/compliance features and vendor support.

### Which cloud provider and regions do you use?

Langfuse Cloud mainly runs on **AWS and Clickhouse via AWS**:
Langfuse Cloud mainly runs on **AWS and ClickHouse Cloud**:

- **US & HIPAA region**: us-west-2 (Oregon)
- **EU region**: eu-west-1 (Ireland)
Expand Down
44 changes: 33 additions & 11 deletions content/security/security-faq.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,19 +21,31 @@

> **What retention, deletion and export controls exist?**

Each project can set its own retention window; data older than that is purged nightly, and users/API can trigger immediate deletion or export. See [data retention](/docs/data-retention) and [data deletion](/docs/data-deletion) documentation.
Each project can set its own retention window; data older than that is purged nightly, and users/API can trigger immediate deletion or export. See [data retention](/docs/administration/data-retention) and [data deletion](/docs/administration/data-deletion) documentation.

> **How should I evaluate Langfuse Cloud's multi-tenant security model?**

Multi-tenancy is the standard operating model for modern SaaS products. The relevant security question is whether tenant isolation is explicit, consistently enforced, and independently tested. Langfuse Cloud combines project-scoped data isolation, project-scoped API keys, RBAC authorization, encrypted infrastructure, continuous monitoring, and annual third-party penetration tests. For most teams, this provides a strong balance of security, time to value, product experience, and operational reliability because Langfuse operates the full application and infrastructure stack.

If your internal policy requires infrastructure-level isolation, customer-operated networking, or a customer-controlled database boundary, use [self-hosted Langfuse](/self-hosting) or discuss Enterprise Cloud options with us.

> **Can I deploy Langfuse in a single-tenant environment?**

Langfuse Cloud is multi-tenant only. For strict infrastructure-level isolation, we recommend Self-hosting Langfuse.
Langfuse Cloud is multi-tenant. For strict infrastructure-level isolation, we recommend self-hosting Langfuse. Self-hosted Enterprise deployments can be paired with your preferred ClickHouse deployment, including ClickHouse Cloud, but your team owns the networking, scaling, upgrades, backups, and operational controls.

> **How is tenant isolation enforced?**

Logical data isolation is technically achieved by associating every piece of data with a specific projectId and pen-tested yearly. This unique identifier acts as a key to partition data within the database, ensuring that all information, from traces and observations to scores and datasets, is explicitly linked to a single project. Access to other projects' data is prevented through a role-based access control (RBAC) system built on ProjectMembership. Users are granted access to projects through these memberships, each of which defines their role and permissions within that specific project. See [RBAC documentation](/docs/rbac) for more details. The application logic then uses the user's authenticated session to filter all database queries by their authorized projectIds, effectively creating a secure wall between different projects' data.
Logical data isolation is technically achieved by associating every piece of data with a specific `projectId`. This unique identifier acts as a key to partition data within the database, ensuring that all information, from traces and observations to scores and datasets, is explicitly linked to a single project. Access to other projects' data is prevented through a role-based access control (RBAC) system built on project memberships. Users are granted access to projects through these memberships, each of which defines their role and permissions within that specific project. See [RBAC documentation](/docs/administration/rbac) for more details. The application logic then uses the user's authenticated session to filter all database queries by their authorized project IDs. The tenant boundary is included in Langfuse's annual third-party penetration tests.

> **How does Langfuse Cloud compare with running Langfuse yourself on ClickHouse Cloud?**

Langfuse Cloud uses ClickHouse Cloud as part of the managed backend, so customers benefit from ClickHouse Cloud's infrastructure security while Langfuse operates the application, control plane, queues/cache, object storage, database integrations, upgrades, backups, and incident response. This is the recommended path when you want the fastest setup and the least operational overhead.

Running self-hosted Langfuse with your own ClickHouse Cloud environment gives your team direct ownership of network topology, database configuration, and infrastructure policies. This can be the right model when a customer policy requires a customer-controlled VPC, private connectivity managed by the customer, or a dedicated database boundary, but it comes with higher cost and operational responsibility.

> **Can customers pin data to specific regions?**

Yes. EU, US and HIPAA‑ready US zones are available, and self‑hosted deployments let you choose any region and infrastructure.
Yes. EU, US, Japan, and HIPAA-ready US regions are available. Langfuse Cloud regions are separated from each other, and self-hosted deployments let you choose any region and infrastructure.

## Identity & Access Management

Expand All @@ -51,21 +63,31 @@

> **How is least‑privilege enforced?**

RBAC lets you scope roles to organisation or project. See [RBAC documentation](/docs/rbac) for more details.
RBAC lets you scope roles to organization or project. See [RBAC documentation](/docs/administration/rbac) for more details.

## Infrastructure & Network Security

> **Where is Langfuse Cloud hosted and how is the perimeter protected?**

Langfuse runs on AWS in isolated VPCs with WAF and AWS Shield for DDoS mitigation.

> **Do supporting services such as Redis introduce additional tenant-isolation concerns?**

Langfuse Cloud uses several managed backing services, including Postgres, ClickHouse, Redis/ElastiCache, and S3. These services are not exposed directly to customers and are accessed by Langfuse services using least-privilege credentials inside isolated regional environments. Stored data is encrypted, activity is monitored, and the service providers are covered by vendor risk management and compliance review.

The tenant boundary remains the Langfuse application and data model: product data is scoped by `projectId`, API keys are project-scoped, and every user request is authorized through RBAC. Supporting infrastructure is part of that controlled service architecture rather than a separate customer-operated surface.

> **Does Langfuse Cloud support AWS PrivateLink or private connectivity?**

Public regional endpoints are the default for Langfuse Cloud. AWS PrivateLink can be enabled for Enterprise customers on committed contracts; contact enterprise@langfuse.com or security@langfuse.com to discuss region availability and onboarding. If you need private connectivity in infrastructure fully controlled by your team, self-hosting gives you that control.

> **What security headers are implemented on Langfuse endpoints?**

We enforce CSP (Content Security Policy), HSTS (HTTP Strict Transport Security), and X-Frame-Options on all endpoints including [langfuse.com](https://domsignal.com/test/ea3amc5z08sh6fnovjek392ihxrb66q6) and [cloud.langfuse.com](https://domsignal.com/test/spdnv4cx0949ah3nvz5b5eapab8o2390).

> **How does Langfuse Cloud monitor its environment?**

Langfuse uses DataDog and Sentry to monitor its application and environments. All cloud audit logs are automatically written into a seperate, locked-down account. In addition, we have automated systems in place to alert us about anomalous usage.
Langfuse uses DataDog and Sentry to monitor its application and environments. All cloud audit logs are automatically written into a separate, locked-down account. In addition, we have automated systems in place to alert us about anomalous usage.

> **What anomaly detection and security alerting capabilities are in place?**

Expand All @@ -81,7 +103,7 @@

> **How often does Langfuse rotate its API keys?**

Langfuse uses short-lived api keys where possible. For long-lived API keys we rotate them every 90 days.
Langfuse uses short-lived API keys where possible. For long-lived API keys we rotate them every 90 days.

## Software Development Lifecycle

Expand Down Expand Up @@ -140,8 +162,8 @@
## Customer Controls & Shared Responsibility for Self-hosted Langfuse

> **Which obligations stay with the customer when I am self-hosting?**

Check warning on line 165 in content/security/security-faq.mdx

View check run for this annotation

Claude / Claude Code Review

Self-hosted obligations link points to off-topic page 

The new link target [/self-hosting/security/deployment-strategies](/self-hosting/security/deployment-strategies) is about single- vs. multi-deployment topology (RBAC, VPC peering, cost trade-offs) and does not cover any of the listed customer obligations (endpoint security, webhook hardening, backups, monitoring, IAM hygiene). Consider linking to a more topical page such as `/self-hosting/security/networking`, the backup guide already referenced in the next FAQ entry, or simply dropping the trai

@claude claude Bot Jun 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 The new link target /self-hosting/security/deployment-strategies is about single- vs. multi-deployment topology (RBAC, VPC peering, cost trade-offs) and does not cover any of the listed customer obligations (endpoint security, webhook hardening, backups, monitoring, IAM hygiene). Consider linking to a more topical page such as /self-hosting/security/networking, the backup guide already referenced in the next FAQ entry, or simply dropping the trailing "See ... for more details" clause.

Extended reasoning...

What the issue is

The FAQ entry at content/security/security-faq.mdx:165 reads:

Endpoint security, webhook endpoint hardening, backups, monitoring, and IAM hygiene on your side remain your responsibility. See the self-hosted deployment strategies for more details.

The linked page does not provide more detail on any of those five obligations. I read content/self-hosting/security/deployment-strategies.mdx end-to-end: its scope is choosing between a single Langfuse deployment vs. one deployment per project/environment, RBAC, VPC peering, scalability, and a cost/complexity comparison table. A grep for endpoint|webhook|backup|monitoring|IAM against that file returns zero hits, and meta.json in /self-hosting/security/ confirms there is no consolidated "self-hosting security overview" page that covers the listed obligations.

Step-by-step proof

  1. Reader sees the FAQ promise: "Endpoint security, webhook endpoint hardening, backups, monitoring, and IAM hygiene ... See the self-hosted deployment strategies for more details."
  2. Reader clicks the link and lands on a page whose first heading is "Deployment Strategies" and whose summary describes "strategies for handling multiple projects and environments."
  3. None of endpoint security, webhook hardening, backups, monitoring, or IAM hygiene appear on that page. Backups in particular have a dedicated page (/self-hosting/configuration/backups) that the very next FAQ entry already links to — strong evidence that deployment-strategies is not where those topics live.
  4. The reader either bounces or scrolls the wrong page hoping to find the promised detail.

Addressing the refutation

A verifier argued this is non-actionable because (a) the previous link (/docs/security/overview) was broken and (b) "See ... for more details" links are conventionally broad. Both points are fair, and they are exactly why this is filed as a nit rather than a blocking issue: the PR does not introduce a regression and the new link at least lands on a real page in the self-hosting/security section. But the new link is still demonstrably mismatched — five named obligations, zero of which are discussed at the target — so the small docs polish opportunity is worth surfacing while the author is in the file. Either picking a closer target (e.g., /self-hosting/security/networking or the backups guide) or removing the "See ... for more details" clause would fully resolve it.

Suggested fix

  • Option A (lowest churn): drop "See the [self-hosted deployment strategies] for more details." — the obligations list is self-contained.
  • Option B: link to the backup guide already referenced one entry below, since backups are the largest of the named obligations: See the [self-hosting backup guide](/self-hosting/configuration/backups) for more details on backups.
  • Option C: split into multiple targeted links (networking for endpoint/webhook hardening, backups for backups, etc.).

Endpoint security, webhook endpoint hardening, backups, monitoring, and IAM hygiene on your side remain your responsibility. See [security overview](/docs/security/overview) for more details.
Endpoint security, webhook endpoint hardening, backups, monitoring, and IAM hygiene on your side remain your responsibility. See the [self-hosted deployment strategies](/self-hosting/security/deployment-strategies) for more details.

> **How should my backup strategy look like when I am self-hosting?**

Expand All @@ -159,12 +181,12 @@

> **Can long‑term retention be disabled?**

Yes. While data is stored indefinitely by default, you can configure custom [data retention](/docs/data-retention) policies per project.
Yes. While data is stored indefinitely by default, you can configure custom [data retention](/docs/administration/data-retention) policies per project.

> **Is prompt/trace data ever used for benchmarking or training?**

No. Langfuse does not repurpose customer data for external benchmarks or model training. See [security overview](/docs/security/overview) for more details.
No. Langfuse does not repurpose customer data for external benchmarks or model training. See [AI features](/security/ai-features) for more details on how optional AI-powered features handle data.

> **Do you ever use customer data to train models or analytics?**

No. Customer traces and prompts are processed only to provide the Langfuse service and are never used to train internal or third‑party ML models. See [security overview](/docs/security/overview) for more details.
No. Customer traces and prompts are processed only to provide the Langfuse service and are never used to train internal or third-party ML models. See [AI features](/security/ai-features) for more details on how optional AI-powered features handle data.
Loading