Installer AnythingLLM sur un VPS Linux avec Docker : base de connaissances IA auto-hébergée

AnythingLLM : une base de connaissances IA auto-hébergée sur votre VPS

AnythingLLM est une application open source (licence MIT, près de 68 000 étoiles sur GitHub au 5 novembre 2026) développée par Mintplex Labs. Elle transforme un VPS Linux en assistant IA privé capable de répondre à partir de vos propres documents : procédures internes, contrats, documentation technique, tickets, comptes rendus. Le principe s'appelle le RAG (Retrieval-Augmented Generation) : les documents sont découpés en morceaux, convertis en vecteurs et stockés dans une base vectorielle ; à chaque question, les passages les plus proches sont injectés dans le contexte du modèle de langage (LLM), qui répond en citant ses sources.

Tout tourne sur le serveur : l'interface web, le pipeline d'ingestion de documents, la base vectorielle LanceDB intégrée, le modèle d'embedding par défaut et, si vous le connectez à Ollama, le modèle de langage lui-même. Aucune donnée ne quitte le VPS, aucun abonnement par requête, et la version Docker ajoute la gestion multi-utilisateurs avec rôles, les agents IA et une API développeur. La dernière version stable, v1.19.0, est sortie le 26 octobre 2026.

Ce guide couvre le déploiement d'AnythingLLM avec Docker sur un VPS Ubuntu ou Debian, la connexion à Ollama comme backend LLM local, l'import de documents dans un espace de travail (workspace), l'activation du mode multi-utilisateurs, la mise en HTTPS derrière NGINX et les réglages de sécurité à appliquer avant d'ouvrir l'instance à une équipe.

AnythingLLM, Open WebUI ou SillyTavern : quel outil pour quel usage

Les trois interfaces se connectent à Ollama, mais elles ne visent pas le même besoin. Open WebUI reproduit l'expérience ChatGPT pour une équipe, SillyTavern est un client léger orienté personnages et jeu de rôle, AnythingLLM est construit autour des documents et des espaces de travail isolés.

Si vous cherchez un assistant qui répond aux questions d'une équipe sur un corpus de documents, avec des espaces cloisonnés par service ou par client, AnythingLLM est l'outil le plus direct. Pour un chat généraliste avec sélection de modèles, Open WebUI reste la référence. Les deux peuvent cohabiter sur le même VPS et partager la même instance Ollama.

Prérequis

• Un VPS Linux sous Ubuntu 22.04/24.04 LTS ou Debian 12 avec un accès root ou sudo. La documentation officielle demande au minimum 2 Go de RAM, 2 cœurs CPU et 5 Go de disque pour AnythingLLM seul.
• Un processeur x86 avec le jeu d'instructions AVX2 : c'est la seule exigence matérielle stricte, imposée par la base vectorielle LanceDB intégrée. Les processeurs ARM ne sont pas concernés.
• Si Ollama tourne sur le même VPS pour l'inférence locale : comptez 8 Go de RAM pour un modèle 7 à 8 milliards de paramètres quantifié, en plus de la mémoire d'AnythingLLM. Consultez notre guide gérer les modèles Ollama sur un VPS Linux pour dimensionner correctement.
• Docker Engine et le plugin Docker Compose installés (installer Docker sur un VPS Linux).
• Un nom de domaine avec un enregistrement DNS A pointant vers l'adresse IP du VPS, pour l'accès HTTPS.
• Les ports TCP 80 et 443 ouverts dans le pare-feu, et le port 3001 fermé depuis l'extérieur (configurer UFW).

Vérifiez la présence d'AVX2 avant de lancer quoi que ce soit. Sans sortie, le conteneur s'arrêtera avec l'erreur Illegal instruction (core dumped) :

lscpu | grep -o avx2 | head -1

Dans une machine virtuelle, l'hyperviseur peut masquer AVX2 derrière un modèle de CPU générique : la vérification se fait donc toujours depuis l'invité, pas depuis la fiche technique du processeur physique. Si la commande ne renvoie rien sur un serveur que vous gérez vous-même sous Proxmox, passez le type de CPU de la VM à host.

Déployer AnythingLLM avec Docker

L'image officielle est publiée sur Docker Hub sous mintplexlabs/anythingllm. Le tag latest est reconstruit à chaque commit sur la branche de développement ; pour un serveur de production, préférez un tag de version fixe comme 1.19.0, qui ne change jamais. Un tag pg existe aussi pour stocker toutes les données dans PostgreSQL avec l'extension pgvector, utile pour une montée en charge horizontale.

