Servicios principales y entorno

PostgreSQL — las dos bases de datos

Your Office AI es una plataforma multitenancy con un backend de dos servidores, y cada servidor tiene su propia base de datos. Mantenerlas separadas significa que el servidor de autenticación (identidad) y el servidor tenant (datos por organización) pueden operarse, escalarse e incluso alojarse por partes distintas.

1. Aprovisiona dos bases de datos PostgreSQL

   Your Office AI ejecuta dos bases de datos independientes: una base de datos de autenticación para el servidor de autenticación (usuarios, organizaciones, ajustes globales) y una base de datos tenant para el servidor tenant (chat, conocimiento, integraciones, tokens de LiveKit). Para el desarrollo local, ambas se ejecutan en Docker a través del docker-compose.yaml de cada servidor. Para producción, usa Postgres gestionado: Supabase, AWS RDS o Cloud SQL.

2. Anota los datos de conexión

   Para cada base de datos, anota el host, el puerto, el nombre de la base de datos, el usuario y la contraseña. En un proyecto de Supabase, los encontrarás en Settings → Database → Connection string. Elige la región más cercana a tus usuarios — los hosts de BD en la UE utilizan cifrado de volumen LUKS / AES-256 en reposo.

3. Establece la contraseña y el host/puerto

   Coloca cada contraseña en el config/passwords.yaml del servidor correspondiente bajo el entorno correcto (development.database), y el host/puerto/nombre en config/development.yaml (o staging / production). Los valores de autenticación viven en command_center_server; los valores tenant en command_center_tenant_server.

4. Aplica las migraciones

   Ejecuta las migraciones contra ambas bases de datos (desde la raíz del repositorio, make both-migrate). Esto también habilita la extensión de vector de PostgreSQL que usa Knowledge para la búsqueda semántica con pgvector. Carga datos de prueba con make both-seed si quieres un entorno poblado.

Adónde van los valores

Redis — pub/sub en tiempo real

Redis respalda los flujos en tiempo real de Serverpod en el servidor tenant. También es el pilar del escalado horizontal: con Redis como bus de mensajes compartido, cualquier réplica puede difundir un evento que reciben todas las demás.

1. Aprovisiona Redis

   El servidor tenant usa Redis para los flujos en tiempo real de Serverpod (pub/sub). En local se incluye en docker-compose.yaml. Para producción, usa un Redis gestionado: ElastiCache, Upstash o Redis Cloud.

2. Establece la contraseña y el host/puerto

   Establece la contraseña de Redis en config/passwords.yaml (development.redis) y el host/puerto en config/development.yaml bajo redis:. El servidor de autenticación dispone de su propio contenedor Redis con el mismo esquema de claves.

3. Obligatorio al escalar

   Una instancia única puede funcionar sin Redis, pero el pub/sub es obligatorio en cuanto se ejecuta más de una réplica del servidor tenant: es la forma en que las réplicas se difunden eventos entre sí. Consulta la guía de despliegue multiinstancia.

Almacenamiento de objetos

Las subidas, los documentos de conocimiento y los avatares viven en almacenamiento de objetos compatible con S3. Los despliegues autoalojados suelen usar MinIO; los gestionados usan Supabase Storage. Las descargas de documentos están mediadas por el servidor: la aplicación obtiene los bytes a través del servidor tenant en lugar de exponer directamente una URL de almacenamiento, por lo que los buckets privados nunca necesitan ser públicos.

1. Elige un almacén compatible con S3

   Las subidas de archivos, los documentos de conocimiento y los avatares se almacenan en almacenamiento de objetos. Los despliegues autoalojados usan MinIO (compatible con S3, gratuito, Docker local); los gestionados usan Supabase Storage. Cualquiera funciona: la aplicación habla el API S3.

2. Crea los buckets

   Crea los buckets que usa la aplicación (por ejemplo, uploads y avatars). En Supabase Storage, marca los buckets de tipo avatar como Públicos y mantén los de subida como privados.

3. Establece las políticas de acceso

   Para Supabase Storage, añade políticas de Row-Level Security para que los usuarios autenticados solo puedan leer y escribir su propia carpeta (ruta prefijada con su id de usuario), con lectura pública en los buckets de avatares. Las descargas de documentos de conocimiento están mediadas por el servidor, por lo que los buckets privados nunca necesitan una URL pública.

Proveedores de LLM — seis en una organización

Your Office AI no depende de un proveedor concreto. Una sola organización puede ofrecer seis proveedores de IA, y los administradores eligen qué modelos están disponibles y establecen límites de gasto por organización. Los modelos alojados provienen de OpenAI, Anthropic, Google y Groq; la inferencia privada y local se ejecuta a través de Ollama y 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.

Modelo de incrustación — fundamentando el conocimiento

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.

Resumen del entorno

Dónde viven los valores principales, de un vistazo: