Open WebUI en Docker
et Docker Compose : guide complet 2026

L’image :main est la recommandation pour 90% des déploiements. C’est Open WebUI seul, sans Ollama inclus. Vous déployez Ollama séparément (comme dans le docker-compose.yml ci-dessus). Cette séparation permet de mettre à jour les deux indépendamment et de mieux contrôler les ressources.

L’image :ollama bundle les deux (Ollama + Open WebUI) dans un seul conteneur. Pratique pour un démarrage rapide ou un déploiement minimaliste. L’inconvénient : vous ne pouvez pas mettre à jour Ollama indépendamment d’Open WebUI — les deux évoluent ensemble à chaque rebuild.

L’image :cuda est l’image :main avec les drivers CUDA préinstallés pour les GPU NVIDIA. Si vous avez un GPU NVIDIA et que vous voulez que les modèles Ollama l’utilisent, c’est cette image qu’il vous faut. Ajoutez –gpus all à la commande docker run pour que le conteneur accède au GPU.

Via le flag -e dans la commande docker run, ou via la section environment dans docker-compose.yml. Les variables les plus utilisées : OLLAMA_BASE_URL (URL de votre serveur Ollama), WEBUI_SECRET_KEY (clé secrète pour la sécurité des sessions), OPENAI_API_KEY (si vous connectez OpenAI), DEFAULT_MODELS (modèle sélectionné par défaut).

Pour les secrets (clés API, mots de passe), ne les mettez jamais en clair dans votre docker-compose.yml si celui-ci est versionné dans Git. Utilisez un fichier .env dans le même dossier que votre docker-compose.yml — Docker Compose le lit automatiquement. Ajoutez .env à votre .gitignore pour ne pas le committer.

La liste complète des variables d’environnement disponibles est documentée dans le README officiel d’Open WebUI sur GitHub. Les variables importantes pour la production : WEBUI_SECRET_KEY (obligatoire en prod, générez une clé aléatoire de 32 caractères), WEBUI_URL (URL publique de votre instance pour les liens dans les emails).

Open WebUI utilise un volume nommé (open-webui par défaut) qui stocke : la base de données SQLite avec vos conversations et utilisateurs, vos collections RAG (vecteurs ChromaDB), les fichiers uploadés, et toute la configuration de l’application.

Pour voir où sont stockés les volumes sur votre système : docker volume inspect open-webui affiche le chemin physique. Sur Mac/Windows avec Docker Desktop, les volumes sont dans une VM Linux — vous ne pouvez pas y accéder directement depuis Finder ou Explorer.

Bonne pratique : nommez toujours votre volume explicitement (–name open-webui dans la commande run, ou dans le docker-compose.yml). Un volume nommé est plus facile à identifier, sauvegarder et restaurer qu’un volume anonyme généré automatiquement. Ne supprimez jamais un volume sans sauvegarde préalable — c’est là que vivent toutes vos données.

Pour la majorité des TPE et PME, Docker Compose suffit largement. Il gère parfaitement une stack Ollama + Open WebUI sur un seul serveur avec restart automatique, logs centralisés et mises à jour simples. La complexité de maintenance est minimale et la courbe d’apprentissage raisonnable.

Docker Swarm ou Kubernetes ne deviennent pertinents qu’à partir de plusieurs dizaines d’utilisateurs simultanés ou d’un besoin de haute disponibilité multi-serveurs. Ces outils ajoutent une complexité opérationnelle significative qui se justifie pour des déploiements critiques (hospitals, grandes entreprises) mais pas pour une PME.

Si vous débutez, ne vous embêtez pas avec Swarm ou K8s. Docker Compose sur un bon VPS (Hetzner, OVH, Scaleway) avec 4 vCPU et 8 GB de RAM couvre 95% des besoins réels pour des équipes jusqu’à 50 utilisateurs, avec une complexité de maintenance radicalement plus faible.

Pour un déploiement basique, docker logs -f open-webui suffit pour voir les erreurs en temps réel. Ajoutez –log-opt max-size=100m –log-opt max-file=3 à votre commande docker run pour limiter la taille des logs et éviter de remplir votre disque.

Pour un monitoring plus sérieux, intégrez Uptime Kuma (outil open source de monitoring) dans votre docker-compose.yml. Uptime Kuma vérifie que http://localhost:3000 répond toutes les minutes et vous alerte par email ou Telegram si l’interface devient inaccessible.

Pour des métriques de performance (CPU, RAM, requêtes par minute), Prometheus + Grafana est la stack standard. Open WebUI n’expose pas encore de métriques Prometheus nativement en 2026, mais vous pouvez monitorer les métriques Docker (CPU, RAM du conteneur) via cAdvisor, qui s’intègre facilement dans une stack Prometheus.

