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, après une sauvegarde — voir Sauvegardes avant migration.

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 des connexions serveur vers des réseaux privés ; désactivé par défaut
STIB_SKIP_PRE_MIGRATION_BACKUP	Applique les migrations en attente sans la sauvegarde automatique — donc sans retour arrière automatique ; 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. STIB_ALLOW_PRIVATE_URLS ne couvre que les connexions serveur : une connexion appartenant à un projet reste sur des hôtes publics quoi que dise l’environnement.

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.

Sauvegardes avant migration

Quand une nouvelle version démarre sur une base existante qu’elle doit migrer, elle écrit d’abord une sauvegarde nommée stib-pre-migration-<date>.db dans data/backups/, puis applique les migrations. Quel que soit le chemin de mise à jour — installeur, image Docker ou binaire remplacé à la main —, cela se passe au démarrage, avant que le serveur n’accepte la moindre requête.

• Si une migration échoue, le serveur remet cette sauvegarde à la place de la base à moitié migrée, puis s’arrête. La base est exactement celle que la version précédente avait laissée : réinstallez cette version, ou attendez une version qui corrige la migration.
• Si la sauvegarde ne peut pas être écrite — le plus souvent parce que le disque ne peut pas contenir une copie de la base —, le serveur s’arrête sans rien migrer. Libérez de la place, ou définissez STIB_SKIP_PRE_MIGRATION_BACKUP=1 pour migrer sans point de retour.

Ces sauvegardes sont toujours stockées en local, quel que soit le fournisseur configuré, et les trois plus récentes sont conservées. Elles sont compressées, et chiffrées quand une clé de sauvegarde est configurée, comme toutes les autres. Avec S3 ou WebDAV, elles n’apparaissent pas dans la liste des sauvegardes : ouvrez le dossier des sauvegardes pour les retrouver.

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.