Agentic Ventures Wiki

VF Chat — Cutover von Open WebUI auf LobeChat (LobeHub)

10 Min. Lesezeit

VF Chat — Cutover Open WebUI → LobeChat

TL;DR

Wir ersetzen die Open WebUI-Instanz unter vf-chat.agenticventures.de durch LobeHub (LobeChat) v2.2.x im gleichen AWS-Account (av-production / eu-central-1). Stack-Form bleibt: Fargate hinter Cloudflare-Tunnel, RDS PostgreSQL als Datenbank, S3 fuer File-Uploads, Bedrock EU-CRIS als LLM-Quelle. Drei Persona-Models (vf-julia, vf-nova, vf-cosmo) wandern als Lobe-Agents mit System-Prompt + Tool-Whitelist mit. mcp-vf-hosted bleibt unveraendert dahinter.

Chat-Historien wandern nicht mit (anderes Datenmodell, Pilot-Reset akzeptiert). Alte Open-WebUI-Instanz bleibt 14 Tage parallel auf einer legacy-vf-chat.agenticventures.de-Subdomain als read-only, danach decom.

Aufwand: 4-6 Tage Bauzeit, Cutover an einem Wochenende.

Warum jetzt

  1. Persona-Architektur passt zu Lobe-Agents wie Faust auf Auge — heute mit Open-WebUI „Custom Models” gebastelt, in Lobe ist das das Standard-Konzept.
  2. MCP-First — Lobe hat ENABLED_MCP=1 als First-Class, nicht als External-Tool-Server-Krampf mit Function-Filter-List wie Open WebUI.
  3. Whitelabel-Hygiene — Lobe-Custom-Image-Build via GitHub Actions kann das App-Name-Suffix vollstaendig wegnehmen (in Open WebUI ist „(Open WebUI)” hardcoded). Marvin’s seit Welle 1 offenes Issue.
  4. Better Auth + Entra ID — Lobe unterstuetzt Microsoft Entra OpenID nativ (AUTH_MICROSOFT_TENANT_ID). Alle VF-User haben M365-Account, Onboarding wird One-Click — adressiert die in Praktikanten-Onboarding-Runbook dokumentierte 10-Min-Friktion.
  5. Knowledge-Base + RAG built-in — ParadeDB mit pgvector ist Lobe-Default-DB, RAG ist Feature-Flag-Toggle. Heute haben wir kein RAG.

Was sich aendert — Stack-Diff

LayerHeute (Open WebUI v0.9.5)Cutover (LobeHub v2.2.x)
App-Containeropen-webui (Python+Node) + LiteLLM (Bedrock-Bridge) + cloudflaredlobehub (Next.js 16) + LiteLLM (bleibt!) + Redis + Searxng + cloudflared
DBRDS PostgreSQL 17.9 t4g.microRDS PostgreSQL 17 mit pgvector + pg_search Extensions (oder ParadeDB Docker)
Object StorageS3-Bucket im av-productionS3-Bucket im av-production (S3_ENABLE_PATH_STYLE=1, S3_SET_ACL=0)
AuthEmail+Passwort+MFA (Open-WebUI eingebaut)Better Auth — Phase 1 Email+Passwort, Phase 2 Microsoft Entra OpenID
LLM-BackendLiteLLM → Bedrock EU-CRIS (Sonnet 4.6/Haiku 4.5/Opus 4.6)LiteLLM bleibt als OpenAI-kompatibler Endpoint — Lobe spricht openai-Provider zur LiteLLM, NICHT Lobe-Bedrock direkt
MCP-AnbindungExternal MCP Servers via UI, function_name_filter_list pro Custom ModelENABLED_MCP=1, mcp-vf-hosted als MCP-Server registriert, Tool-Whitelist pro Agent
Personas3 Custom Models (vf-julia, vf-nova, vf-cosmo)3 Lobe-Agents mit gleichem System-Prompt + Tool-Subset
Web-Suchenicht built-in (Open WebUI kann’s, war off)Searxng Container im Stack, default ON
File-Upload + RAGrudimentaer, S3-BackedVolle Knowledge-Base + RAG via pgvector
BrandingENTRYPOINT-Wrapper curlt Favicon in 17 Pfade, „(Open WebUI)“-Suffix nicht entfernbarCustom-Image via GitHub Actions, NEXT_PUBLIC-build-args fuer Logo+Name vollstaendig brandable
System-Prompt-Source-of-Truth~/source/apps/open-webui-vf/prompts/ + build.py —push via Open-WebUI Admin-APIGleiche Struktur, neuer build.py-Adapter fuer Lobe Admin-API

