Configuration du serveur

La plupart des réglages de production se gèrent dans l’interface. Ouvrez le menu utilisateur, choisissez Paramètres, puis développez Serveur.

Carte des paramètres serveur

Section	Rôle
Général	Identité serveur, licence/mise à jour, export et informations de connexion client
Identifiants	Profils OAuth et clés API des fournisseurs d’agents
Utilisateurs	Comptes, rôles, sièges et accès
Notifications mobiles	Configuration du fournisseur de push
Authentification	Connexion par mot de passe et SSO OIDC
Boards	Valeurs par défaut et modèles de boards serveur
Clés API	Identifiants d’automatisation limités par portée et permissions
Skills	Skills installés pour tout le serveur
Intégrations	Gestionnaires de tickets et fournisseurs personnalisés
Labels	Labels réutilisables du serveur
Sauvegarde	Sauvegardes manuelles/planifiées, fournisseur et rétention
Export de logs	Destination externe et format de sortie
Chiffrement	Source de la clé et rotation sûre

Les paramètres d’organisation et de projet constituent des portées distinctes. Il n’est pas nécessaire de placer tous les labels, skills ou identifiants propres à un projet au niveau Serveur.

Réseau et ports

Les builds natifs publiés écoutent sur 0.0.0.0. Le port préféré est 50505 ; s’il est indisponible, le serveur essaie 50506 à 50514, puis un port attribué par le système. Le port réel est écrit dans port.txt.

Docker expose toujours le port conteneur 50505 ; choisissez librement le mapping hôte. Pour un accès distant, utilisez HTTPS via un reverse proxy et transmettez les upgrades WebSocket.

Le health check sans authentification est :

curl http://localhost:50505/api/health

Données persistantes

Les emplacements natifs sont listés dans Binaire serveur. Docker persiste le même dossier applicatif via le volume /data. Son contenu important comprend :

• data/stib.db — base SQLite en mode WAL ;
• pièces jointes et exports générés ;
• sauvegardes et logs ;
• fichiers de mise à jour et identité serveur ;
• port.txt — dernier port lié avec succès.

Ne modifiez jamais une migration déjà appliquée à une base. Les versions normales appliquent automatiquement les migrations en attente.

Chiffrement

Les secrets d’identifiants et d’intégrations sont chiffrés. L’ordre de résolution de la clé est :

1. valeur valide de STIB_ENCRYPTION_KEY ;
2. clé stockée dans la base ;
3. nouvelle clé générée et persistée au premier lancement.

Quand une clé d’environnement est active, l’interface ne la remplace pas. Faites la rotation via la configuration de déploiement et le flux prévu ; ne redémarrez jamais simplement une base existante avec une autre clé.

Variables d’environnement courantes

Variable	Signification
RUST_LOG	Filtre de logs Rust, par exemple info ou stib_server=debug
STIB_ENCRYPTION_KEY	Clé externe de 32 octets codée en 64 caractères hexadécimaux
STIB_SERVER_ORIGIN	Origine publique servant à construire les callbacks OIDC
STIB_RELEASE_CHANNEL	stable ou beta
STIB_UPDATE_URL	Remplace l’endpoint du manifeste signé de mise à jour
STIB_WEBSITE_API_URL	Remplace l’API stib.ai de compte/licence
STIB_AGENT_IMAGE	Image agent utilisée par un serveur capable de créer des sandboxes Docker
STIB_API_URL	Origine publique de secours du serveur et cible du CLI humain ou externe ; elle n’est pas réutilisée comme route privée des agents
STIB_AGENT_API_URL	Origine serveur privée imposée aux runtimes agent ; les agents directs utilisent sinon le loopback et les sandboxes Docker host.docker.internal
STIB_ALLOW_REMOTE_CALLBACK	Autorise les callbacks agent depuis des adresses RFC1918 de confiance ; désactivé par défaut
STIB_ALLOW_PRIVATE_URLS	Autorise les URL d’intégration vers des réseaux privés ; désactivé par défaut

Les deux variables ALLOW_… élargissent l’accès réseau. Activez-les uniquement dans une architecture volontaire et de confiance.

Sauvegardes

Utilisez Paramètres → Serveur → Sauvegarde pour créer une sauvegarde cohérente et régler planification/rétention. Préférez ce flux à la copie d’un fichier SQLite en cours d’écriture. Stockez les sauvegardes hors du domaine de panne contre lequel vous vous protégez.

Un export facilite la portabilité, mais ne remplace pas une sauvegarde opérationnelle complète. Testez une restauration avant de dépendre d’une politique.

Logs

Les logs serveur résident sous le dossier de données. Export de logs peut transmettre des enregistrements structurés à une destination configurée. L’application bureau possède un export distinct pour ses diagnostics côté client.

N’incluez pas tokens, clés API, payloads d’identifiants ou prompts privés complets dans un bundle de support sans destinataire et canal de confiance.

Suite : Authentification, Intégrations et Paramètres.