Installation et auto-hébergement

Olivares AI est livré comme un binaire statique unique avec la console web embarquée. Le plan de contrôle — la partie qui observe, gouverne et audite les agents IA de votre infrastructure — fonctionne dans votre périmètre et peut être air-gappé. Cette page couvre l’installation en production : un hôte, des défauts sécurisés, des sondes de santé, et le choix de store qui compte pour les déploiements multi-tenants.

Si vous voulez seulement explorer d’abord, le démarrage rapide démarre un environnement de démonstration synthétique en environ cinq minutes. Cette page est la vraie posture.

Obtenir le binaire

Il n’y a pas d’URL de téléchargement publique à copier ici. Vous obtenez le binaire olivares de deux manières :

• Un artefact de release signé — vérifiez-le avant de l’exécuter. Voir vérifier une release pour la chaîne de signature et de provenance.
• Compiler depuis les sources — le store est en pur Go SQLite, il n’y a donc pas de chaîne d’outils C. Un task build produit ./bin/olivares avec l’interface web et les connecteurs first-party embarqués ; olivares version confirme ce que vous avez compilé.

Dans les deux cas, vous obtenez un fichier unique. Installez-le et créez un utilisateur de service dédié plutôt que de l’exécuter en root.

Défauts sécurisés

Les défauts sont choisis pour qu’une installation neuve soit sûre avant que vous ne touchiez un flag.

Un premier démarrage minimal :

olivares serve \
  --listen 127.0.0.1:8443 \
  --grpc-listen 127.0.0.1:8444 \
  --data-dir /var/lib/olivares

Le répertoire de données contient le store, la clé de signature d’audit et le matériel TLS. Sauvegardez-le et protégez-le avec des permissions restrictives.

Réclamer le token de configuration unique

Une installation neuve n’a aucun identifiant par défaut. Au premier démarrage, tant qu’aucun utilisateur n’existe, le moteur génère un token à usage unique et l’affiche sur stdout uniquement — jamais dans les logs :

=== FIRST-BOOT SETUP ===
No users exist yet. Create the first administrator:
  POST /v1/setup  {"token":"olst_…","email":"you@example.com","password":"..."}
This token is shown ONCE and is single-use.
========================

Seul le hash du token est stocké, un token manqué ne peut donc pas être récupéré et un redémarrage ne le ré-affiche pas. Sur une installation toute neuve sans utilisateurs, supprimer le token stocké du répertoire de données et redémarrer en génère un nouveau. Cette récupération ne fonctionne que tant qu’aucun utilisateur n’existe, elle ne peut donc jamais prendre le contrôle d’une installation configurée.

Après avoir créé le premier administrateur, le endpoint de configuration est fermé définitivement.

Sondes de santé

L’écouteur HTTP expose deux sondes avec des sémantiques délibérément différentes. Câblez-les à la sonde Kubernetes correspondante — confondre les deux provoque des boucles de redémarrage ou du routage périmé.

/livez est la vivacité. Elle n’exécute aucune vérification de dépendance : si le processus peut répondre, il est vivant. Une dépendance défaillante ne doit jamais déclencher un redémarrage de vivacité.

curl -ks https://127.0.0.1:8443/livez
# {"status":"ok"}

/readyz est la disponibilité, et c’est le signal de disponibilité sur lequel un load balancer devrait drainer. Elle retourne 503 dans deux cas, distingués dans le corps pour vos logs :

• Store inaccessible — {"status":"unavailable","store":"down"}. Le ping du store s’exécute avec un timeout court, donc un backend bloqué draine l’instance au lieu de bloquer.
• Pas l’écrivain actif — {"status":"standby","store":"up","leader":false}. Dans un cluster actif-passif, un standby rapporte 503 ici pour que le Service arrête de router vers lui, sans le redémarrer (c’est le travail de /livez — un standby chaud doit rester actif pour prendre le relais). Quand le leader meurt, un standby acquiert le leadership et cela bascule à 200, donc le trafic suit automatiquement le nouveau leader.