LiteLLM bleibt drin. Begruendung: heute laeuft Bedrock-Auth ueber ECS-TaskRole, nicht ueber Long-Lived IAM-User-Keys. Lobe-Doku zeigt nur AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY (statisch). LiteLLM uebersetzt OpenAI-Schema auf Bedrock-EU-CRIS-Profiles (eu.anthropic.claude-sonnet-4-...) und nutzt die TaskRole — gleiche Pattern wie heute, kein Schritt rueckwaerts bei Credentials-Hygiene. Lobe spricht LiteLLM via OPENAI_PROXY_URL (oder OPENAI_API_KEY + OPENAI_API_BASE). Prompt-Caching-Setup aus Welle-1 (Cache-Hit-Rate-Audit 2026-05-18) bleibt unveraendert.

Was NICHT migriert wird

  • Chat-Historien Open WebUI → Lobe — andere DB-Schemas, kein Konverter. Akzeptiert: User starten leer.
  • Welle-1-Klassifikator-Routing (Haiku-Pre-Klassifikator). Lobe hat keinen Pipeline-Hook fuer Pre-Routing. Cost-Konsequenz: alle Persona-Requests laufen direkt auf Sonnet 4.6 — geschaetzter Mehraufwand $50-80/Mo (Welle-2-Item, evt. via LiteLLM-Router nachruesten).
  • Open-WebUI-spezifische Permission-Architektur (Groups crew + buchhaltung, access_control auf Models). Lobe hat eigene RBAC — siehe Phase 4 unten.

Phasen

Phase 0 — Decisions vor Bau (1 h)

FrageEmpfehlungBegruendung
DB: bestehende RDS upgraden oder neubestehende RDS PostgreSQL 17.9 t4g.micro nehmen, pgvector + (optional pg_search) als Extension dazuSchon da, KMS+Backup eingerichtet. Neuer Schema-Namespace lobehub
S3-Bucketneuen Bucket vf-chat-lobehub-files-eu-central-1 anlegenOpen-WebUI-Bucket bleibt fuer 14d Parallelbetrieb verfuegbar
Auth Phase 1Email+Passwort+SMTP (Postmark oder SES)Cutover-Speed. Entra in Phase 5 nach Cutover.
Domain-Strategievf-chat.agenticventures.de zeigt nach Cutover auf Lobe, legacy-vf-chat.agenticventures.de neue Subdomain fuer Open WebUI (read-only)User-Memory: gewohnte URL bleibt funktional
Tool-Whitelist pro Agentgleich wie heute (julia/nova/cosmo, siehe permission-architektur)Permission-Architektur-Plan bleibt gueltig, nur in Lobe-Agent-Schema gerendert
Custom-BrandingCustom-Image-Build via GitHub Actions Day 1 — NICHT first auf stock-Image deployenSpart Doppel-Deploy, Cutover-Day direkt brandgefuehrt
Klassifikator-Routingerstmal weg, alle Requests Sonnet 4.6 direktLobe hat keinen Pipeline-Hook. Welle-2 Eval mit LiteLLM-Router.
BackupsRDS automated 7d wie heute + DB-Schema-Dump pre-Cutover in S3Standard

Ball: Marvin Phase-0-Decisions schnell durchgehen, dann Phase-1-Start.

Phase 1 — Stack-Skelett (1.5 Tage)

Neuer CDK-Stack lobehub-vf-stack.ts im selben Repo ~/source/apps/open-webui-vf/infra/lib/ (Repo umbenennen erst nach Cutover-Stabilisierung). Komponenten:

av-production / eu-central-1
├── Fargate Service "lobehub-vf"
│   ├── Container lobe (lobehub/lobehub:latest, x86 1 vCPU/3 GB, Port 3210)
│   ├── Container redis (redis:7-alpine, Port 6379 intern)
│   ├── Container searxng (searxng/searxng:latest, Port 8080 intern)
│   ├── Container litellm (bleibt aus alter Konfig, Port 4000 intern)
│   └── Container cloudflared (Sidecar, Tunnel `<neue-tunnel-id>`)
├── RDS PostgreSQL 17 (`open-webui-vf-db`, bestehend)
│   └── neuer Schema/DB `lobehub` mit `pgvector` Extension
├── S3 Bucket `vf-chat-lobehub-files-eu-central-1` (KMS, Block Public Access)
├── Secrets Manager:
│   ├── prod/vf-chat-lobehub/auth-secret (openssl rand -base64 32)
│   ├── prod/vf-chat-lobehub/key-vaults-secret (openssl rand -base64 32)
│   ├── prod/vf-chat-lobehub/db-url (postgres://... → bestehende RDS)
│   ├── prod/vf-chat-lobehub/smtp-credentials (Postmark oder SES)
│   └── prod/vf-chat-lobehub/microsoft-oauth (in Phase 5 hinzu)
└── CloudWatch Dashboard `lobehub-vf` (Logs + Metrics)

Cloudflare-Tunnel: neuer Tunnel via cloudflare-MCP anlegen, DNS-CNAME lobehub-vf.agenticventures.de (Build-Subdomain fuer Phase 2-4 Tests). DNS fuer vf-chat.agenticventures.de bleibt zunaechst auf Open WebUI — Cutover-Switch erst in Phase 6.

IAM-TaskRole: identisch zur heutigen plus:

  • bedrock:InvokeModel + bedrock:InvokeModelWithResponseStream auf EU-CRIS-Inference-Profile-ARNs (fuer LiteLLM)
  • S3-RW auf neuen Bucket + KMS
  • Secrets Manager Read auf die 4 neuen Secrets

Verifikation Phase 1: Lobe startet, Login mit Marvin’s Admin-Email funktioniert, Web-Search via Searxng laeuft, kein LLM noch verbunden.

Phase 2 — LiteLLM + Bedrock-Anbindung (0.5 Tag)

LiteLLM-Config aus dem heutigen Stack uebernehmen (~/source/apps/open-webui-vf/infra/litellm-config.yaml):

  • 3 Bedrock-EU-CRIS-Profile (Sonnet 4.6, Haiku 4.5, Opus 4.6)
  • Prompt-Caching enabled
  • Cache-Killer-Fix aus Welle-1 (kein {{CURRENT_TIME}} im System-Prompt) ist bereits in den Persona-Prompts gefixt

Lobe-Env-Vars:

ENABLED_AWS_BEDROCK=0           # NICHT Lobe-direct, sondern via OpenAI-Proxy
OPENAI_API_KEY=sk-litellm-internal-...
OPENAI_PROXY_URL=http://localhost:4000/v1   # LiteLLM intern im Task
OPENAI_MODEL_LIST=-all,+claude-sonnet-4-6=Claude Sonnet 4.6,+claude-haiku-4-5=Claude Haiku 4.5,+claude-opus-4-6=Claude Opus 4.6

Verifikation Phase 2: Lobe Settings → AI Providers → OpenAI → Connection-Test gruen. Neuer Chat mit Sonnet 4.6 → Antwort kommt. LiteLLM-CloudWatch-Logs zeigen Bedrock-Call mit Cache-Hit. (Erster Call cold, zweiter hot.)

Phase 3 — MCP-Anbindung (1 Tag)

Lobe ENABLED_MCP=1 global, danach pro Agent in der Lobe-UI MCP-Server registrieren. Es gibt zwei Modi laut Lobe-Doku:

  • Marketplace-MCPs (eingebaut, mit eingebautem OAuth-Flow) — nicht relevant fuer uns
  • Custom-MCPs (URL + Auth-Header) — das brauchen wir fuer https://mcp-vf.agenticventures.de/mcp

Offene Verifikations-Punkte (am Live-Stack zu pruefen, da Lobe MCP-Doku online aktuell 403 zurueckgibt):

  1. Unterstuetzt Lobe streamable-http-MCPs mit OAuth-2.1-Flow (Scalekit) wie mcp-vf-hosted spricht?
  2. Forward von User-Identity-Headern (X-OpenWebUI-User-Email-Equivalent) — gibt es in Lobe einen Konfig-Hook?
  3. Tool-Whitelist pro Agent — wie heute function_name_filter_list mit 16 Core-Tools?

Falls einer der drei Punkte nicht out-of-the-box geht: Fallback = MCP-Pattern bleibt wie heute (mcp-vf-hosted spricht MCP-Protokoll, Lobe konsumiert es) — aber wir muessen entweder den Lobe-Code patchen (LobeHub Community License erlaubt Forks) oder einen duennen Proxy davorlegen. Worst Case +1-2 Tage.

Verifikation Phase 3: vf-cosmo-Agent kann sharepoint_list_messages aufrufen, vf-julia-Agent kann papierkram_offene_posten, vf-nova-Agent kann replicate_create_prediction. Audit-Header kommt in mcp-vf-hosted-Logs an.

Phase 4 — Personas als Agents + Permission-Layer (1 Tag)

Drei Lobe-Agents anlegen, je mit:

  • Agent-ID: vf-julia, vf-nova, vf-cosmo
  • System-Prompt: Files aus ~/source/apps/open-webui-vf/prompts/ (bleibt Source-of-Truth, neuer build.py-Push-Adapter fuer Lobe-Admin-API)
  • Tool-Whitelist pro Agent — gleich wie in permission-architektur dokumentiert
  • Model: claude-sonnet-4-6 (via LiteLLM)

RBAC — Lobe hat KEIN Group-basiertes „pro-User-Agent-Sichtbarkeit” wie Open WebUI’s Access-Control out-of-the-box (Stand 2026-05, ueber Better-Auth-Features verifizieren beim Build). Drei Optionen:

  1. Alle User sehen alle drei Agents — pragmatisch, vertraut auf Self-Discipline. Felix sieht vf-julia, ruft sie aber nicht auf (System-Prompt sagt „du bist hier falsch, sprich Andre/Christoph an”). Akzeptabel fuer VF-Trust-Level.
  2. Per-User-Sichtbarkeit via Lobe-Marketplace-Feature — falls in v2.2.x verfuegbar, in Phase 4 verifizieren.
  3. Reverse-Proxy-Layer der Agent-IDs pro User-Mail filtert — Eigenbau, Welle-2.

Empfehlung Phase 4: Option 1 zum Cutover, Option 2/3 als Welle-2-Item wenn echter Bedarf entsteht. Permission-Sicherung kommt aus dem System-Prompt + MCP-User-Header-Scope-Lock (siehe Offene-Folgethemen — Schicht-2-RBAC im MCP-Code).

Verifikation Phase 4: drei Agents sichtbar im Picker, drei verschiedene Tool-Sets, vf-julia spricht Andre-Buchhaltungs-Stil aus dem System-Prompt.

Phase 5 — User-Cutover (0.5 Tag)

  1. Email an Andre + Christoph + Marvin (siehe Mail-Template unten in cutover-mail)
  2. Accounts in Lobe anlegen (Better Auth Email+Passwort, Initial-Passwort generiert, force-change-on-first-login)
  3. Smoke-Test mit Andre auf einer echten Buchhaltungs-Aufgabe: „zeig mir die offenen Posten” → vf-julia → papierkram_offene_posten → Tabelle
  4. DNS-Cutover:
    • vf-chat.agenticventures.de → neuer Lobe-Tunnel (Cloudflare DNS-Update via MCP)
    • legacy-vf-chat.agenticventures.de → bestehender Open-WebUI-Tunnel (DNS-Eintrag neu)
    • TTL vorher auf 60s setzen, nach Stabilisierung wieder auf 5min
  5. Status-Page-Update auf den Agenticventures.de-Status-Indikator (falls vorhanden)

Phase 6 — Decom Open WebUI (14 Tage nach Cutover)

  • ECS-Service Open-WebUI auf 0 Tasks
  • RDS-Schema openwebui per pg_dump in S3 sichern (Retention 90d), dann DROP SCHEMA
  • EFS-Volume (BertModel-Cache) loeschen
  • CloudWatch-Log-Group /aws/ecs/default/open-webui-vf archivieren
  • Capability-File intern/capabilities/apps/open-webui-vf.md Status auf decommissioned setzen
  • Neuer File intern/capabilities/apps/lobehub-vf.md mit vollstaendiger Doku (analog zum bestehenden Open-WebUI-File)
  • Subdomain legacy-vf-chat.agenticventures.de DNS loeschen

Cost-Schaetzung (post-Cutover)

KomponenteEUR/Mo
Fargate Task (1 vCPU/3 GB x86, 5 Container)42 € (3 € mehr durch +Redis+Searxng)
RDS PostgreSQL t4g.micro (shared mit altem Stack waehrend Parallelbetrieb)14 €
EFS (entfaellt nach Decom)0 €
S3 + KMS + CloudWatch Logs7 €
Lobe-Stack Fix~63 €
Plus mcp-vf-hosted (unveraendert)9 €
Gesamt Fix~72 €/Mo (5 € mehr als heute)
Bedrock-API30-150 €/Mo + ggf. +50-80 €/Mo durch fehlendes Klassifikator-Routing

Cost-Pflicht-Folgethema: Welle-2-Item „Klassifikator-Router in LiteLLM nachbauen” — sonst tendiert die Bedrock-Rechnung in Richtung Welle-1-Pre-Audit-Niveau (~$320-380/Mo). Mit Lobe-Native-Prompt-Caching ueber LiteLLM bleibt ein Teil der Welle-1-Spar-Effekte bestehen.

Risiken + Mitigations

RisikoWahrscheinlichkeitImpactMitigation
Lobe-MCP-Anbindung kann mcp-vf-hosted nicht out-of-the-boxmittelhoch (Phase 3 verzoegert um 1-2 d)Phase-3-Verifikation am Live-Stack frueh durchziehen, nicht erst gegen Ende. Fallback: duenner Proxy-Layer.
Lobe-RBAC reicht nicht fuer Felix-darf-vf-julia-nicht-sehenhochmittelPhase-4-Empfehlung Option 1 (System-Prompt-Diskretion) akzeptieren, Welle-2 fuer harte RBAC
Klassifikator-Routing fehlt → Bedrock-Kosten steigenhochmittel ($50-80/Mo)bewusste Akzeptanz beim Cutover, Welle-2-Item: LiteLLM-Router
EU-CRIS-Inference-Profile via OpenAI-Proxy klappt nichtniedrighochLiteLLM macht das heute schon, getestet. Niedrig.
Chat-Historien-Verlust irritiert Andre/ChristophniedrigniedrigVorab kommuniziert, alte Instanz 14d read-only erreichbar
Datum-Cutover-Wochenende kollidiert mit echtem VF-Workloadniedrighochmit Andre/Christoph Termin abstimmen, idealerweise Sonntag-Cutover, Montag-Smoke-Test
Better Auth Email-Verifikation requires SMTPhochmittelSES in Phase 0 mit noreply@vibe-factory.de einrichten — Christoph hat Domain-Hoheit

Aufgabenstellung — Konkrete Schritte

  1. [Phase 0] Decisions oben durchgehen, Go/No-Go pro Punkt
  2. [Phase 0] SES (oder Postmark) fuer SMTP einrichten, noreply@vibe-factory.de als Sender verifizieren
  3. [Phase 0] GitHub-Repo fuer Custom-Lobe-Image anlegen (agentic-ventures/lobehub-vf-image), Workflow aus Lobe-Doku adaptieren, NEXT_PUBLIC-Brand-Vars setzen
  4. [Phase 1] Branch lobehub-cutover im ~/source/apps/open-webui-vf/ Repo. Neue CDK-Stack-File lobehub-vf-stack.ts. Bestehenden Stack belassen.
  5. [Phase 1] Tunnel lobehub-vf via cloudflare-MCP anlegen, DNS-CNAME lobehub-vf.agenticventures.de → Tunnel
  6. [Phase 1] RDS-Schema lobehub + pgvector Extension einrichten (CREATE EXTENSION IF NOT EXISTS vector;)
  7. [Phase 1] Stack deployen, Lobe-Container started, Admin-Setup
  8. [Phase 2] LiteLLM-Config kopieren, Lobe-Env-Vars setzen, Connection-Test
  9. [Phase 3] mcp-vf-hosted in Lobe als Custom-MCP registrieren, Tool-Sichtbarkeit verifizieren — risk-Phase
  10. [Phase 4] ~/source/apps/open-webui-vf/prompts/ umstrukturieren: neuer build.py-Adapter mit --target=lobe (Lobe-API-Endpoint) zusaetzlich zum heutigen --target=owui. Drei Agents pushen.
  11. [Phase 5] Mails an Andre/Christoph, Accounts anlegen, Smoke-Test, DNS-Switch
  12. [Phase 6] 14 Tage spaeter Decom-Schritt

Cutover-Mail an VF-Team

Draft fuer Phase 5, vor Versand mit style-profile-marvin gegenchecken.

Betreff: VF Chat wird heute Abend auf neue Plattform umgestellt

Hi Andre, hi Christoph,

heute Abend ab ca. 21 Uhr stelle ich die VF-Chat-Instanz auf LobeChat um.
Lobechat ist ausgereifter, hat eine saubere MCP-Integration und Whitelabel,
und unsere drei Personas Julia/Nova/Cosmo bleiben gleich.

Was sich aendert:
- Login per Email+Passwort, Account-Setup-Mail kommt heute Abend
- die Chat-Historie aus dem alten System wandert nicht mit, die alte Instanz
  bleibt unter legacy-vf-chat.agenticventures.de noch 14 Tage erreichbar
  falls ihr was nachschlagen muesst
- die URL vf-chat.agenticventures.de zeigt ab morgen auf die neue Instanz

Was gleich bleibt:
- Julia, Nova, Cosmo sind weiter da, mit denselben Faehigkeiten
- Papierkram, M365, TicketPAY, Bild-Generierung — alles ueber dieselben Tools
- der Mail-Workflow: Drafts ja, Senden niemand

Bei Problemen ruft mich morgen frueh an, ich bin erreichbar.

Marvin

Dokumentations-Folgen nach Cutover

  1. intern/capabilities/apps/lobehub-vf.md anlegen — wie bestehende open-webui-vf, aber Lobe-spezifisch
  2. intern/capabilities/apps/open-webui-vf.md Status auf decommissioned, Verweis nach lobehub-vf
  3. intern/wissen/prozesse/lobehub-fargate-bedrock.md als neues Pattern-File (analog open-webui-fargate-bedrock)
  4. CLAUDE.md Routing-Tabelle: Zeile „Open WebUI auf AWS hosten” durch „LobeHub auf AWS hosten” ersetzen
  5. produkt-bundle aktualisieren: Custom-Tier-Default ist ab 2026-05-Cutover LobeHub
  6. _index aktualisieren: Stack-Status auf Lobe
  7. permission-architektur umschreiben oder durch permission-architektur-lobehub.md ersetzen — Lobe-Agent-Konzept statt Open-WebUI-Custom-Models
  8. welle-1-perfektion und welle-4-capability-rollout: Items markieren die durch Cutover obsolet werden (z.B. Custom-Model-Branding)
  9. Welle-2-Backlog: „LiteLLM-Klassifikator-Router” und „Lobe-Code-Patch fuer User-Header-Forward” und „RBAC pro Agent”

Status

Status: draft. Vor Phase-1-Start einmal mit Marvin durchgehen, dann Phase 0 Decisions abhaken.

Naechster Schritt: Marvin gibt Go oder nimmt Anpassungen am Plan vor.

Cross-Refs

Graphansicht