Héberger Kisuno vous-même

Ce dont vous avez besoin

Pour Kisuno, il vous faut une machine Ubuntu avec Docker Engine et Compose v2, un enregistrement DNS pointant dessus et une clé API de votre passerelle de modèles. Le stack tourne intégralement sur cet unique hôte, car la charge de calcul des modèles de langage repose sur le fournisseur d’inférence.

Serveur et prérequis système

Le minimum est de 2 vCPU, 4 Go de RAM, 40 Go de disque et Ubuntu 22.04 LTS. Pour la production, nous recommandons 4 vCPU, 16 Go de RAM et 200 Go de disque sur Ubuntu 24.04 LTS ; la répartition selon la taille de l’équipe figure dans le tableau ci-dessous. Le bac à sable de code durci exige en plus la virtualisation imbriquée.

Sous charge, seule la mémoire de l’application de chat augmente réellement, l’utilisation du processeur restant proche de zéro. Les images occupent environ 5 à 6 Go une seule fois et sont partagées entre les instances d’une même machine. Ensuite, ce sont surtout les téléversements qui croissent : la première limite en exploitation est l’espace disque.

Ce dont vous n’avez pas besoin

• Pas de Kubernetes. Docker Compose est l’architecture prise en charge, aucun chart Helm n’est fourni.
• Pas de GPU pour la couche applicative. Le matériel GPU n’est nécessaire que si vous souhaitez exécuter en plus des modèles de langage en local.
• Pas de compte chez nous. L’installation se déroule sans inscription, sans clé de licence et sans serveur de licences.
• Pas d’hyperscaler ni de base de données managée. Toute VM Ubuntu suffit, la base de données et l’index de recherche tournent dans le même stack.

Installation en trois étapes

L’installation de Kisuno se résume à deux scripts et à une entrée dans le fichier .env. Sur une machine où Docker tourne déjà, la première étape est superflue.

Étape 1 : préparer le serveur

Le dépôt GitHub est à venir prochainement. Si vous souhaitez démarrer dès aujourd’hui, demandez un accès à l’instance gérée via le formulaire. Les commandes montrent à quoi ressemble ensuite l’installation : cloner le dépôt, se placer dans le répertoire distribution, lancer le script de préparation.

cd distribution
./setup-server.sh

Le script est idempotent et installe Docker Engine ainsi que Compose v2 depuis la source officielle de Docker, car le paquet Ubuntu docker.io ne fournit pas Compose v2. S’y ajoutent la rotation des journaux, des règles de pare-feu pour les ports 22, 80 et 443, le swap, le fuseau horaire et les mises à jour de sécurité automatiques. Reconnectez-vous ensuite une fois.

Étape 2 : installer le stack

./install.sh --profiles production

L’installateur vérifie Docker et Compose v2, crée le fichier .env à partir du modèle, génère tous les secrets, crée les répertoires de données et le réseau du bac à sable, télécharge les images et démarre le stack. Le profil production inclut le reverse proxy, qui obtient automatiquement le certificat TLS.

Étape 3 : renseigner l’accès aux modèles

# .env
MODEL_API_KEY=<euer-api-key>

docker compose up -d

Sans clé, le stack démarre, mais le chat signale une clé API manquante. L’accès est libre, car Kisuno dialogue avec toute passerelle compatible OpenAI. Dans l’instance gérée, nous proposons les modèles actuels d’OpenAI (ChatGPT) et d’Anthropic (Claude) ; ils sont exécutés dans le centre de données AWS de Francfort. AWS est une entreprise américaine, le US CLOUD Act s’applique donc même avec des serveurs à Francfort, et nous le disons ouvertement. Pour les clients aux exigences élevées en matière de protection des données, des modèles ouverts de premier plan comme GLM, Kimi et DeepSeek sont disponibles, exploités par des entreprises européennes sur des serveurs en Europe ; le US CLOUD Act ne s’y applique pas. En auto-hébergement, vous choisissez vous-même chaque fournisseur de cette chaîne et renseignez votre propre point de terminaison.

Les services qui composent le stack

Le stack repose sur un fichier docker-compose.yml ; plusieurs services se trouvent derrière des profils optionnels et ne démarrent que si vous les activez. Chaque service est un projet open source reconnu et peut être inspecté, remplacé ou désactivé individuellement.

L’application de chat repose sur LibreChat sous licence MIT et fournit l’interface, les comptes, les conversations, les téléversements de fichiers et la connexion aux modèles. Kisuno maintient cette partie proche de l’amont, afin que les mises à jour de sécurité du projet restent reprenables.

MongoDB stocke les conversations, les comptes, les rôles et les paramètres, sous forme de conteneur dans le même stack et sur votre disque. Il n’existe aucun service de base de données externe vers lequel des contenus pourraient s’échapper.

Meilisearch assure la recherche plein texte dans vos propres conversations. L’index est local et peut être reconstruit ; la télémétrie de Meilisearch est désactivée d’usine.

L’API RAG avec pgvector est optionnelle et s’ajoute via le profil filesearch. L’API RAG indexe par embeddings les fichiers que les utilisateurs téléversent dans le chat et restitue au modèle les passages pertinents lorsqu’il répond.

La passerelle MCP se place entre l’application de chat et chaque système connecté et décide, pour chaque appel d’outil, s’il est autorisé. L’évaluation se fait dans cet ordre : utilisateur individuel, rôle, groupe, réglage par défaut du serveur. Chaque appel est journalisé et, si la vérification échoue, l’accès est refusé.

Le panneau d’administration est l’interface pour les utilisateurs, les rôles, les groupes, les règles d’accès, le journal d’audit et le budget. Il fait partie du stack, n’écoute qu’en local et n’est accessible depuis l’extérieur que via le reverse proxy.

Le bac à sable de code exécute le code généré par le modèle, afin qu’une demande produise un véritable fichier téléchargeable. Il est déployé à côté comme stack Compose distinct et raccordé via un réseau Docker dédié. Deux backends sont proposés : un backend léger par défaut et un backend durci basé sur une microVM, qui exige la virtualisation imbriquée sur l’hôte. Un proxy de sortie avec liste d’autorisation est en cours.

SearXNG assure la recherche web depuis votre propre stack, sans compte auprès d’un service de recherche. En toute transparence : SearXNG transmet les termes de recherche à des moteurs externes, sans communiquer l’identité de l’utilisateur. Les conversations et les fichiers ne quittent pas la machine.

Caddy termine le TLS, obtient automatiquement les certificats dès que l’enregistrement DNS pointe vers la machine, et constitue le seul service sur les ports 80 et 443. Des variantes sont fournies pour une exploitation derrière un WAF ou avec une autorité de certification interne.

Trois modèles d’exploitation, une seule architecture

Il existe trois modèles d’exploitation et une seule architecture : exploité par vous, dans votre cloud, au besoin par votre prestataire informatique, ou géré par nous. Le stack est identique dans les trois cas. Seuls diffèrent celui qui détient le root, celui qui gère les clés et celui qui assure les mises à jour et les sauvegardes.

Exploité par vous

Vous exploitez la machine, détenez le root, gérez vos clés et assurez vous-même mises à jour et sauvegardes. Le logiciel ne coûte rien, un abonnement de support est optionnel. Ce modèle sert d’étalon : ce qu’un administrateur externe peut mettre en route en deux commandes soutient aussi les autres modèles.

Dans votre cloud

Kisuno tourne sur n’importe quelle VM Ubuntu, dans votre propre centre de données comme chez un fournisseur cloud suisse ou européen. Il n’existe aucune dépendance à un hyperscaler. Un prestataire informatique qui héberge pour ses clients utilise la même architecture : un stack par client.

Géré par nous

Nous prenons en charge l’installation, les mises à jour, les sauvegardes et la supervision et exploitons l’instance dans des centres de données certifiés ISO 27001 de Green à Lupfig, en Suisse. Les certificats sont détenus par Green, et non par Kisuno ; la certification ISO 27001 propre à Kisuno est en cours.

Plusieurs instances sur une machine