Créez le répertoire de stockage, le fichier .env vide et donnez-les à l'UID 1000, celui de l'utilisateur sous lequel le conteneur tourne. Sans cette étape, le conteneur s'arrête avec unable to open database file dès que le dossier appartient à root :

export STORAGE_LOCATION=/var/lib/anythingllm
sudo mkdir -p "$STORAGE_LOCATION"
sudo touch "$STORAGE_LOCATION/.env"
sudo chown -R 1000:1000 "$STORAGE_LOCATION"

Lancez ensuite le conteneur. Le port 3001 est lié à 127.0.0.1 : AnythingLLM n'est joignable que depuis le VPS lui-même, le reverse proxy NGINX s'occupera de l'accès externe en HTTPS :

docker run -d --name anythingllm \
  --restart unless-stopped \
  -p 127.0.0.1:3001:3001 \
  --cap-add SYS_ADMIN \
  --add-host=host.docker.internal:host-gateway \
  -v "$STORAGE_LOCATION:/app/server/storage" \
  -v "$STORAGE_LOCATION/.env:/app/server/.env" \
  -e STORAGE_DIR="/app/server/storage" \
  mintplexlabs/anythingllm:1.19.0

Détail des options de cette commande :

• --cap-add SYS_ADMIN : requis par la documentation officielle pour le scraping de pages web, qui s'appuie sur Puppeteer et un Chromium en bac à sable. Sans cette capacité, l'import d'une URL et le navigateur des agents échouent.
• --add-host=host.docker.internal:host-gateway : fait résoudre host.docker.internal vers l'adresse de la passerelle Docker, ce qui permet au conteneur d'atteindre un Ollama installé directement sur le VPS. Sur Linux, la documentation indique aussi l'adresse 172.17.0.1, celle du pont Docker par défaut.
• -v .../storage : persiste la base SQLite, les documents convertis, la base vectorielle LanceDB et les modèles d'embedding téléchargés. Sans ce volume, tout disparaît à la recréation du conteneur.
• -v .../.env : AnythingLLM écrit dans ce fichier les réglages choisis dans l'interface (fournisseur LLM, clés d'API, embedder). Il doit exister avant le lancement, sinon Docker crée un répertoire à sa place.

Suivez le démarrage dans les logs, puis vérifiez que le service répond en local :

docker logs -f anythingllm
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3001/api/ping

Un code 200 confirme que le serveur est prêt. L'endpoint /api/ping est celui que la documentation recommande pour la supervision.

Variante Docker Compose

Pour un déploiement reproductible, décrivez le service dans un fichier compose.yaml (guide Docker Compose sur VPS Linux). Le fichier ci-dessous fixe la version, limite l'écoute à l'hôte local et pré-renseigne la connexion à Ollama via des variables d'environnement, ce qui évite de ressaisir ces valeurs dans l'assistant de premier démarrage :

mkdir -p ~/anythingllm && cd ~/anythingllm
nano compose.yaml

services:
  anythingllm:
    image: mintplexlabs/anythingllm:1.19.0
    container_name: anythingllm
    restart: unless-stopped
    cap_add:
      - SYS_ADMIN
    ports:
      - "127.0.0.1:3001:3001"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - /var/lib/anythingllm:/app/server/storage
      - /var/lib/anythingllm/.env:/app/server/.env
    environment:
      - STORAGE_DIR=/app/server/storage
      - LLM_PROVIDER=ollama
      - OLLAMA_BASE_PATH=http://host.docker.internal:11434
      - OLLAMA_MODEL_PREF=llama3.1
      - OLLAMA_MODEL_TOKEN_LIMIT=4096
      - EMBEDDING_ENGINE=native
      - VECTOR_DB=lancedb
      - DISABLE_TELEMETRY=true
      - DISABLE_SWAGGER_DOCS=true
      - DISABLE_METRICS_ENDPOINT=true

docker compose up -d
docker compose logs -f anythingllm

Les variables LLM_PROVIDER, OLLAMA_BASE_PATH, OLLAMA_MODEL_PREF et OLLAMA_MODEL_TOKEN_LIMIT reprennent les noms documentés dans le fichier .env.example du projet. EMBEDDING_ENGINE=native et VECTOR_DB=lancedb sont les valeurs par défaut, écrites ici pour expliciter la configuration. Les trois dernières variables désactivent la télémétrie anonyme, la documentation Swagger sur /api/docs et l'endpoint de métriques non authentifié, trois réglages que la documentation recommande en production.

Connecter AnythingLLM à Ollama

Ollama fournit le modèle de langage et, si vous le souhaitez, le modèle d'embedding. Deux architectures sont possibles sur un VPS.

Ollama installé en natif sur le VPS

