⚠️ Dieses Pattern ist seit 2026-05-12 abgeloest durch open-webui-fargate-bedrock. Begruendung im Frontmatter (superseded_reason). Bleibt erhalten fuer ggf. Bestandskunden und als Vergleichs-Referenz, keine neuen Setups mehr nach diesem Pattern.

LibreChat + Railway + Bedrock + Live-Files (Multi-User)

Architektur-Pattern für ein eigenes Chat-System mit mehreren Usern, gemeinsam genutzten Files (Live-Sync) und DSGVO-konformer Datenverarbeitung. Erstmals erforscht für Vibe Factory (5 User, 850 GB SharePoint, Bedrock EU). Quell-Recherche mit Step-by-Step-Plan: ../../runs/2026-04-26-research-librechat-vf-multiuser/01-bericht.md.

Wann dieser Stack vs. claude-dsgvo-setup.md

Frageclaude-dsgvo-setup.mddieses Pattern
Anzahl User1 (Solo)2-20 (Team)
HostingHetzner / lokal DockerRailway (PaaS)
File-Modellper-User-UploadShared Live-Files via SharePoint/M365
AuthEmail-RegMicrosoft Entra OpenID (Tenant-Pin)
Setup-Zeit Erstinstallation20-30 min1-2 Wochen (Phase 0-5 inkl. Live-Files)
Pricing5-20 €/Monat (Solo)35-75 USD/Monat (Team, exkl. Token)

Faustregel: Solo + nur eigene Daten → claude-dsgvo-setup.md. Team + geteilte Files (insbesondere existierender M365-Tenant) → dieses Pattern.

Stack-Komponenten (gepinnt)

KomponenteVersionRolle
LibreChatghcr.io/danny-avila/librechat-dev:v0.8.5 (nicht latest)Chat-UI + MCP-Host
librechat.yaml Schema1.3.5Config
MongoDBmongo:7.0 (nicht latest)Conversations
Meilisearchv1.11.3 (Template-Default)Volltext-Suche
RAG API + PGVectorTemplate-DefaultDocument-Embeddings
Bedrock-Regioneu-central-1 (Frankfurt)LLM (DSGVO-Default)
Bedrock-IDseu.anthropic.claude-{opus-4-7,sonnet-4-6,haiku-4-5} (CRIS-Profile)Modelle
StorageCloudflare R2 EU (S3-kompatibel)Pflicht — Railway-FS ist ephemeral
AuthMicrosoft Entra OpenID + Tenant-PinOnboarding gekoppelt an M365
Railway-PlanPro (20 USD/Mo)Hobby-Limit von 3 Containern reicht nicht
Railway-Regioneurope-west4-drams3a (Amsterdam)Latenz zu eu-central-1
MCP-Transportstreamable-httpMit User-Identity-Headers

Architektur

flowchart TB
    Users["5 User<br/>(Browser)"]

    subgraph Railway["Railway (Amsterdam EU)"]
        LC["LibreChat v0.8.5<br/>+ Mongo + Meili + RAG + PGVector"]
    end

    subgraph Bedrock["AWS Bedrock eu-central-1"]
        Claude["Claude Opus/Sonnet/Haiku 4.x<br/>via eu.anthropic.claude-...<br/>EU geographic CRIS"]
    end

    subgraph MCPLayer["MCP-Layer (Mono-Container)"]
        M365["mcp-m365 v0.3<br/>delegated OAuth pro User<br/>~35 Tools (read+write)"]
        TP["mcp-ticketpay"]
        PK["mcp-papierkram"]
    end

    subgraph M365Cloud["Microsoft 365 Tenant"]
        SP[("SharePoint<br/>Co-Auth nativ")]
        EX[("Excel Online<br/>workbook-session-id")]
    end

    Users -- HTTPS --> LC
    LC -- "Bedrock SDK" --> Claude
    LC -- "streamable-http<br/>X-LibreChat-User-Id" --> M365
    LC -- streamable-http --> TP
    LC -- streamable-http --> PK
    M365 -- "Bearer (delegated, per User)" --> SP
    M365 -- "PATCH workbook/range<br/>workbook-session-id" --> EX

Kern-Mechanik: User-Identität durch den Stack

Das ist die zentrale Idee dieses Patterns: Multi-User-Logik liegt nicht in LibreChat, sondern im MCP. LibreChat injectet seit v0.7.9 in jeden MCP-Request automatisch Header-Substitution:

mcpServers:
  m365:
    type: streamable-http
    url: "http://mcp-m365.railway.internal:8765/mcp"
    headers:
      X-LibreChat-User-Id: "{{LIBRECHAT_USER_ID}}"
      X-LibreChat-User-Email: "{{LIBRECHAT_USER_EMAIL}}"
      X-LibreChat-User-Role: "{{LIBRECHAT_USER_ROLE}}"

Der MCP entscheidet dann pro Request welchen Token er gegen das Backend benutzt, welche Audit-Zeile geschrieben wird und welcher Storage-Bereich sichtbar ist. Alle 5 User sehen dieselbe MCP-URL — was sie tun können, kontrolliert der MCP.

Live-Files: Warum SharePoint + mcp-m365, nicht LibreChat-Upload

LibreChat hat keinen nativen shared-files-Pool (Discussion #8611 trackt das, nicht implementiert). File-Uploads sind per ACL an den User gebunden, RAG ist per-Upload. Konsequenz: Live-Files muss ein externer File-Pool sein, exposed via MCP.

Bei Kunden mit existierendem M365-Tenant (wie VF) ist die saubere Antwort:

  1. SharePoint als Single-Source-of-Truth (Co-Auth, Versions-Historie, Sync-Clients sind native)
  2. mcp-m365 v0.3 als Schreib-fähiger MCP über Microsoft Graph
  3. Delegated OAuth pro User statt App-only — Audit-Trails zeigen den echten User

Ausgangsbasis ist das vorhandene ~/source/mcps/mcp-m365 (24 Tools v0.2.0, read-only + bestehende Tools write_excel_range, add_excel_worksheet). Die v0.3-Erweiterung (~10 Schreib-Tools + delegated OAuth-Layer) ist 1-2 Tage Aufwand. Rule-18 in Reinform: vorhandenes Tool erweitern, kein neues System bauen.

Excel-Concurrency — die scharfe Kante

Microsoft Graph hat kein echtes Live-Co-Auth für Excel. Concurrent Writes werden serialisiert oder werfen Conflict-Errors. Workaround:

POST /sites/{site-id}/drive/items/{item-id}/workbook/createSession
Body: { "persistChanges": true }
→ Header workbook-session-id: <session-id> auf alle PATCH/POST
→ Session expired nach ~5 min Inaktivität
→ POST .../workbook/closeSession am Ende

Folgerung für mcp-m365 v0.3: Tool-Familie excel_open_session / excel_set_range(...,session_id) / excel_close_session. Praktische Implikation für Kunden-Teams: Excel-Files die der Agent gerade bearbeitet, im Browser zumachen — oder topografisch trennen in „Agent-Files” und „Human-Files”. Microsoft Excel Best Practices.

Berechtigungen für mcp-m365 v0.3

Delegated Permissions (nicht App-only): Files.ReadWrite.All, Sites.ReadWrite.All, User.Read, optional Mail.Send. Admin-Consent durch Tenant-Admin einmalig. Login-Flow pro User über LibreChats built-in OAuth-2.0-MCP-Pattern (MCP antwortet 401, LibreChat zeigt „Authenticate”-Button, Token persistent gespeichert).

Decision-Forks

ForkEmpfehlungWenn anders
Regioneu-central-1 (Cloud Act minimiert)USA: DPIA + CMK + No-Logs + Datenminimierung dokumentieren
File-Layermcp-m365 erweitern (~1-2 Tage)Softeria/ms-365-mcp-server Drop-In; Nextcloud nur bei EU-Sovereign-Vorgabe (+850-GB-Migration)
AuthMicrosoft Entra OpenID Tenant-PinEmail-Reg + 1h ALLOW_REGISTRATION=true als Bootstrap
MCP-TopologieMono-Container (FastMCP-Mount, mehrere Sub-Apps)Separate Services: +20 USD/Mo + bessere Lifecycle-Trennung
PersistenceCloudflare R2 EUAWS S3 EU oder Azure Blob (wenn schon im Tenant)

Bekannte Quirks (Pflicht-Mitigation)

QuirkMitigationQuelle
LibreChat Memory-Leak nach 1-2 WochenNODE_OPTIONS=--max-old-space-size=4096 + wöchentlicher Auto-Restart via Railway-Cron#3445
Mongo-Crash bei zu kleinem Volumemin. 5 GB, lieber 10 GB; Image pinnen mongo:7.0Railway-Station
Hobby-Plan max. 3 ContainerPro-Plan einplanen (Template alleine zieht 5)Railway Pricing
uploads/ ephemeral auf RailwayS3/R2 PflichtLibreChat-Doku
librechat.yaml nicht hot-reloadedService-Restart nach Edit, CONFIG_PATH auf Volume oder GitHub-URL#5162
ENDPOINTS-Env auf Railway ignoriertEndpoints in librechat.yaml pflegen, nicht via .env#5584
MCP-Tools nach Hinzufügen unsichtbarContainer-Restart nach MCP-Tool-Änderung#7117
Bedrock-Modell-IDs ohne Prefix scheiterneu.anthropic.claude-... (oder us.), nie nackte anthropic.claude-...LibreChat AWS-Doku
Tools brauchen Agents-Endpoint, nicht Bedrock-direktUser wählt „Agent” in UI#11728
Excel-Concurrency-ConflictsSession-Pattern + Schulung „Datei vor Agent-Edit zumachen”Excel Best Practices

Wenn doch USA (Bedrock us-east-1 statt eu-central-1)

Es gibt Stand 2026-04-26 keinen technischen Grund für USA — alle Claude 4.x-Modelle laufen via EU CRIS (eu.anthropic.claude-...) aus eu-central-1, identisches Pricing, EU-Quotas reichen für Team-Workloads. Falls es trotzdem USA sein soll (Marketing-Positionierung, US-Vertragslage o.ä.), zwingend mit:

  1. DPIA / Transfer Impact Assessment schreiben — explizit warum US-Region
  2. Regional Endpoint (us.anthropic.claude-...), niemals global.anthropic.claude-...
  3. CMK in eu-central-1 KMS für persistierte Bedrock-Ressourcen
  4. No-Logs-Policy (Bedrock model invocation logging aus oder in EU-Bucket)
  5. Datenminimierung / PII-Pseudonymisierung in Prompts, Prompt-Hygiene-Schulung beim Kunden
  6. VVT-Eintrag: AWS USA als Sub-Processor, DPF + SCCs als Rechtsgrundlage
  7. Datenschutzhinweis für Endkunden — KI-Verarbeitung in US-Cloud transparent

Alternative Maximalsicherheit: AWS European Sovereign Cloud (eusc-de-east-1, Brandenburg, seit 2026-01-15). Architektonisch außerhalb Cloud Act, aber Bedrock-Modell-Verfügbarkeit dort ist limitiert — konkret prüfen vor Commitment.

Pin-Liste (für Repo-Konstanten)

librechat_image: "ghcr.io/danny-avila/librechat-dev:v0.8.5"
librechat_yaml_schema: "1.3.5"
mongo_image: "mongo:7.0"
bedrock_region: "eu-central-1"
bedrock_models:
  workhorse: "eu.anthropic.claude-sonnet-4-6"
  heavy: "eu.anthropic.claude-opus-4-7"
  cheap: "eu.anthropic.claude-haiku-4-5"
railway_plan: "Pro"
railway_region: "europe-west4-drams3a"
mcp_transport: "streamable-http"
mcp_m365_target_version: "0.3.0+marvin.1"
mcp_m365_required_permissions:
  - "Files.ReadWrite.All (delegated)"
  - "Sites.ReadWrite.All (delegated)"
  - "User.Read"
  - "Mail.Send (optional)"
storage_provider: "Cloudflare R2 (EU)"
auth_provider: "Microsoft Entra OpenID (Tenant-Pin)"

Cost-Tabelle (5 User, mittlere Last)

SzenarioContainerRAMVolumeUSD/Mo (Railway)
Lite (LibreChat + Mongo, kein RAG, kein MCP)22 GB5 GB~32
Standard (Voll-Template ohne MCP)54 GB17 GB~57
Voll mit Mono-MCP64,5 GB17 GB~67 (empfohlen)
Voll mit 5× separaten MCPs105,3 GB17 GB~85

Bedrock-Token-Kosten on-top: 5 User mit Sonnet-Workhorse typisch 5-30 USD/Mo. Sonnet 4.6 Regional (eu-central-1): 16.50/M Output.

DSGVO-Pflichtarbeit (zusätzlich zur Technik)

  • AVV zwischen Agentic Ventures (Auftragsverarbeiter) und Kunde (Verantwortlicher)
  • AWS GDPR DPA gilt automatisch global seit 2023-04 — kein separater Vertrag nötig (AWS Global DPA Update, PDF: aws-gdpr/AWS_GDPR_DPA.pdf)
  • VVT-Eintrag beim Kunden mit AWS EMEA SARL als Sub-Processor, Datenstandort eu-central-1
  • Datenschutzhinweis falls Kunde mit Endkunden-PII arbeitet (Tickets, Bestellungen) — KI-Verarbeitung transparent machen
  • DPIA nur bei USA-Region zwingend, bei EU-Region nice-to-have

Ausführlicher Compliance-Hintergrund: anthropic-datenschutz.md.