Open-WebUI + Ollama sur VPS : interface multi-utilisateurs LLM

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.

Avec plus de 150 000 étoiles sur GitHub (licence MIT), Open-WebUI est devenu le frontend de référence pour Ollama. Sa croissance a été amplifiée par la Series B d'Ollama — 65 millions de dollars levés en juillet 2026 — qui a accéléré l'adoption du moteur d'inférence dans les équipes de développement.

Le projet est actif, maintenu de façon continue, et publie des tags stables (v0.6.x au moment de cet article). Sa maturité lui permet de couvrir des besoins qui vont bien au-delà du chat : RAG sur des fichiers locaux, gestion de plusieurs modèles, groupes d'utilisateurs 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 (Open-WebUI requiert HTTPS pour les cookies de session sécurisés)

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/openwebui

Contenu 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=changez-cette-valeur-par-une-chaine-aleatoire
    volumes:
      - open_webui_data:/app/backend/data
    restart: unless-stopped

volumes:
  ollama_data:
  open_webui_data:

La clé WEBUI_SECRET_KEY doit être une chaîne aléatoire longue : générez-la avec openssl rand -hex 32.

Démarrer la stack

Lancez les deux services :

docker compose up -d

Vérifiez que les deux conteneurs sont actifs :

docker compose ps

Ollama 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:8b

Vous 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.com

L'entête Connection: upgrade et le proxy_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.com dans votre navigateur. Le premier compte créé devient automatiquement administrateur. 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=votre-client-secret
  - OPENID_PROVIDER_URL=https://votre-idp.example.com/.well-known/openid-configuration
  - OAUTH_PROVIDER_NAME=Mon SSO
  - ENABLE_OAUTH_SIGNUP=true

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 -d

Pour 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.

Open-WebUI, AnythingLLM, LibreChat : quelle interface choisir

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	150 000+ (MIT)	40 000+ (MIT) / 20 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.
Les nouveaux comptes créés via SSO sont placés par défaut dans le rôle pending si ENABLE_OAUTH_SIGNUP n'est pas configuré. Passez leur rôle à user dans Panneau d'administration → Utilisateurs, ou configurez DEFAULT_USER_ROLE=user dans les variables d'environnement.

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.6.x (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.

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.