C'est le cas si vous avez suivi notre guide installer Ollama sur un VPS Linux. Par défaut, Ollama n'écoute que sur 127.0.0.1:11434, une adresse que le conteneur ne peut pas atteindre : depuis Docker, localhost désigne le conteneur lui-même. Il faut donc faire écouter Ollama sur toutes les interfaces, en gardant le port 11434 fermé dans le pare-feu pour que seul le trafic local et celui du pont Docker y accèdent :

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ufw status | grep 11434 || echo "port 11434 non exposé : OK"

Vérifiez que le conteneur atteint bien l'API Ollama. La réponse JSON liste les modèles installés :

docker exec anythingllm curl -s http://host.docker.internal:11434/api/tags

Si vous n'avez pas encore de modèle, téléchargez-en un adapté à la RAM du VPS, par exemple ollama pull llama3.1 pour un 8B sur 8 Go, ou ollama pull llama3.2 pour un 3B sur 4 Go.

Ollama dans un conteneur sur le même réseau Docker

Si vous préférez tout gérer dans Compose, ajoutez un service ollama à côté d'AnythingLLM. Les deux conteneurs partagent alors un réseau interne et le nom du service sert de nom d'hôte, sans rien ouvrir sur l'hôte :

services:
  anythingllm:
    # ... configuration vue plus haut ...
    environment:
      - OLLAMA_BASE_PATH=http://ollama:11434
    depends_on:
      - ollama

  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ollama_data:/root/.ollama

volumes:
  ollama_data:

docker exec ollama ollama pull llama3.1

Réglages côté AnythingLLM

Dans l'interface, ouvrez les paramètres, section LLM, choisissez Ollama comme fournisseur et renseignez l'URL de base. AnythingLLM teste automatiquement http://127.0.0.1:11434, http://host.docker.internal:11434 et http://172.17.0.1:11434 ; si aucun modèle n'apparaît dans la liste, c'est presque toujours une URL incorrecte. Sélectionnez ensuite le modèle et la taille de contexte (OLLAMA_MODEL_TOKEN_LIMIT, 4096 jetons par défaut). Une fenêtre plus large permet d'injecter davantage de passages de documents dans chaque réponse, au prix d'une consommation mémoire plus élevée côté Ollama.

Pour l'embedding, le modèle intégré all-MiniLM-L6-v2 tourne sur le CPU du VPS et suffit pour quelques centaines de documents. Vous pouvez aussi choisir Ollama comme embedder avec un modèle dédié comme nomic-embed-text, celui que l'exemple Compose du projet utilise. Attention : l'embedder est un réglage global de l'instance, et en changer après coup impose de supprimer puis de réimporter tous les documents déjà vectorisés.

Premier démarrage et création d'un espace de travail

Tant que NGINX n'est pas en place, accédez à l'interface par un tunnel SSH depuis votre poste : ssh -L 3001:127.0.0.1:3001 user@IP_DU_VPS, puis ouvrez http://localhost:3001 dans votre navigateur. L'assistant de premier démarrage demande le fournisseur LLM, puis propose de protéger l'instance par mot de passe ou d'activer le mode multi-utilisateurs. Activez l'une des deux options immédiatement : une instance fraîchement installée n'a aucune authentification.

Créez ensuite un premier espace de travail (workspace). Chaque espace a ses propres documents, son prompt système, son historique et, si vous le souhaitez, son propre modèle de langage. Pour une organisation, c'est l'unité de cloisonnement naturelle : un espace « Support » avec les procédures de niveau 1, un espace « Juridique » avec les contrats types, un espace « Infra » avec les runbooks. Un utilisateur de rôle Default ne voit que les espaces auxquels un administrateur l'a ajouté.

Importer des documents et construire la base de connaissances

Le collecteur d'AnythingLLM convertit en texte une large gamme de formats. La liste ci-dessous est tirée du fichier de constantes du collecteur dans le dépôt du projet :

Au-delà des fichiers, les connecteurs de données importent un dépôt GitHub, GitLab ou Gitea, les transcriptions d'une vidéo YouTube, un espace Confluence ou Drupal Wiki, un coffre Obsidian, les documents d'une instance Paperless-ngx, ou un site web entier à partir d'une URL avec une profondeur de crawl. C'est ce dernier connecteur qui justifie la capacité SYS_ADMIN accordée au conteneur.

Le flux d'ingestion se déroule en trois temps. L'upload convertit le fichier en texte brut. L'embedding dans un espace de travail découpe ce texte en morceaux (1 000 caractères avec un chevauchement de 20 par défaut, modifiable dans les paramètres de découpage) et vectorise chaque morceau. Enfin, à chaque question, la base vectorielle renvoie les 4 à 6 morceaux les plus proches par distance cosinus, filtrés par un seuil de similarité réglable, et les injecte dans le prompt système envoyé au LLM.

Deux réglages par espace de travail changent beaucoup le comportement :

• Mode Chat ou Query : en mode Chat, le modèle combine les documents et ses connaissances générales ; en mode Query, il ne répond qu'à partir des documents et signale quand il ne trouve rien. Pour une base de connaissances d'entreprise, le mode Query évite les réponses inventées.
• Épinglage (pin) : un document épinglé est injecté en entier dans le contexte à chaque requête au lieu de passer par la recherche vectorielle. À réserver aux documents courts et critiques, comme une charte ou une grille tarifaire, qui doivent tenir dans la fenêtre de contexte du modèle.

Un document glissé directement dans la fenêtre de chat n'est pas vectorisé : son texte intégral est joint à la conversation en cours, et il n'est pas disponible dans les autres fils. Pour qu'un document serve à tout l'espace de travail, passez par le gestionnaire de documents et le bouton d'embedding.

Activer le mode multi-utilisateurs

AnythingLLM propose deux niveaux de protection, tous deux réservés à la version Docker. Le premier, Password Protect Instance, pose un mot de passe unique : toute personne qui le connaît a le contrôle complet de l'instance et voit toutes les conversations. Le second, le mode multi-utilisateurs, crée des comptes individuels avec trois rôles :

Pour l'activer, ouvrez les paramètres de sécurité de l'instance, basculez Enable multi-user mode et saisissez le nom d'utilisateur et le mot de passe du premier compte administrateur. Vous êtes déconnecté et devez vous reconnecter avec ce compte. Le passage est irréversible : une instance en mode multi-utilisateurs ne revient pas en mode mono-utilisateur.

Les comptes se créent ensuite depuis la section d'administration : la page Users pour créer un utilisateur, lui attribuer un rôle et cocher les espaces de travail auxquels il accède, et la page Invitations pour générer des liens d'invitation. Deux variables d'environnement complètent le dispositif : PASSWORDMINCHAR fixe la longueur minimale des mots de passe (8 caractères par défaut, montez à 12 ou plus) et JWT_EXPIRY la durée des sessions (30 jours par défaut).

Pour un usage personnel ou une petite équipe de confiance, le mot de passe d'instance suffit. Dès qu'il y a des documents confidentiels à cloisonner entre services, le mode multi-utilisateurs s'impose, puisque c'est lui qui rend la séparation par espace de travail effective.

Agents IA : aller au-delà du chat sur documents

La recherche vectorielle a une limite : elle ne renvoie que quelques morceaux par question. Demander « liste tous les contrats qui expirent en 2027 » sur un corpus de 300 documents échoue, parce que les passages pertinents ne sont jamais tous remontés. C'est le domaine des agents. En commençant un message par @agent, vous ouvrez une session où le modèle peut appeler des outils : recherche RAG, listage et résumé de documents, navigation web, scraping d'une page, génération de graphiques, sauvegarde de fichiers, requêtes SQL sur une base connectée, génération de documents, et planification de tâches récurrentes.

Les agents s'étendent de deux façons. Agent Flows permet de construire sans code des enchaînements d'étapes réutilisables. Les serveurs MCP (Model Context Protocol) ajoutent des outils externes, par exemple une connexion à votre outil de ticketing ou à une base de données interne. Vérifiez au préalable que le modèle Ollama choisi gère l'appel natif d'outils : AnythingLLM le détecte automatiquement. Pour un modèle qui ne le gère pas, la variable PROVIDER_DISABLE_NATIVE_TOOL_CALLING=ollama force un appel d'outils par prompt, moins fiable sur les petits modèles.

Sur un VPS partagé par plusieurs personnes, deux variables méritent attention : AGENT_AUTO_APPROVED_SKILLS liste les outils que les agents peuvent exécuter sans validation humaine, et COLLECTOR_ALLOW_ANY_IP, désactivé par défaut, doit le rester pour empêcher un agent de scraper des adresses de votre réseau privé.

Mettre en HTTPS avec un reverse proxy NGINX

La documentation officielle recommande de ne pas exposer le port 3001 et de placer NGINX devant avec un certificat Let's Encrypt. Installez NGINX et Certbot (guide NGINX reverse proxy), puis créez le virtual host :

sudo apt update && sudo apt install -y nginx certbot python3-certbot-nginx
sudo nano /etc/nginx/sites-available/anythingllm

server {
    listen 80;
    server_name ia.exemple.fr;

    client_max_body_size 100M;

    location /api/agent-invocation/ {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 605s;
    }

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 605s;
        proxy_send_timeout 605s;
    }
}

Le bloc /api/agent-invocation/ transmet les en-têtes WebSocket dont les sessions d'agents ont besoin ; les délais de 605 secondes et la désactivation du buffering reprennent la configuration d'exemple de la documentation, indispensables pour que les réponses s'affichent en streaming et que les longues générations sur CPU n'expirent pas. client_max_body_size autorise l'upload de documents volumineux.

sudo ln -s /etc/nginx/sites-available/anythingllm /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d ia.exemple.fr

Certbot réécrit le bloc server pour écouter en 443 et rediriger le HTTP vers le HTTPS ; le renouvellement est pris en charge par un timer systemd (guide Certbot et Let's Encrypt).

Sécuriser l'instance avant d'ouvrir l'accès

• Authentification activée : mot de passe d'instance ou mode multi-utilisateurs, avant toute exposition publique. Sans cela, n'importe qui peut lire vos documents.
• Port 3001 lié à 127.0.0.1 : vérifiez avec ss -tlnp | grep 3001 que l'écoute n'est pas sur 0.0.0.0. Rappel : un port publié par Docker sur toutes les interfaces contourne les règles UFW classiques, d'où l'importance de la liaison locale.
• Endpoints techniques désactivés : DISABLE_SWAGGER_DOCS=true et DISABLE_METRICS_ENDPOINT=true ferment la documentation d'API et un endpoint de métriques accessible sans authentification.
• Widget de chat : si vous utilisez le widget embarquable, EMBED_REQUIRE_ALLOWLIST=true rejette les requêtes des widgets sans liste de domaines autorisés, qui acceptent sinon toutes les origines.
• Suppression protégée : WORKSPACE_DELETION_PROTECTION=true empêche la suppression d'un espace de travail depuis l'interface et l'API.
• Clés d'API : réservées aux comptes qui en ont le droit, elles donnent un accès complet ; ne les publiez jamais dans un dépôt.
• Le serveur lui-même : SSH par clé uniquement et Fail2ban contre les tentatives répétées.

Mettre à jour et sauvegarder

Toutes les données d'AnythingLLM vivent dans le répertoire de stockage monté : la base SQLite anythingllm.db, les documents convertis, les vecteurs LanceDB, le fichier .env avec vos clés et réglages. Une mise à jour consiste à changer le tag d'image et à recréer le conteneur, le volume restant intact :

cd ~/anythingllm
sed -i 's/anythingllm:1.19.0/anythingllm:1.19.1/' compose.yaml   # adaptez au numéro publié
docker compose pull && docker compose up -d
docker image prune -f

Consultez la page des releases du projet avant chaque montée de version : certaines introduisent des migrations de base de données qui s'exécutent au démarrage. Après la mise à jour, nettoyez les anciennes images (nettoyer Docker avec prune).

Pour la sauvegarde, arrêtez brièvement le conteneur pour obtenir une copie cohérente de la base SQLite, puis synchronisez le répertoire vers un stockage distant (sauvegarder un VPS avec rsync) :

docker stop anythingllm
rsync -az --delete /var/lib/anythingllm/ user@backup:/backups/anythingllm/
docker start anythingllm

Le répertoire grossit avec les documents et les modèles d'embedding téléchargés : surveillez l'espace disque et la mémoire avec htop ou btop, surtout si Ollama partage le VPS. Pour un corpus de plusieurs milliers de documents ou des modèles au-delà de 14 milliards de paramètres, un serveur dédié avec davantage de RAM, voire un GPU, devient le bon support ; notre comparatif vLLM vs Ollama détaille les moteurs d'inférence adaptés à cette échelle.

Tableau récapitulatif

Conclusion

AnythingLLM fournit en un conteneur ce qu'il fallait auparavant assembler à la main : une interface de chat, un pipeline d'ingestion de documents, une base vectorielle et une gestion des accès. Connecté à Ollama sur le même VPS Linux, il donne à une équipe un assistant qui répond à partir de ses propres procédures et contrats, sans qu'un seul octet ne parte vers un service tiers. Les points à ne pas négliger sont l'AVX2 du processeur, les permissions du répertoire de stockage, l'authentification avant toute exposition et le reverse proxy NGINX en HTTPS.

Pour prolonger ce déploiement, l'API développeur d'AnythingLLM se combine bien avec un orchestrateur comme n8n pour alimenter automatiquement la base de connaissances depuis vos outils métier, et un Nextcloud sur le même serveur peut servir de source de documents partagée.