Quand le moteur est prêt, il retourne 200 :

{"status":"ok","store":"up","leader":true,"setup_required":false}

setup_required est rapporté pour l’observabilité mais ne fait pas échouer la disponibilité — un moteur fraîchement démarré est prêt à être configuré. Sur un store à nœud unique, l’écrivain est toujours actif, donc /readyz suit simplement l’accessibilité du store.

Choisir un store

Le store est sélectionné avec --engine. Choisissez par topologie, pas par préférence.

SQLite (défaut)

Le store SQLite embarqué en pur Go n’a besoin de rien d’externe et est le bon choix pour un nœud unique, un lab, un petit environnement, ou une installation air-gappée. Tout l’état vit dans le répertoire de données.

Postgres (multi-tenant)

Pour les déploiements multi-hôtes ou multi-tenants, utilisez Postgres. Ne vous connectez pas en superutilisateur ou avec un rôle ayant BYPASSRLS. L’isolation des tenants est appliquée par FORCE ROW LEVEL SECURITY, et Postgres contourne silencieusement toute la sécurité au niveau des lignes pour de tels rôles — ce qui ne laisserait que le prédicat de la couche application entre les tenants. Le moteur refuse de démarrer avec un rôle privilégié sauf si vous passez explicitement --allow-privileged-db-role (mono-tenant ou dev uniquement).

Provisionnez plutôt un rôle dédié en moindre privilège — NOSUPERUSER NOBYPASSRLS NOCREATEROLE NOCREATEDB. Il est propriétaire de sa propre base de données pour pouvoir appliquer les migrations de schéma ; FORCE ROW LEVEL SECURITY applique la politique tenant même au propriétaire de la table, donc un rôle propriétaire-mais-non-contournant reste pleinement isolé.

olivares serve --engine postgres \
  --dsn "postgres://olivares_app:$DB_PASSWORD@db:5432/olivares?sslmode=verify-full" \
  --data-dir /var/lib/olivares

Utilisez sslmode=verify-full et un mot de passe SCRAM fort. Les lectures véritablement cross-tenant au niveau System (la liste des orgs, la couverture des checkpoints multi-tenants) nécessitent un rôle séparé : provisionnez-en un qui est NOSUPERUSER BYPASSRLS — moindre privilège mais capable de lire à travers les tenants — et pointez --admin-dsn dessus. Omettez-le pour les déploiements mono-tenant et ces lectures seront simplement limitées par RLS.

Avant de considérer l’installation comme terminée

Deux choses décident si vos preuves survivent à un incident :

• Sauvegardez la clé de signature d’audit hors-boîte. Elle signe le registre d’audit append-only ; si elle est perdue, le registre ne peut plus être re-vérifié. Le moteur prévient au premier démarrage — il n’y a pas de mise sous séquestre forcée.
• Gardez une copie hors-boîte de la clé publique du registre. Cette copie hors-hôte est ce qui rend la vérification d’audit résistante après une compromission d’hôte.

Puis planifiez de vraies sauvegardes du répertoire de données.

Ce qui fonctionne où

Seul le plan de contrôle est à vous de placer — air-gappé si vous le choisissez. Les collecteurs (plan de données) fonctionnent toujours sur votre infrastructure. Une réserve qui mérite d’être formulée clairement : Olivares gouverne et audite l’utilisation de Claude, mais l’inférence Claude elle-même n’est pas auto-hébergée — elle atteint l’API d’Anthropic (directement ou via Bedrock, Vertex ou Foundry). Seuls les modèles véritablement auto-hébergés fonctionnent hors ligne. Voir la page transparence et limites pour la frontière complète.

Étapes suivantes

• Câbler du signal réel : connecter une source et connecter Claude Code.
• Ajuster l’installation : la référence de configuration.
• Comprendre le modèle : la carte d’accès lecture/écriture.