AnythingLLM sur VPS : guide complet avec pièges à éviter

Pourquoi self-héberger AnythingLLM sur un VPS

AnythingLLM est avant tout un moteur RAG complet : ingestion de documents, découpage, vectorisation, recherche sémantique et génération, le tout dans une interface multi-utilisateurs accessible depuis un navigateur. Le cœur du sujet, c'est la donnée : rapports financiers, contrats, documentation produit, base de connaissances support. Ces fichiers n'ont pas vocation à transiter chez un fournisseur SaaS d'ingestion tiers.

Sur un VPS, l'embarqueur de documents, la base vectorielle (LanceDB intégré par défaut) et l'historique des conversations restent dans vos volumes Docker — jamais dupliqués ailleurs sans votre accord. Vous contrôlez qui accède à quel espace de travail, vous choisissez librement le LLM (API cloud ou modèle local via Ollama), et vous échappez aux quotas d'ingestion des offres SaaS qui plafonnent le nombre de pages ou de fichiers.

Pour une agence qui gère plusieurs clients, chaque workspace devient un silo étanche : documents cloisonnés, droits par rôle, aucune fuite entre équipes. Pour une entreprise, c'est la conformité qui prime : les données restent sur votre infrastructure, dans votre juridiction, sous votre politique de sauvegarde.

Les bénéfices concrets d'un AnythingLLM auto-hébergé

Documents confidentiels indexés localement, jamais envoyés à un service d'ingestion tiers.
Espaces de travail cloisonnés par client ou par équipe, avec gestion fine des rôles (Administrateur, Manager, Standard).
Base vectorielle au choix : LanceDB embarqué pour démarrer, Chroma ou Qdrant externe pour les gros corpus.
Connexion à plus de 20 fournisseurs LLM, dont un Ollama local pour le zéro-cloud et zéro-coût d'inférence.
Aucune limite sur le nombre de documents, de pages ou d'espaces de travail ingérés.
Sauvegarde simple et portable : tout l'état tient dans un unique volume storage à archiver ou répliquer.
Agents IA no-code intégrés : créez des pipelines d'automatisation sans quitter l'interface.
API REST complète pour intégrer AnythingLLM dans vos propres applications ou scripts d'automatisation.

Prérequis matériels et logiciels

Le conteneur AnythingLLM est raisonnable en ressources, mais l'embedding d'un gros corpus consomme CPU et RAM de manière significative. Visez 2 vCPU / 2 Go de RAM pour démarrer avec quelques centaines de documents et un LLM en API cloud. Montez à 4 vCPU / 8 Go si vous indexez des milliers de documents, utilisez un modèle d'embedding local, ou faites tourner Ollama sur le même hôte.

Prévoyez 15 à 20 Go de disque au minimum : les vecteurs et le cache de documents grossissent vite, surtout avec des PDF denses ou des corpus multilingues. Ajoutez de la marge si vous déployez aussi Qdrant ou Ollama sur le même VPS.

Côté logiciel, il vous faut :
- Docker et Docker Compose (v2 recommandé)
- Un nom de domaine ou sous-domaine pointant sur votre VPS (ex. chat.votre-domaine.com)
- Le port 443 ouvert en entrée sur votre pare-feu
- Une clé API LLM (OpenAI, Anthropic, Mistral…) si vous n'utilisez pas Ollama en local

Note importante sur les versions : avant toute commande docker pull, lisez la section Épinglage de version plus bas. Tirer :latest sans précaution peut effacer définitivement vos embeddings.

Épinglage de version : critique et irréversible

N'utilisez jamais le tag :latest en production. Un docker pull mintplexlabs/anythingllm:latest peut écraser la clé de chiffrement interne des embeddings stockés dans votre volume, rendant tous vos documents vectorisés illisibles de façon permanente — sans possibilité de récupération.

Ce comportement est documenté comme breaking change depuis mars 2026 (issue GitHub #5256).

La règle à suivre : épinglez toujours une version fixe dans votre docker-compose.yml :

image: mintplexlabs/anythingllm:v1.8.4

Avant de mettre à jour, lisez les release notes de chaque version intermédiaire, sauvegardez votre volume storage complet, et testez la montée de version sur une copie avant de l'appliquer en production.

Déployer AnythingLLM avec Docker et HTTPS

Créer l'arborescence et les permissions

En SSH sur votre VPS, créez le répertoire de travail et le volume de données :

mkdir -p /opt/anythingllm/storage
cd /opt/anythingllm
chmod -R 777 storage

Le conteneur tourne avec un UID dédié (non root) : les permissions 777 sur storage sont nécessaires pour que le processus interne puisse écrire la base vectorielle et les uploads de documents.

Écrire le docker-compose.yml avec une version épinglée

Créez /opt/anythingllm/docker-compose.yml. Notez le tag de version fixe — ne mettez pas :latest :

services:
  anythingllm:
    image: mintplexlabs/anythingllm:v1.8.4
    container_name: anythingllm
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./storage:/app/server/storage
    env_file:
      - .env
    cap_add:
      - SYS_ADMIN

Puis créez .env dans le même dossier avec au minimum :

JWT_SECRET=changez-moi-par-une-chaine-aleatoire-longue
STORAGE_DIR=/app/server/storage
LLM_PROVIDER=openai
OPEN_AI_KEY=sk-votre-cle-openai

Remplacez LLM_PROVIDER et la clé selon votre fournisseur. Pour Ollama local, voir l'étape suivante.

Configurer Ollama si vous optez pour le 100 % local

Si Ollama tourne sur le même hôte que le conteneur AnythingLLM, n'utilisez pas localhost — depuis l'intérieur du conteneur, localhost désigne le conteneur lui-même, pas l'hôte.

URL correcte selon l'OS :
- Linux : http://172.17.0.1:11434 (adresse du bridge Docker par défaut)
- macOS / Windows : http://host.docker.internal:11434

Dans votre .env :

LLM_PROVIDER=ollama
OLLAMA_BASE_PATH=http://172.17.0.1:11434
OLLAMA_MODEL_PREF=llama3.2
EMBEDDING_ENGINE=ollama
EMBEDDING_BASE_PATH=http://172.17.0.1:11434
EMBEDDING_MODEL_PREF=nomic-embed-text

Vérifiez qu'Ollama écoute bien sur 0.0.0.0 (pas seulement 127.0.0.1) en contrôlant OLLAMA_HOST=0.0.0.0 dans son unité systemd ou sa variable d'environnement.

Démarrer le conteneur et créer le compte admin

Lancez le service :

docker compose up -d
docker compose logs -f

Attendez les lignes [server] Listening on port 3001 et [database] Migration complete. Puis accédez à http://votre-ip:3001 depuis votre poste (accès temporaire, à couper après configuration du reverse proxy). L'assistant de configuration vous guide pour créer le compte administrateur et choisir le modèle d'embedding et le LLM.

Mettre en place le reverse proxy avec HTTPS

Avec Nginx (exemple minimal) ou Caddy, exposez AnythingLLM derrière votre domaine.

Exemple Caddy (le plus simple, Let's Encrypt automatique) :

chat.votre-domaine.com {
    reverse_proxy localhost:3001
    request_body {
        max_size 100MB
    }
}

Exemple Nginx (bloc server) :

server {
    listen 443 ssl;
    server_name chat.votre-domaine.com;
    ssl_certificate /etc/letsencrypt/live/chat.votre-domaine.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/chat.votre-domaine.com/privkey.pem;
    client_max_body_size 100M;
    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

La directive client_max_body_size (Nginx) ou max_size (Caddy) est indispensable pour permettre l'upload de gros PDF ou d'archives de documents.

Créer un workspace, ingérer des documents et tester

Dans l'interface, cliquez « + Nouveau workspace », donnez-lui un nom, puis glissez quelques PDF dans la zone d'upload. Lancez l'embedding (bouton « Sauvegarder et embarquer »). Une fois terminé, posez une question dans le chat — les réponses doivent citer les sources extraites de vos fichiers.

Si les citations n'apparaissent pas, vérifiez dans les paramètres de workspace que le mode RAG est bien activé (option « Chat mode » → « Query »), et que le nombre de chunks retournés est supérieur à 0.

Activer le mode multi-utilisateurs et sécuriser l'accès

Dans les Paramètres → Multi-User Mode, activez le mode multi-utilisateur. Invitez vos collaborateurs par e-mail et attribuez les rôles : Administrateur (accès total), Manager (gestion des workspaces), Standard (utilisation uniquement).

Restreignez chaque utilisateur aux seuls workspaces qui le concernent. Depuis l'interface admin, vous pouvez également configurer un SSO ou une authentification externe si votre fournisseur LLM le supporte.

Dépannage : les trois pièges les plus fréquents

Ces trois problèmes reviennent régulièrement dans la communauté AnythingLLM. Les connaître avant de déployer vous évitera des heures de debug.

Piège 1 — :latest efface vos embeddings (critique, irréversible)

Si vous mettez à jour votre conteneur avec docker pull mintplexlabs/anythingllm:latest, une nouvelle version peut écraser la clé de chiffrement des embeddings stockée dans votre volume. Résultat : tous vos documents vectorisés deviennent illisibles, sans possibilité de récupération. Ce breaking change est documenté depuis mars 2026 (issue #5256). Solution : épinglez toujours un tag de version fixe (v1.8.4, v1.9.x…) dans votre docker-compose.yml et ne faites jamais de pull sans sauvegarde préalable du volume storage.

Piège 2 — Les agents Gemini sont cassés depuis la v1.16

Depuis AnythingLLM v1.16, le provider Gemini produit une erreur de connexion en streaming qui reste ouverte indéfiniment, bloquant l'agent (issue #6153, toujours ouverte). Contournement : désactivez le provider Gemini dans les paramètres LLM et utilisez à la place un endpoint compatible OpenAI (ex. gemini-openai-compatible) ou passez sur Ollama. Ne tentez pas de déboguer côté réseau — le problème est dans la gestion du stream côté AnythingLLM.

Piège 3 — Ollama inaccessible depuis le conteneur

Si Ollama est installé directement sur l'hôte (hors Docker), configurer http://localhost:11434 dans AnythingLLM ne fonctionne pas : depuis l'intérieur du conteneur, localhost pointe sur le conteneur lui-même, pas sur l'hôte. Utilisez http://172.17.0.1:11434 sur Linux (IP du bridge Docker) ou http://host.docker.internal:11434 sur macOS/Windows. Vérifiez aussi qu'Ollama écoute sur 0.0.0.0 et non uniquement sur 127.0.0.1 (variable OLLAMA_HOST=0.0.0.0 dans le service systemd).

Pour des corpus volumineux (plus de 10 000 chunks), ne restez pas sur LanceDB embarqué : déployez Qdrant dans un conteneur voisin sur le même réseau Docker et pointez AnythingLLM dessus via la variable VECTOR_DB=qdrant et QDRANT_ENDPOINT=http://qdrant:6333. Qdrant gère mieux les millions de vecteurs, offre du filtrage par métadonnées et reste interrogeable indépendamment, ce qui facilite le debug de vos recherches sémantiques. Le volume Qdrant se sauvegarde lui aussi facilement : un simple docker cp ou un snapshot de volume suffit.

AnythingLLM vs Open WebUI : quel espace de travail IA choisir ?

	AnythingLLM	Open WebUI
Objectif principal	RAG documentaire + agents IA	Interface de chat pour LLM
RAG / ingestion de documents	Intégré (PDF, Word, URL, Notion, GitHub…)	Import de fichiers basique
Constructeur d'agents IA	Oui (no-code)	Non
Fournisseurs de LLM	Plus de 20 (Ollama, OpenAI, Anthropic, Mistral…)	Ollama + compatibles OpenAI
Rôles multi-utilisateurs	Administrateur / Manager / Standard	Gestion des utilisateurs basique
API REST	API complète documents et chat	Limitée
Base vectorielle	LanceDB intégré + interchangeable (Qdrant, Chroma…)	Externe via la configuration RAG
RAM (API seule, sans LLM local)	~512 Mo	~256 Mo
Risque :latest	Critique — efface les embeddings	Moins documenté
Licence	MIT	MIT