La frontière entre clients est le stack Compose, pas la VM : chaque instance dispose de sa propre base de données, de son propre index de recherche, de ses propres téléversements, de ses propres secrets, de son propre réseau Docker et de son propre bac à sable de code. Pour de petites équipes, trois à cinq instances peuvent donc partager la même VM.

Peuvent être partagés les images Docker et un reverse proxy commun. Ne sont jamais partagés la base de données, les téléversements, les secrets, le réseau du bac à sable et la clé du fournisseur de modèles : une clé partagée rend la consommation par client impossible à attribuer, et un réseau de bac à sable partagé supprime la séparation là précisément où s’exécute du code tiers.

Comment se déroulent les mises à jour et ce qui compte en exploitation

Les mises à jour sont reproductibles, car l’image applicative est figée sur un digest plutôt que sur un tag mobile et les autres services tournent sur des versions fixes. Une release de Kisuno est donc une combinaison testée d’image applicative et de services, et deux instances sur la même machine peuvent tourner sur des versions différentes.

git pull
./backup.sh backup
./install.sh --migrate

L’option --migrate laisse le fichier .env intact et reconstruit les services maison. Une sauvegarde s’impose avant chaque mise à jour, suivie d’un bref test fonctionnel. Le retour en arrière passe par la version précédente du fichier Compose.

En exploitation courante, deux points sont importants : la rotation des journaux mise en place par setup-server.sh et l’espace disque, avec une alerte à partir de 70 pour cent d’occupation. Les questions récurrentes sur l’exploitation, les mises à jour et la sauvegarde trouvent leur réponse dans les questions fréquentes.

Un script pour la sauvegarde, la restauration et la migration

Un seul script couvre la sauvegarde, la restauration et la migration de serveur : backup.sh crée une archive à partir du dump de la base de données, du fichier .env et des fichiers téléversés, et la restaure également. Une migration se résume donc à une sauvegarde sur l’ancien serveur, à la copie de l’archive et à une restauration sur le nouveau.

./backup.sh backup            # Archiv erzeugen
./backup.sh list              # vorhandene Archive
./backup.sh restore <archiv>  # ersetzt die Datenbank, fragt vorher nach

L’archive contient des secrets et des conversations et est stockée avec des droits de fichier restrictifs. Elle n’a jamais sa place dans un dépôt ni, non chiffrée, dans un cloud tiers. L’index de recherche n’est pas sauvegardé, car il peut être reconstruit à partir de la base de données.

L’erreur la plus coûteuse lors d’une migration consiste à laisser régénérer les clés de chiffrement au lieu de les reprendre depuis l’ancien fichier .env. Tous les identifiants stockés dans la base de données deviennent alors illisibles. Avec des valeurs reprises, la migration reste une fenêtre de maintenance de 15 à 30 minutes.

Deux règles issues de l’exploitation : répliquer la cible de sauvegarde en dehors de la machine et tester la restauration au moins une fois.

Licence : ce que MIT signifie concrètement

Kisuno paraîtra sous licence MIT prochainement ; l’application de chat sous-jacente LibreChat l’est déjà aujourd’hui. L’auto-hébergement est gratuit, dès un utilisateur et sans inscription chez nous. Ce que cela signifie en détail, et pourquoi c’est la différence décisive dans la comparaison avec d’autres plateformes :

• Aucune limite de sièges. Que 3 ou 300 personnes travaillent sur l’instance ne change rien à la licence.
• Aucune obligation de marque. Nom, logo et couleurs relèvent de la configuration, y compris pour un usage commercial.
• Aucun verrouillage de fonctionnalités. Gestion des droits, journal d’audit, budgets et connexions aux systèmes proviennent de la même source ouverte.
• Code source ouvert. La base LibreChat est déjà consultable publiquement ; le stack, les scripts et les services paraîtront sous licence MIT prochainement et seront alors consultables, forkables et vérifiables, au lieu de reposer sur une promesse.

Sur le plan commercial, nous soutenons le modèle par l’exploitation et l’accompagnement, non par les licences. C’est pourquoi le chemin de retour de l’exploitation gérée vers l’auto-hébergement est également ouvert : même architecture, même archive.

Questions fréquentes sur l’auto-hébergement