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 — die EU-DB-Hosts verwenden LUKS / AES-256-Volumenverschlüsselung im Ruhezustand.

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.

Add the provider API keys you intend to use to the tenant server's passwords.yaml. Each provider has its own key (for example openaiApiKey); Ollama and Ollama Cloud take a base URL and model name rather than a secret key. The OpenAI key also powers image generation in workflows. There is no hardcoded default provider — availability is whatever an admin configures.

Embedding-Modell — Wissen verankern

Knowledge answers are grounded with pgvector semantic search: uploaded documents and linked websites are chunked, embedded, and retrieved with citations. That requires an embedding model in addition to the chat LLMs. Configure an embedding provider key (for example an OpenAI embeddings key) in the tenant server's passwords.yaml.

Umgebungsübersicht

Wo die Kernwerte auf einen Blick liegen: