Kerndienste & Umgebung

PostgreSQL — die beiden Datenbanken

Your Office AI ist eine Multi-Tenant-Plattform mit einem Zwei-Server-Backend, und jeder Server besitzt seine eigene Datenbank. Die Trennung ermöglicht es, Auth-Server (Identität) und Tenant-Server (organisations­spezifische Daten) unabhängig zu betreiben, zu skalieren und sogar von verschiedenen Parteien hosten zu lassen.

1. Zwei PostgreSQL-Datenbanken bereitstellen

   Your Office AI betreibt zwei unabhängige Datenbanken: eine Auth-Datenbank für den Auth-Server (Benutzer, Organisationen, globale Einstellungen) und eine Tenant-Datenbank für den Tenant-Server (Chat, Wissen, Integrationen, LiveKit-Tokens). Für die lokale Entwicklung laufen beide in Docker über die jeweilige docker-compose.yaml. Für die Produktion nutzen Sie verwaltetes Postgres — Supabase, AWS RDS oder Cloud SQL.

2. Verbindungsdaten notieren

   Notieren Sie für jede Datenbank Host, Port, Datenbankname, Benutzer und Passwort. In einem Supabase-Projekt finden Sie diese unter Settings → Database → Connection string. Wählen Sie die Region, die Ihren Nutzern am nächsten liegt — verwaltete Anbieter verschlüsseln Volumes im Ruhezustand in der Regel standardmäßig, bestätigen Sie die Details jedoch bei Ihrem Anbieter.

3. Passwort und Host/Port festlegen

   Tragen Sie jedes Passwort in die config/passwords.yaml des entsprechenden Servers unter der richtigen Umgebung (development.database) ein und Host/Port/Name in config/development.yaml (oder staging / production). Die Auth-Werte liegen in command_center_server; die Tenant-Werte in command_center_tenant_server.

4. Migrationen anwenden

   Führen Sie die Migrationen für beide Datenbanken aus (vom Repository-Stammverzeichnis: make both-migrate). Dabei wird auch die PostgreSQL-Vektorer­weiterung aktiviert, die Knowledge für die pgvector-Semantiksuche verwendet. Laden Sie Testdaten mit make both-seed, wenn Sie eine befüllte Umgebung wünschen.

Wohin die Werte gehören

Redis — Echtzeit-Pub/sub

Redis unterstützt die Echtzeit-Streams von Serverpod auf dem Tenant-Server. Es ist auch das Rückgrat der horizontalen Skalierung: Mit Redis als gemeinsamem Nachrichtenbus kann jede Replika ein Ereignis senden, das alle anderen Replikas empfangen.

1. Redis bereitstellen

   Der Tenant-Server verwendet Redis für die Echtzeit-Streams von Serverpod (Pub/sub). Lokal ist es in docker-compose.yaml enthalten. Für die Produktion nutzen Sie ein verwaltetes Redis — ElastiCache, Upstash oder Redis Cloud.

2. Passwort und Host/Port festlegen

   Tragen Sie das Redis-Passwort in config/passwords.yaml ein (development.redis) und Host/Port in config/development.yaml unter redis:. Der Auth-Server verfügt über einen eigenen Redis-Container mit demselben Schlüssellayout.

3. Erforderlich beim Skalieren

   Eine einzelne Instanz kann ohne Redis betrieben werden, aber Pub/sub ist obligatorisch, sobald mehr als eine Tenant-Server-Replika läuft — so teilen Replikas Ereignisse miteinander. Lesen Sie die Anleitung zur Multi-Instanz-Bereitstellung.

Objektspeicher

Uploads, Wissensdokumente und Avatare liegen im S3-kompatiblen Objektspeicher. Selbst gehostete Deployments verwenden typischerweise MinIO; verwaltete Deployments nutzen Supabase Storage. Dokument-Downloads sind server-vermittelt — die App holt Bytes über den Tenant-Server statt eine Speicher-URL direkt freizugeben — daher müssen private Buckets nie öffentlich sein.

1. Einen S3-kompatiblen Speicher wählen

   Datei-Uploads, Wissensdokumente und Avatare werden im Objektspeicher abgelegt. Selbst gehostete Deployments verwenden MinIO (S3-kompatibel, kostenlos, lokales Docker); verwaltete Deployments nutzen Supabase Storage. Beides funktioniert — die App spricht die S3-API.

2. Buckets erstellen

   Erstellen Sie die Buckets, die die App verwendet (z. B. uploads und avatars). Markieren Sie in Supabase Storage Avatar-artige Buckets als öffentlich und halten Sie Upload-Buckets privat.

3. Zugriffsrichtlinien festlegen

   Fügen Sie für Supabase Storage Row-Level-Security-Richtlinien hinzu, damit authentifizierte Benutzer nur ihren eigenen Ordner lesen und schreiben können (Pfad mit ihrer Benutzer-ID präfixiert), mit öffentlichem Lesezugriff auf Avatar-Buckets. Downloads von Wissensdokumenten sind server-vermittelt, daher benötigen private Buckets keine öffentliche URL.

LLM-Anbieter — sechs in einer Organisation

Your Office AI ist anbieterunabhängig. Eine einzelne Organisation kann sechs KI-Anbieter anbieten, und Administratoren entscheiden, welche Modelle verfügbar sind, und legen Ausgabenlimits pro Organisation fest. Gehostete Modelle kommen von OpenAI, Anthropic, Google und Groq; private und lokale Inferenz läuft über Ollama und Ollama Cloud.

Fügen Sie die API-Schlüssel der Anbieter, die Sie verwenden möchten, in die passwords.yaml des Tenant-Servers ein. Jeder Anbieter hat seinen eigenen Schlüssel (z. B. openaiApiKey); Ollama und Ollama Cloud erhalten eine Basis-URL und einen Modellnamen statt eines Geheimschlüssels. Der OpenAI-Schlüssel treibt auch die Bildgenerierung in Workflows an. Es gibt keinen fest programmierten Standard-Anbieter — die Verfügbarkeit richtet sich danach, was ein Administrator konfiguriert.

Embedding-Modell — Wissen verankern

Wissensantworten werden durch pgvector-Semantiksuche verankert: hochgeladene Dokumente und verknüpfte Websites werden aufgeteilt, eingebettet und mit Quellenangaben abgerufen. Dafür ist zusätzlich zu den Chat-LLMs ein Embedding-Modell erforderlich. Konfigurieren Sie einen Embedding-Anbieterschlüssel (z. B. einen OpenAI-Embeddings-Schlüssel) in der passwords.yaml des Tenant-Servers.

Umgebungsübersicht

Wo die Kernwerte auf einen Blick liegen: