Déploiement du serveur

Cette page couvre le serveur (apps/server) : variables, migrations, sondes et points de vigilance. Le déploiement d'ensemble (images, Helm, bots) est décrit dans la section Déploiement.

Images

Le Dockerfile à la racine définit une cible server : elle lance bun run serve, soit bun start sur dist/src/index.js, après un build TypeScript (tsc).

docker-compose.yml lance le serveur avec document-processor, PostgreSQL, index, rag-agent, web et docs. Le serveur est publié sur SERVER_PORT (3000 dans .env.example).

Variables d'environnement

Le fichier de référence est .env.example à la racine du dépôt (pas dans apps/server/). Variables lues par le serveur :

Variable	Obligatoire	Rôle
`DATABASE_URL`	oui	PostgreSQL principale
`CHAINLIT_DATABASE_URL`	oui pour `getLogo` et `getAllFeedback`	Base Chainlit (logo, feedbacks)
`BETTER_AUTH_SECRET`	oui	Secret de Better Auth
`BETTER_AUTH_URL`	oui	URL publique du serveur (ex. `http://localhost:3000`)
`CORS_ORIGIN`	oui	Origine du front (ex. `http://localhost:3001`)
`MICROSOFT_CLIENT_ID`, `MICROSOFT_CLIENT_SECRET`, `MICROSOFT_TENANT_ID`	oui	OAuth Microsoft
`DOCUMENT_PROCESSOR_URL`	oui	URL de `document-processor` (ex. `http://localhost:8001`)
`INDEX_API_URL`	oui	URL de l'API d'index de `rag-agent` (ex. `http://localhost:8502`)
`I18N_JSON`	non	Traductions inline ; sinon fichier `i18n.json`
`LITELLM_API_BASE`, `LITELLM_API_KEY`, `TRANSCRIPTION_MODEL_ID`	non	Transcription audio

Le code n'utilise pas RESEND_API_KEY ni EMAIL_FROM : aucun envoi d'e-mail n'est configuré côté serveur (voir Authentification).

Démarrage local

Deux options :

# Option 1 : Docker Compose
cp .env.example .env
cp i18n.json.example i18n.json
docker compose up --build -d

# Option 2 : développement local
bun install
bun run dev:server   # serveur sur le port 3000

Pour la base seule, voir Installation & configuration de la base.

Migrations

Les migrations ne sont pas appliquées au démarrage du serveur. Elles sont lancées :

en Helm, par un initContainer db-migrate qui exécute bun run --cwd /app/apps/server db:migrate, après une attente de la base ;
en local, à la main : bun run db:migrate dans apps/server/.

Le détail des migrations est dans Base de données & migrations.

Sondes et routes

Route	Usage
`GET /health`	Sonde de vivacité (liveness)
`GET /ready`	Sonde de disponibilité (readiness)
`GET /`	Réponse `OK`
`POST/GET /api/auth/**`	Better Auth
`/rpc/*`	Procédures oRPC

Les trois routes de santé répondent OK sans vérifier la base.

CORS et cookies

Le serveur accepte localhost et 127.0.0.1 (tous ports) et l'origine exacte CORS_ORIGIN, avec credentials: true.
Les requêtes oRPC du front envoient les cookies de session (credentials: 'include').
Better Auth utilise CORS_ORIGIN comme trustedOrigins. Si le front change d'origine, il faut mettre à jour cette variable.

Le client Better Auth du front (apps/web/src/lib/auth-client.ts) a pour baseURL la valeur de VITE_SERVER_URL, sans suffixe. Better Auth ajoute son chemin par défaut /api/auth à cette origine. Ne pas ajouter /api/auth à VITE_SERVER_URL, sinon le chemin est doublé.

Helm

Le chart helm/ déploie le serveur avec :

la configuration dans le configmap (ports, URLs internes, i18n) et les secrets dans secrets.yaml (dont DATABASE_URL, reconstruite à partir des valeurs de base) ;
les sondes /health et /ready ;
l'initContainer de migration décrit plus haut.

Les traductions du chart viennent de i18n.json.example via scripts/convert_i18n_to_helm_values.py. Éditer l'exemple, puis lancer le script.

Points de vigilance

Protéger .env et les secrets : aucun ne doit atteindre le navigateur.
Une base distincte par environnement (DATABASE_URL).
Sans CHAINLIT_DATABASE_URL, le logo et les feedbacks ne s'affichent pas : le reste du back-office fonctionne.

Deployment