docs(security): document cross-region backup for Postgres#2844
docs(security): document cross-region backup for Postgres#2844Steffen911 wants to merge 1 commit intomainfrom
Conversation
Adds a Cross-Region Backup section to the data regions page describing Postgres snapshot replication to a secondary AWS region, ClickHouse and S3 non-replication caveats, and data-residency implications. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
@claude review |
|
|
||
| | Data store | Primary region | Secondary region | Mechanism | Retention | | ||
| |-------------------------------|--------------------------------------------------------------------------|---------------------------------------------------------|-------------------------------------------------------------------|------------------------| | ||
| | **Postgres** | EU: `eu-west-1` <br/> US / HIPAA: `us-west-2` <br/> JP: `ap-northeast-1` | `eu-central-1` <br/> `us-east-2` <br/> `ap-northeast-3` | AWS Backup daily snapshot copy, re-encrypted with a dedicated CMK | 14 days in each region | |
There was a problem hiding this comment.
The cross-region backup table introduces ap-northeast-1 / ap-northeast-3 as the Japan primary/secondary regions, but the ## Langfuse Cloud Regions table at the top of this page only lists US, EU, and HIPAA. A reader following the page top-to-bottom will have no indication that a JP region exists, making this row appear orphaned.
If the JP region is live, consider adding it to the Cloud Regions table. If it is not yet public, a brief parenthetical (e.g. "JP (private preview)") would avoid confusion.
Prompt To Fix With AI
This is a comment left during a code review.
Path: content/security/data-regions.mdx
Line: 69
Comment:
**JP region not listed in Cloud Regions table**
The cross-region backup table introduces `ap-northeast-1` / `ap-northeast-3` as the Japan primary/secondary regions, but the `## Langfuse Cloud Regions` table at the top of this page only lists US, EU, and HIPAA. A reader following the page top-to-bottom will have no indication that a JP region exists, making this row appear orphaned.
If the JP region is live, consider adding it to the Cloud Regions table. If it is not yet public, a brief parenthetical (e.g. "JP (private preview)") would avoid confusion.
How can I resolve this? If you propose a fix, please make it concise.|
Preview: |
|
|
||
| | Data store | Primary region | Secondary region | Mechanism | Retention | | ||
| |-------------------------------|--------------------------------------------------------------------------|---------------------------------------------------------|-------------------------------------------------------------------|------------------------| | ||
| | **Postgres** | EU: `eu-west-1` <br/> US / HIPAA: `us-west-2` <br/> JP: `ap-northeast-1` | `eu-central-1` <br/> `us-east-2` <br/> `ap-northeast-3` | AWS Backup daily snapshot copy, re-encrypted with a dedicated CMK | 14 days in each region | |
There was a problem hiding this comment.
🔴 The Cross-Region Backup table lists JP (ap-northeast-1 → ap-northeast-3) as an active primary/secondary pair, but JP is absent from the Cloud Regions table and other pages in the repo mark it as a "coming soon" / waitlist region. Enterprise readers reviewing the security page will see JP backup infrastructure described without any corresponding Cloud endpoint to connect it to, which is potentially misleading.
Extended reasoning...
What the bug is: The new Cross-Region Backup table added by this PR lists three primary regions — EU (eu-west-1), US/HIPAA (us-west-2), and JP (ap-northeast-1) — with corresponding secondary regions. The closing paragraph also states "All secondary regions are within the same legal jurisdiction … Japan ↔ Japan". However, the Langfuse Cloud Regions table earlier on the same page only documents three regions: US, EU, and HIPAA. There is no JP/Japan endpoint listed, and the "Connecting to a Region" section likewise has no JP base URL.
The specific code path: Lines 16–20 define the canonical Cloud Regions table. Line 69 (the Postgres row of the backup table) introduces JP: ap-northeast-1 and ap-northeast-3 as an active backup pair. Line 84 reinforces this with "Japan ↔ Japan" data residency language. No other part of data-regions.mdx introduces JP or explains how to access it.
Why existing content doesn't prevent confusion: The Cloud Regions table is the authoritative list of generally-available product endpoints. Because JP does not appear there, a reader has no way to know whether JP is available, in preview, on a waitlist, or entirely internal. The backup section presents JP on equal footing with EU and US/HIPAA, giving the impression it is a live region.
Impact: Two other files in the repository confirm JP is not yet launched: content/marketing/jp.mdx contains a callout stating "Langfuse Cloud 日本リージョンが近日公開！" (Japan region coming soon), and content/marketing/jp-cloud.mdx is a waitlist page with the description "Langfuse Cloud is coming to Japan. Join the waitlist for the Japan data region." Security-conscious enterprise readers — the primary audience of this page — who see a JP entry in the backup table but cannot find a JP product endpoint may be misled into believing a GA Japan region exists, or may become confused about Langfuse's actual product availability.
Step-by-step proof: (1) A prospective Japanese enterprise customer lands on /security/data-regions. (2) They scan the Cloud Regions table and find only US, EU, and HIPAA. (3) They scroll to the new Cross-Region Backup section and see "JP: ap-northeast-1" listed alongside EU and US/HIPAA as an active primary region. (4) They scroll to the closing paragraph and read "Japan ↔ Japan" data residency. (5) They return to the Cloud Regions section looking for a JP endpoint URL — it is not there. (6) They search other documentation and find only a waitlist page. The PR has introduced documentation that implies JP infrastructure is operational without providing any product-level context for it.
How to fix: Either (a) add a note in the backup table row (e.g., "JP — limited availability, see waitlist") and a matching callout in the Cloud Regions section, or (b) defer the JP backup row until the JP region is generally available and the Cloud Regions table can be updated simultaneously.
| | **Backup Layers** | Postgres: 7d retention. ClickHouse: 6-hourly backups (4d retention). S3: 7d versioning retention. | | ||
| | **Durability** | Encrypted backups stored across multiple availability zones within the primary region on AWS/ClickHouse Cloud; tested at least annually for restoration integrity. Postgres backups are additionally replicated to a secondary AWS region (see [Cross-Region Backup](#cross-region-backup) below). | |
There was a problem hiding this comment.
🟡 The PR's stated casing fix (Clickhouse → ClickHouse) is incomplete: line 10 of data-regions.mdx still reads "partly managed by Clickhouse" while all table entries and newly added content now correctly use "ClickHouse". Update line 10 to use "ClickHouse" to complete the fix.
Extended reasoning...
What the bug is: The PR description explicitly lists "Minor casing fix: Clickhouse → ClickHouse" as a deliverable. The diff correctly updates two table rows (lines 57–58) in the Business Continuity table and all newly added Cross-Region Backup content uses ClickHouse consistently. However, the introductory paragraph at line 10 — "Our database and application run on AWS infrastructure, partly managed by Clickhouse." — was not touched and still uses the old incorrect casing.
The specific code path: The file content/security/data-regions.mdx line 10 contains the string Clickhouse (lowercase 'h'). The PR diff only modified lines 54–87 (the Business Continuity table and the new Cross-Region Backup section). Line 10 falls outside the diff hunk and was never updated.
Why existing code doesn't prevent it: There is no automated lint or spell-check that enforces the correct ClickHouse capitalization, so the missed instance sailed through undetected. The PR author updated instances within the edited region of the file but missed the earlier occurrence in the intro paragraph.
Impact: After this PR is merged, the document contains inconsistent vendor name casing: Clickhouse in the intro (line 10) and ClickHouse throughout every table and the new section (lines 57, 58, 70, 76, 77, and more). Security and compliance pages are often reviewed by customers and auditors; misspelling or inconsistently casing a vendor name looks unprofessional.
How to fix: Change line 10 from:
Our database and application run on AWS infrastructure, partly managed by Clickhouse.
to:
Our database and application run on AWS infrastructure, partly managed by ClickHouse.
Step-by-step proof:
- The PR description states: "Minor casing fix:
Clickhouse→ClickHouse" - Open
content/security/data-regions.mdx(the only file changed in this PR) - Read line 10:
Our database and application run on AWS infrastructure, partly managed by Clickhouse.— old casing, not fixed - Read line 58 (updated by the diff):
| **Durability** | … on AWS/ClickHouse Cloud …— new casing, fixed - Read any new content in the Cross-Region Backup section, e.g., line 76:
ClickHouse stores historical traces…— new casing, consistent - Conclusion: line 10 is the sole remaining instance of the old casing, making the fix incomplete as stated in the PR description.
Summary
content/security/data-regions.mdxdescribing Postgres daily snapshot replication to a secondary AWS region per jurisdiction (EU ↔ EU, US ↔ US, JP ↔ JP), 14d retention, and re-encryption with a dedicated CMK.Clickhouse→ClickHouse.Test plan
pnpm devand visit/security/data-regions— verify the new### Cross-Region Backupsection renders under "Cloud (managed by Langfuse)" with the table and anchor#cross-region-backupworking.#cross-region-backupscrolls to the new section.🤖 Generated with Claude Code
Disclaimer: Experimental PR review
Greptile Summary
This PR adds a Cross-Region Backup section to the data-regions page, documenting that Postgres daily snapshots are replicated to a secondary AWS region within the same legal jurisdiction, while ClickHouse tracing data and S3 media are explicitly called out as non-replicated with clear data-loss implications. The
Clickhouse→ClickHousecasing fix is applied throughout the table but missed on line 10.Confidence Score: 5/5
Safe to merge — all findings are P2 documentation polish items that do not affect correctness or security.
All three comments are P2 (style/clarity): a missed casing fix, an undocumented JP region row, and ambiguous RTO wording. None block merge or introduce data-integrity or security risk.
content/security/data-regions.mdx — minor casing inconsistency on line 10, JP region not surfaced in the Cloud Regions table, and potentially contradictory RTO figures.
Important Files Changed
Clickhousecasing fix on line 10, JP region not surfaced in the Cloud Regions table, and RTO figures across two sections may appear contradictory to compliance readers.Flowchart
%%{init: {'theme': 'neutral'}}%% flowchart TD subgraph Primary["Primary AWS Region"] PG["Postgres\n(org, project, user,\nAPI keys, prompts…)"] CH["ClickHouse\n(traces, observations,\nscores)"] S3["S3 Media Bucket\n(uploaded media)"] end subgraph Secondary["Secondary AWS Region\n(same jurisdiction)"] PG2["Postgres Replica\n(daily snapshot copy\nre-encrypted CMK\n14d retention)"] CH2["❌ Not replicated"] S3_2["❌ Not replicated"] end PG -->|"AWS Backup\ndaily snapshot"| PG2 CH -.->|"no cross-region copy"| CH2 S3 -.->|"no cross-region copy"| S3_2 note1["EU: eu-west-1 → eu-central-1\nUS/HIPAA: us-west-2 → us-east-2\nJP: ap-northeast-1 → ap-northeast-3"] Secondary --- note1Prompt To Fix All With AI
Reviews (1): Last reviewed commit: "docs(security): document cross-region ba..." | Re-trigger Greptile