Pourquoi ajouter Open-WebUI à votre serveur Ollama
Ollama expose une API REST compatible OpenAI — efficace pour les développeurs, inaccessible pour les autres membres d'une équipe. Open-WebUI comble cet écart : c'est une interface web complète qui se connecte à Ollama (ou à tout autre fournisseur compatible OpenAI) et transforme un serveur d'inférence en outil collaboratif.
Le dépôt dépasse 155 000 étoiles sur GitHub. Attention à la licence : ce n'est pas du MIT. Le projet publie une licence propre, de type BSD à trois clauses, assortie d'une condition : au-delà de 50 utilisateurs sur 30 jours glissants, il est interdit de modifier ou de retirer la marque « Open WebUI », sauf accord écrit ou licence entreprise. Pour une petite équipe, rien ne change ; au-delà, relisez le fichier LICENSE avant de personnaliser l'interface. De son côté, Ollama a annoncé en juillet 2026 une levée de 65 millions de dollars (Series B), signe que le moteur d'inférence s'installe durablement dans les équipes de développement.
Le projet est maintenu de façon continue et publie des tags stables à un rythme soutenu : la version 0.13.0 date du 3 novembre 2026. Cette cadence a un revers, puisque des comportements par défaut changent d'une version mineure à l'autre (l'appel d'outils natif est devenu le défaut en 0.10.0). D'où l'intérêt de figer un tag et de lire les notes de version avant chaque mise à jour. Open-WebUI couvre des besoins bien au-delà du chat : RAG sur des fichiers locaux, gestion de plusieurs modèles, groupes d'utilisateurs, recherche web et intégration SSO via OpenID Connect.
Ce qu'Open-WebUI apporte concrètement à votre stack Ollama
- Interface multi-utilisateurs : chaque membre de l'équipe dispose de son compte, de son historique et de ses conversations — sans accès à l'API brute ni à la ligne de commande.
- RAG natif : importez des fichiers PDF, Markdown ou Word directement depuis l'interface ; Open-WebUI les indexe et les injecte dans le contexte de chaque conversation.
- Gestion des modèles : téléchargez, supprimez et activez des modèles Ollama depuis l'interface web, sans passer par
docker exec. - SSO OpenID Connect : connectez Open-WebUI à votre fournisseur d'identité (Keycloak, Authentik, Google Workspace…) pour un accès unifié et une révocation centralisée.
- Groupes et rôles : définissez qui peut accéder à quels modèles, qui peut télécharger des fichiers, qui a les droits d'administration.
- Aucune dépendance cloud : tous les tokens, toutes les conversations et tous les fichiers restent sur votre infrastructure.
Prérequis matériels et logiciels
Open-WebUI s'exécute en conteneur Docker et se connecte à Ollama via le réseau Docker interne. Les deux peuvent cohabiter sur le même VPS.
Pour un usage équipe de 5 à 10 personnes avec des modèles 7B quantisés (Q4), comptez au minimum :
- 8 Go de RAM (6 Go pour le modèle + marge pour Open-WebUI et le système)
- 4 vCPU : l'inférence sur CPU est lente avec moins de cœurs ; passez à 8 vCPU pour un confort d'usage quotidien
- 30 Go de stockage SSD minimum, plus l'espace pour vos modèles (un modèle 7B Q4 ≈ 4,5 Go, un modèle 13B ≈ 8 Go)
- Docker et Docker Compose installés
- Un nom de domaine pointant vers votre VPS (nécessaire pour TLS et le SSO)
- Un reverse proxy avec HTTPS — Nginx, Traefik ou Caddy (servi en HTTP sur un domaine ou une IP non locale, Open-WebUI perd des fonctions dans le navigateur : voir le dépannage)
Si Ollama est déjà déployé sur votre VPS (voir l'article Comment héberger Ollama sur un VPS), vous pouvez passer directement à l'installation d'Open-WebUI.
Déployer Open-WebUI et Ollama avec Docker Compose
Créer le fichier Docker Compose
Créez un répertoire de travail puis rédigez le fichier de composition :
mkdir -p /opt/openwebui && cd /opt/openwebuiContenu de
compose.yml:services: ollama: image: ollama/ollama:latest container_name: ollama volumes: - ollama_data:/root/.ollama restart: unless-stopped open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui depends_on: - ollama ports: - "127.0.0.1:3000:8080" environment: - OLLAMA_BASE_URL=http://ollama:11434 - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY} volumes: - open_webui_data:/app/backend/data restart: unless-stopped volumes: ollama_data: open_webui_data:La clé
WEBUI_SECRET_KEYdoit être une chaîne aléatoire longue, jamais écrite dans le fichier de composition : générez-la avececho "WEBUI_SECRET_KEY=$(openssl rand -hex 32)" > .env && chmod 600 .env. Docker Compose lit ce fichier.envdu répertoire et remplace${WEBUI_SECRET_KEY}.Démarrer la stack
Lancez les deux services :
docker compose up -dVérifiez que les deux conteneurs sont actifs :
docker compose psOllama peut mettre quelques secondes à démarrer. Open-WebUI attend qu'Ollama soit prêt grâce à
depends_on, mais si vous observez des erreurs de connexion au premier démarrage, attendez 15 secondes et rechargez.Télécharger un premier modèle
Depuis le host, téléchargez un modèle via Ollama :
docker exec -it ollama ollama pull llama3.1:8bVous pouvez aussi le faire depuis l'interface Open-WebUI une fois connecté, dans Panneau d'administration → Modèles → Télécharger depuis Ollama.com.
Configurer le reverse proxy Nginx avec HTTPS
Open-WebUI écoute sur
127.0.0.1:3000. Créez un virtual host Nginx pour l'exposer en HTTPS :server { listen 443 ssl; server_name openwebui.yourdomain.com; ssl_certificate /etc/letsencrypt/live/openwebui.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/openwebui.yourdomain.com/privkey.pem; location / { proxy_pass http://127.0.0.1:3000; 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; # WebSocket (nécessaire pour le streaming des réponses) proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 300s; } }Obtenez le certificat avec Certbot :
certbot --nginx -d openwebui.yourdomain.comL'entête
Connection: upgradeet leproxy_read_timeoutétendu sont indispensables : les réponses des LLM sont diffusées en streaming via WebSocket, et un timeout court coupe la réponse en pleine génération.Créer le compte administrateur
Ouvrez
https://openwebui.yourdomain.comdans votre navigateur. Le premier compte créé devient automatiquement administrateur : créez-le dès la mise en ligne, avant que quelqu'un d'autre ne le fasse. Renseignez un e-mail et un mot de passe.Depuis le panneau d'administration (icône avatar → Panneau d'administration), vous pouvez :
- définir si de nouveaux inscrits sont actifs immédiatement ou en attente de validation ;
- créer des groupes d'utilisateurs et leur associer des modèles ;
- configurer le SSO.
Configurer le SSO OpenID Connect
Open-WebUI prend en charge nativement l'authentification via OpenID Connect (OIDC). Vous pouvez l'intégrer à Keycloak, Authentik, Authelia, ou tout fournisseur compatible (y compris Google Workspace ou Microsoft Entra).
Dans compose.yml, ajoutez les variables d'environnement suivantes au service open-webui :
environment:
- OAUTH_CLIENT_ID=votre-client-id
- OAUTH_CLIENT_SECRET=${OAUTH_CLIENT_SECRET}
- OPENID_PROVIDER_URL=https://votre-idp.example.com/.well-known/openid-configuration
- OAUTH_PROVIDER_NAME=Mon SSO
- ENABLE_OAUTH_SIGNUP=trueComme la clé de session, le secret client se range dans le fichier .env (OAUTH_CLIENT_SECRET=…), pas dans compose.yml. La variable ENABLE_OAUTH_SIGNUP=true permet aux utilisateurs qui s'authentifient via SSO d'être créés automatiquement dans Open-WebUI. Mettez-la à false si vous souhaitez que l'administrateur provisionne chaque compte manuellement.
L'URL de callback à déclarer dans votre fournisseur d'identité est https://openwebui.yourdomain.com/oauth/oidc/callback.
Redémarrez la stack après modification :
docker compose up -dPour limiter l'accès SSO à un domaine e-mail spécifique (ex. @votre-entreprise.com), configurez la restriction directement dans votre fournisseur d'identité, pas dans Open-WebUI. Keycloak et Authentik permettent tous les deux de filtrer par domaine au niveau du client OIDC — c'est le point de contrôle le plus sûr, car il couvre aussi l'API.
Activer le RAG sur vos documents
Open-WebUI intègre un pipeline RAG (Retrieval-Augmented Generation) qui permet d'interroger vos documents locaux dans une conversation. Le traitement se fait entièrement sur votre VPS — aucun document n'est envoyé à un service externe.
Pour activer le RAG :
1. Depuis l'interface, cliquez sur le trombone dans la zone de saisie d'une conversation, ou utilisez l'onglet Documents dans le menu latéral.
2. Importez un fichier PDF, Markdown, DOCX ou TXT. Open-WebUI le découpe, le vectorise et le stocke dans sa base de données locale.
3. Dans la conversation, préfixez votre message avec # suivi du nom du document pour l'injecter comme contexte.
Pour un usage avancé (plusieurs documents, collections thématiques), la section Espace de travail → Documents permet d'organiser les fichiers en collections et de les associer à des modèles spécifiques.
Par défaut, Open-WebUI utilise son propre moteur d'embeddings léger. Pour améliorer les performances sur un corpus important, vous pouvez configurer un modèle d'embeddings Ollama dédié (par exemple nomic-embed-text) dans Panneau d'administration → Documents → Modèle d'embeddings.
Ajouter la recherche web avec SearXNG
La recherche web n'est pas embarquée dans Open-WebUI : l'interface interroge un moteur externe, puis injecte les pages trouvées dans le contexte du modèle. SearXNG, un métamoteur auto-hébergé, évite de dépendre d'une clé d'API payante : il interroge pour vous plusieurs moteurs publics et renvoie une liste unique. C'est aussi sa fragilité, détaillée dans la section de dépannage plus bas.
Trois réglages suffisent. Côté SearXNG, ouvrez settings.yml et ajoutez json à la liste formats située sous search, à côté de html : sans cela, Open-WebUI reçoit une erreur 403. Côté Open-WebUI, ouvrez Panneau d'administration → Réglages → Recherche web, choisissez searxng et saisissez l'URL de requête, par exemple http://searxng:8080/search?q=<query> (variable SEARXNG_QUERY_URL). Vous pouvez aussi poser ENABLE_WEB_SEARCH=true et WEB_SEARCH_ENGINE=searxng dans le compose.yml. Si les deux services partagent un réseau Docker, le nom du service sert d'hôte et le port de SearXNG n'a pas à être publié sur Internet.
Reste un piège : trois interrupteurs doivent être allumés en même temps, la recherche web globale, la capacité « recherche web » du modèle et le bouton de la conversation en cours. Le moindre oubli donne une réponse sans recherche, souvent sans erreur visible.
Open-WebUI, AnythingLLM, LibreChat : quelle interface choisir
Faites défiler le tableau
| Critère | Open-WebUI | AnythingLLM / LibreChat |
|---|---|---|
| Backend LLM | Ollama natif + tout endpoint OpenAI | OpenAI, Ollama, Azure, LM Studio |
| Gestion des utilisateurs | Intégrée, groupes, OIDC natif | Intégrée (AnythingLLM : espaces isolés) |
| RAG | Natif, sans configuration | Natif, configurable (LanceDB, pgvector) |
| Étoiles GitHub | 155 000+ (licence propre, marque protégée) | 65 000+ (MIT) / 45 000+ (MIT) |
| Cas d'usage principal | Équipe avec Ollama déjà déployé | RAG multi-sources avancé / Chat multi-backend |
Dépannage : les erreurs courantes
Connection refused au démarrage d'Open-WebUI.
Ollama n'est pas encore prêt quand Open-WebUI tente de se connecter. Attendez 20 secondes et relancez docker compose restart open-webui. Pour éviter ce problème à chaque redémarrage, ajoutez un healthcheck sur le service Ollama dans compose.yml.
Le streaming s'interrompt après 60 secondes.
Votre reverse proxy applique un timeout HTTP par défaut. Ajoutez proxy_read_timeout 300s; dans le bloc location / de Nginx (ou l'équivalent timeout dans Traefik). Les LLM prennent parfois plusieurs minutes pour générer une longue réponse.
WebSocket connection failed.
Vérifiez que les entêtes Upgrade et Connection sont bien transmis par le reverse proxy. Sans eux, le streaming SSE/WebSocket est bloqué et les réponses n'arrivent pas en temps réel.
L'authentification SSO renvoie redirect_uri_mismatch.
L'URL de callback déclarée dans votre fournisseur d'identité ne correspond pas à celle qu'Open-WebUI envoie. Elle doit être exactement https://openwebui.yourdomain.com/oauth/oidc/callback — avec le nom de domaine complet, sans slash final.
Un utilisateur SSO peut se connecter mais n'a accès à aucun modèle.DEFAULT_USER_ROLE vaut pending par défaut : tout nouveau compte, SSO compris, attend l'activation d'un administrateur, et ENABLE_OAUTH_SIGNUP ne gouverne que la création du compte. Passez leur rôle à user dans Panneau d'administration → Utilisateurs, ou configurez DEFAULT_USER_ROLE=user dans les variables d'environnement.
Écran qui ne répond pas, crypto.randomUUID is not a function dans la console du navigateur.
Open-WebUI est servi en HTTP sur un domaine ou une adresse non locale : le navigateur ne fournit cette fonction qu'en contexte sécurisé (HTTPS ou localhost). Terminez la configuration TLS du reverse proxy avant de tester les fonctions d'IA.
La recherche web ne renvoie rien.
Voir la section dédiée plus bas : testez SearXNG seul avant d'accuser Open-WebUI.
Dépannage : la recherche web ne renvoie rien
Symptôme. La recherche web est activée, mais la conversation affiche No results found from web search (une erreur 404 dans le journal d'Open-WebUI), ou le modèle répond sans avoir cherché.
Ce que dit ce message. Open-WebUI a bien joint SearXNG, lui a envoyé la requête et a reçu une liste vide. Un cas public l'illustre (issue open-webui #32401, ouverte le 14 octobre 2026 après un passage en 0.12.0) : l'auteur soupçonnait la nouvelle version, la maintenance a d'abord incriminé le modèle, puis, le journal de SearXNG en main, a constaté que DuckDuckGo répondait par un CAPTCHA, Brave par « Too many requests » (moteur suspendu 3 minutes à chaque fois) et Startpage par une redirection vers son CAPTCHA. Tous les moteurs bloqués, donc zéro résultat. Selon la maintenance, ces sites bloquaient l'adresse IP indépendamment de la mise à jour. L'issue a été fermée le jour même sans correctif côté Open-WebUI, et l'auteur a fini par choisir le fournisseur DDGS.
La méthode à retenir : avant d'accuser la version ou le modèle, interrogez SearXNG seul.
Diagnostiquer une recherche web vide
Interroger SearXNG sans Open-WebUI
Depuis le VPS, lancez
curl -s 'http://127.0.0.1:8080/search?q=test&format=json'en adaptant l'hôte et le port à votre installation (si SearXNG n'est joignable que par le réseau Docker, lancez la commande depuis un conteneur de ce réseau). Trois issues : une erreur 403 signifie quejsonmanque dansformats; une listeresultsvide signifie que les moteurs échouent ; une liste remplie signifie que SearXNG fonctionne et que le problème se trouve côté Open-WebUI ou du modèle (voir l'encadré plus bas).Lire le journal de SearXNG
docker compose logs --tail 200 searxngmontre ce que chaque moteur a répondu. Cherchez les lignes qui nomment un moteur (duckduckgo, brave, startpage…) avec un CAPTCHA, un refus pour trop de requêtes ou un délai dépassé. Un moteur qui revient à chaque recherche avec la même erreur est bloqué pour l'adresse IP de votre VPS, ce qui arrive plus volontiers à une adresse de centre de données.Activer ou remplacer des moteurs
Dans
settings.yml, sectionengines, activez des moteurs généralistes qui ne sont pas bloqués : la maintenance d'Open-WebUI cite Google, Bing, Mojeek et Qwant. Une entréename: mojeekavecdisabled: falseactive un moteur présent dans les réglages par défaut ; avecuse_default_settings: trueen tête de fichier, vous ne listez que vos écarts. Redémarrez avecdocker compose restart searxng, puis rejouez l'étape 1 jusqu'à obtenir des résultats. Multipliez les moteurs : un seul moteur actif retombe vite dans le blocage.Passer par un fournisseur à clé si l'IP reste bloquée
Si tous les moteurs échouent, un fournisseur par API contourne le problème : Brave Search API, Tavily ou Serper se choisissent dans le même écran d'administration. Pour l'offre gratuite de Brave, réglez
WEB_SEARCH_CONCURRENT_REQUESTS=1. Le fournisseur DDGS, retenu par l'auteur de l'issue, ne demande pas de clé.
SearXNG renvoie des résultats, mais l'assistant ne cherche jamais ? Depuis la version 0.10.0 (fin juin 2026), l'appel d'outils natif est le mode par défaut : la recherche web devient un outil que le modèle doit appeler lui-même, et un modèle ancien ou petit le saute ou écrit un appel malformé. Choisissez un modèle récent qui gère les outils et vérifiez que Function Calling est sur Native dans les paramètres avancés du modèle ; la maintenance décrit le mode Legacy comme non pris en charge. Si la recherche réussit mais que les pages ne se chargent pas, regardez WEB_SEARCH_TRUST_ENV derrière un proxy HTTP, puis USER_AGENT.
Suivre l'usage d'une instance d'équipe
Savoir qui consomme quoi devient vite une question de budget dès que des développeurs appellent l'instance par l'API. Aujourd'hui, quatre sources se complètent, chacune avec un angle mort :
Les quatre sources de mesure
- Le tableau de bord Analytics (réglages d'administration, rubrique Analytics) : messages, tokens en entrée et en sortie, par modèle et par utilisateur, avec filtre par groupe et par période ; depuis la 0.12.4, le classement se fait par tokens. Il se calcule à partir de l'historique de messages enregistré dans la base : ce qui n'y est pas enregistré n'y figure pas.
ENABLE_ADMIN_ANALYTICS=Falsele masque. - La vue personnelle (réglages, onglet Usage, depuis la 0.11.0 de juillet 2026) : chaque utilisateur voit sa propre activité, et rien de celle des autres.
- Le journal d'audit : désactivé par défaut (
AUDIT_LOG_LEVEL=NONE). AvecAUDIT_LOG_LEVEL=METADATA, Open-WebUI écritaudit.logdans son répertoire de données (rotation à 10 Mo) pour les requêtes authentifiées par en-têteAuthorizationou par cookie : les appels d'API y figurent donc, avec le modèle demandé. Pour obtenir aussi les tokens de chaque réponse (depuis la 0.12.4), retirez/chatdeAUDIT_EXCLUDED_PATHS, qui vaut/chats,/chat,/folderspar défaut. Évitez les niveauxREQUESTetREQUEST_RESPONSE, qui enregistrent le contenu des conversations, et rejouez un appel de test pour lire l'entrée produite avant de bâtir un décompte dessus. - Les journaux du reverse proxy : l'angle le plus simple pour la volumétrie. Avec le format combined de Nginx,
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | headclasse les chemins les plus appelés ; ajoutez$request_timeà votrelog_formatpour repérer les requêtes lentes. Ce journal ne voit ni l'utilisateur ni les tokens, et l'en-têteAuthorizationne doit jamais y être consigné.
Ce que le suivi d'usage ne fait pas encore
La demande d'un suivi qui sépare l'interface de l'API et attribue les appels à chaque clé est ouverte sur le dépôt du projet : issue open-webui #21675, « enh: analytics », créée le 20 février 2026 et toujours ouverte au 7 novembre 2026, avec une centaine de commentaires. Le fil rapporte qu'un utilisateur d'API placé dans un groupe n'apparaît pas dans Analytics, et le 14 octobre une équipe dont les développeurs passent surtout par l'API réclamait encore cette visibilité. Aucune date n'y est annoncée : ne planifiez rien sur cette fonction.
La maintenance répond qu'un filtre, c'est-à-dire une fonction Python installée dans l'interface, peut compter les requêtes, y compris celles de l'API ; un contributeur précise que les routes en passthrough y échappent. Elle range les plafonds par utilisateur ou par groupe dans le limitage de débit, hors du sujet Analytics. Lire directement la base SQLite webui.db reste possible sur une copie, mais son schéma n'est pas un contrat et change d'une version à l'autre. Un contributeur a aussi publié un plugin tiers de quotas : une fonction s'exécute avec les droits du serveur, donc relisez son code avant de l'activer.
Donnez à chaque développeur son compte et sa propre clé d'API plutôt qu'une clé partagée : sans identité distincte, aucune des quatre sources ne peut attribuer l'usage. Si l'API devient le canal principal, une passerelle devant Ollama qui compte les appels à la source (LiteLLM, déjà au catalogue ServOrbit, propose des clés virtuelles et un suivi de dépense) est une piste à tester avant de l'adopter.
Sécuriser l'accès à l'API Ollama
Par défaut, Ollama écoute sur 0.0.0.0:11434 dans son conteneur. La configuration compose.yml proposée ci-dessus ne publie pas ce port sur l'hôte — seul Open-WebUI y accède via le réseau Docker interne. C'est la posture correcte.
Si vous avez besoin d'accéder à l'API Ollama directement (depuis un IDE, un notebook Jupyter ou une application externe), deux options :
1. Tunnel SSH : ssh -L 11434:localhost:11434 user@votre-vps — l'API est accessible localement sans exposition publique.
2. Reverse proxy avec authentification : exposez Ollama derrière Nginx avec un auth_basic ou un token Bearer, si vous avez des clients qui ne supportent pas le tunnel SSH.
Ne publiez jamais le port 11434 directement sur l'interface publique sans authentification : l'API Ollama n'a aucune protection native contre les accès non autorisés.
Pour maintenir Open-WebUI à jour, modifiez l'image de ghcr.io/open-webui/open-webui:main en ghcr.io/open-webui/open-webui:v0.13.0 (ou le dernier tag stable) dans votre compose.yml. Le tag :main suit le développement en continu — pratique pour tester les nouvelles fonctions, moins prévisible en production. Consultez les notes de version sur GitHub avant chaque mise à jour : certaines versions ont introduit des migrations de base de données, d'autres changent des comportements par défaut (l'appel d'outils natif en 0.10.0), et les notes de la 0.12.0 recommandent une mise à jour rapide des déploiements de production pour ses correctifs de sécurité.
Fonctions avancées à explorer après le déploiement
- Pipelines et fonctions : Open-WebUI permet d'écrire des fonctions Python qui s'intercalent dans le flux de conversation — filtres, enrichisseurs de contexte, connecteurs vers des APIs externes.
- Modèles personnalisés : créez des « modèles » pré-configurés (instructions système, température, contexte) et partagez-les avec des groupes d'utilisateurs spécifiques.
- Image generation : connectez Open-WebUI à une instance Stable Diffusion ou ComfyUI locale pour générer des images directement dans le chat.
- Intégration avec des outils externes : via le protocole MCP (Model Context Protocol), Open-WebUI peut appeler des outils externes — bases de données, APIs REST, recherche web.
La documentation officielle
Pour la configuration avancée et les options propres à l'outil, référez-vous à la documentation officielle d'Open-WebUI. Ce guide couvre le déploiement de base et les configurations les plus courantes — les paramètres spécifiques à votre environnement (intégration LDAP, configuration de pipelines, tuning des embeddings) se trouvent dans la documentation du projet.
