docs: clarify cloud security model

[AkioNuernberger]

Greptile Summary

This PR expands the security documentation to clarify Langfuse Cloud's multi-tenant security model and add new FAQ entries covering topics like Redis/ElastiCache tenant isolation, AWS PrivateLink availability, and a side-by-side comparison of Langfuse Cloud vs. self-hosted on ClickHouse Cloud. It also updates several internal doc links (e.g., /docs/rbac → /docs/administration/rbac) and fixes minor copy issues (typo "seperate", capitalization of "API keys", "organisation" → "organization").

• New content sections add clarity on tenant isolation enforcement, the Japan region, PrivateLink availability for Enterprise customers, and how ClickHouse Cloud fits into the managed vs. self-hosted choice.
• Link corrections align references to new URL paths (/docs/administration/data-retention, /docs/administration/rbac, /self-hosting/security/deployment-strategies, /security/ai-features) across both files.

Confidence Score: 4/5

Documentation-only change with clear, well-structured additions; safe to merge after addressing the minor content and formatting notes.

Both files contain only prose and MDX markup — no executable code paths are affected. The main items worth a second look are ClickHouse appearing both as a primary platform and as a supporting service in the same sentence (potentially confusing to security reviewers), and two newly added email addresses missing the backtick wrapping required to prevent platform mention interpretation. Neither blocks correctness of the security model being described.

content/security/index.mdx (ClickHouse listed twice in the cloud model paragraph) and content/security/security-faq.mdx (email addresses without backticks on the PrivateLink answer).

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Customer Request] --> B{Authentication}
    B -->|API Key| C[Project-scoped API Key Validation]
    B -->|Session| D[JWT / OIDC SSO Session]
    C --> E{RBAC Authorization}
    D --> E
    E -->|Authorized| F[Application Layer]
    E -->|Denied| G[403 Rejected]

    F --> H[Filter by projectId]
    H --> I[(Postgres)]
    H --> J[(ClickHouse Cloud)]
    H --> K[(S3 Object Storage)]
    H --> L[(Redis / ElastiCache)]

    subgraph Langfuse Cloud - AWS Region
        F
        H
        I
        J
        K
        L
    end

    subgraph Monitoring & Compliance
        M[DataDog / Sentry]
        N[AWS GuardDuty]
        O[SOC 2 Type II & ISO 27001]
    end

    F --> M
    F --> N

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Customer Request] --> B{Authentication}
    B -->|API Key| C[Project-scoped API Key Validation]
    B -->|Session| D[JWT / OIDC SSO Session]
    C --> E{RBAC Authorization}
    D --> E
    E -->|Authorized| F[Application Layer]
    E -->|Denied| G[403 Rejected]

    F --> H[Filter by projectId]
    H --> I[(Postgres)]
    H --> J[(ClickHouse Cloud)]
    H --> K[(S3 Object Storage)]
    H --> L[(Redis / ElastiCache)]

    subgraph Langfuse Cloud - AWS Region
        F
        H
        I
        J
        K
        L
    end

    subgraph Monitoring & Compliance
        M[DataDog / Sentry]
        N[AWS GuardDuty]
        O[SOC 2 Type II & ISO 27001]
    end

    F --> M
    F --> N

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
content/security/security-faq.mdx:82
Email addresses containing `@` are not wrapped in backticks, which means the platform will attempt to interpret them as user mentions and the rendered output may be garbled or broken. Per the project's formatting guidance, all `@` symbols outside of code fences must be in backticks.

```suggestion
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.
```

### Issue 2 of 2
content/security/index.mdx:32
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.
```

_{Reviews (1): Last reviewed commit: "docs: clarify cloud security model" | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
langfuse-docs	Ready	Preview, Comment	Jun 27, 2026 1:26am

[github-actions]

@claude review

[greptile-apps]

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!

[claude]

LGTM — docs-only clarifications to the cloud security overview and FAQ, with broken doc links fixed along the way.

Extended reasoning...

Overview

This PR updates two MDX docs files (content/security/index.mdx and content/security/security-faq.mdx) to clarify Langfuse Cloud's multi-tenant security model. It adds a new top-level "Langfuse Cloud security model" section to the overview, expands the FAQ with new entries on multi-tenancy evaluation, ClickHouse Cloud comparison, supporting services isolation, and PrivateLink, fixes several broken doc links (/docs/rbac → /docs/administration/rbac, /docs/data-retention → /docs/administration/data-retention, etc.), adds Japan region mentions, and fixes a few typos (seperate → separate, api keys → API keys).

Security risks

None. This is a documentation-only change to MDX content — no code, configuration, auth, or runtime behavior is touched. The content describes existing security posture rather than changing it.

Level of scrutiny

Low. Pure docs edits in content/security/*.mdx warrant a light review. The link rewrites all follow patterns already used elsewhere in the file (e.g., /docs/administration/rbac matches the canonical location), and the new FAQ content aligns with already-public claims (regions, SOC 2 / ISO 27001, AWS hosting).

Other factors

The bug hunting pass surfaced two nits (a within-file SOC 2 / ISO 27001 spelling inconsistency the PR slightly worsens, and a "see deployment-strategies for more details" link that doesn't actually cover the obligations listed). Both are cosmetic and posted as inline comments — neither blocks merging.

[claude]

🟡 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.

[claude]

🟡 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.).