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 proveedores gestionados suelen cifrar los volúmenes en reposo por defecto, pero confirma los detalles con tu proveedor.

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.

Añade las claves de API de los proveedores que vayas a usar al passwords.yaml del servidor tenant. Cada proveedor tiene su propia clave (por ejemplo openaiApiKey); Ollama y Ollama Cloud reciben una URL base y un nombre de modelo en lugar de una clave secreta. La clave de OpenAI también impulsa la generación de imágenes en los flujos de trabajo. No hay un proveedor predeterminado fijo: la disponibilidad depende de lo que configure un administrador.

Modelo de incrustación — fundamentando el conocimiento

Las respuestas de conocimiento se fundamentan con la búsqueda semántica de pgvector: los documentos subidos y los sitios web vinculados se fragmentan, incrustan y recuperan con citas. Eso requiere un modelo de incrustación además de los LLM de chat. Configura una clave de proveedor de incrustación (por ejemplo, una clave de incrustaciones de OpenAI) en el passwords.yaml del servidor tenant.

Resumen del entorno

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