Oui, mais avec des limitations importantes. Open WebUI tourne sur Raspberry Pi 4 et 5 (architecture ARM64) grâce aux images Docker multi-architecture publiées par l’équipe. La commande standard fonctionne sans modification sur Pi OS 64-bit.

Les modèles LLM sur Raspberry Pi sont très lents : un Pi 4 avec 8 GB de RAM génère 1 à 3 tokens par seconde sur un modèle 3B. C’est frustrant pour un usage interactif. Le Pi 5 est environ 2× plus rapide que le Pi 4 sur ces tâches. Pour une meilleure expérience, utilisez Open WebUI sur Pi comme interface qui se connecte à un Ollama sur une machine plus puissante du réseau local.

Une configuration qui fonctionne bien : Raspberry Pi 5 (8 GB) comme serveur Open WebUI, + une machine desktop avec GPU comme serveur Ollama. Open WebUI est configuré pour pointer sur l’IP locale de votre desktop Ollama. Vous avez l’interface web sur le Pi et la puissance de calcul sur le desktop.

Oui, en changeant les ports et les noms de conteneurs/volumes pour chaque instance. Par exemple : une instance de production sur le port 3000 (volume open-webui-prod) et une instance de test sur le port 3001 (volume open-webui-test).

Avec Docker Compose, la méthode propre est d’utiliser des profils ou des fichiers compose séparés. Un fichier docker-compose.prod.yml et un docker-compose.dev.yml, chacun avec ses propres ports et volumes. Lancez avec docker compose -f docker-compose.prod.yml up -d pour l’une ou l’autre.

Limites pratiques : chaque instance Open WebUI consomme 300-500 MB de RAM. Si vous avez 3 instances + 2 modèles Ollama chargés, vous consommez 6 à 8 GB de RAM rien qu’en overhead. Sur un serveur avec 16 GB, soyez raisonnable sur le nombre d’instances simultanées.

Pour Nginx, créez un fichier de configuration dans /etc/nginx/sites-available/open-webui avec la configuration standard de reverse proxy : proxy_pass http://localhost:3000, proxy_set_header directives pour passer les bons headers, et la configuration SSL si vous avez un certificat.

La commande Let’s Encrypt pour générer le certificat : certbot –nginx -d ai.votredomaine.fr. Certbot modifie automatiquement votre configuration Nginx pour activer HTTPS et redirige HTTP vers HTTPS.

Un point spécifique pour Open WebUI derrière Nginx : activez les WebSockets (proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection ‘upgrade’;). Open WebUI utilise des WebSockets pour les réponses en streaming — sans cette configuration, le streaming de tokens ne fonctionnera pas correctement.

Pour Apple Silicon (M1, M2, M3), Docker Desktop utilise l’émulation x86 ou les images ARM64 natives. Open WebUI supporte ARM64 nativement. Ollama sur Mac Apple Silicon utilise automatiquement le GPU unifié via Metal — vous n’avez pas besoin de configuration spéciale Docker.

Pour les GPU AMD, la situation est plus complexe. L’image :cuda est spécifique aux GPU NVIDIA. Pour les GPU AMD, utilisez l’image :main standard et configurez ROCm séparément dans votre conteneur Ollama. C’est faisable mais plus technique que NVIDIA/CUDA.

Sur Apple Silicon, la commande Docker standard fonctionne directement et Ollama utilise le GPU Apple via son intégration Metal. Les performances sont excellentes — un M2 Pro 16GB génère 30-40 tokens/seconde sur un modèle 7B. C’est comparables à un GPU NVIDIA RTX 3060.

Quatre mesures essentielles. Un : HTTPS obligatoire via Caddy ou Nginx + Let’s Encrypt. Jamais d’Open WebUI en HTTP sur Internet. Deux : WEBUI_SECRET_KEY configuré avec une valeur aléatoire forte (générez avec openssl rand -hex 32).

Trois : firewall configuré pour n’exposer que les ports 80 et 443 (HTTP et HTTPS). Le port 3000 et 11434 (Ollama) ne doivent pas être accessibles depuis Internet — uniquement entre conteneurs Docker via le réseau interne Docker. Quatre : authentification forte — ne laissez pas votre instance accessible en création libre de compte (ENABLE_SIGNUP=false après avoir créé vos comptes admin).

Pour une sécurité renforcée, ajoutez une couche d’authentification en amont avec Cloudflare Access ou Authelia. Ces outils interceptent toutes les requêtes avant qu’elles n’arrivent à Open WebUI et vérifient l’identité de l’utilisateur. C’est particulièrement utile pour des instances partagées en entreprise où vous voulez contrôler précisément qui peut accéder à l’interface.