Comment auto-héberger Open WebUI en 2026 : endpoints de modèles, stockage et sécurité

Considérez Open WebUI comme un petit système, pas comme une image Docker. L’objectif côté utilisateur est clair : fournir une interface de chat pour les endpoints de modèles compatibles avec OpenAI et les modèles locaux ; le déploiement n’est acceptable que lorsque vous pouvez connecter un endpoint de modèle distant, recevoir une réponse de chat en streaming, téléverser un document, lancer une recherche et rouvrir la conversation après un redémarrage.

Cette distinction permet d’identifier le problème que les opérateurs rencontrent après les tests locaux : OLLAMA_BASE_URL pointe vers localhost à l’intérieur du conteneur WebUI. Elle rend également le plan de sauvegarde et de mise à niveau suffisamment précis pour être testé.

Choisir la topologie Open WebUI viable la plus simple

Commencez par l’espace de noms réseau d’Open WebUI : son listener web utilise le port 8080, et non un port hôte copié depuis un tutoriel pour ordinateur portable. Le contrat réseau d’Open WebUI repose sur une API compatible avec OpenAI ou sur un service Ollama accessible. Conservez les endpoints privés dans le DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à Open WebUI un identifiant de service aux permissions limitées.

Une fois le besoin satisfait, exécutez le scénario complet — connecter un endpoint de modèle distant, recevoir une réponse de chat en streaming, téléverser un document, lancer une recherche et rouvrir la conversation après un redémarrage. Enregistrez les logs et les mesures concernant la latence des modèles, les streams simultanés, les tâches d’embedding, la taille des fichiers téléversés et la croissance de l’index vectoriel. Ces éléments constituent la première architecture validée et rendent testables les déplacements ultérieurs entre le compute Dockup et un serveur associé.

TLS est simple ; les URL générées le sont moins

L’émission du certificat TLS ne représente que la moitié du routage d’Open WebUI. Rendez l’endpoint de modèle accessible depuis le réseau des conteneurs. Acheminez le trafic en interne vers 8080 et transmettez le scheme externe afin que les URL générées et les cookies sécurisés restent cohérents.

Utilisez le scénario Open WebUI complet depuis un réseau vierge, et pas seulement la page racine. Une erreur 502 ou un échec de certificat peut être isolé avec la configuration automatique du domaine et de TLS. Si le trafic atteint le processus et qu’OLLAMA_BASE_URL pointe vers localhost à l’intérieur du conteneur WebUI, diagnostiquez cette condition à l’endroit où elle se produit au lieu d’empiler les redirections.

Démarrer Open WebUI sans masquer les éléments importants

Gardez l’invocation initiale d’Open WebUI suffisamment reproductible pour pouvoir être relue dans une pull request.

docker run -d \
  --name open-webui \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v open-webui-data:/app/backend/data \
  -e WEBUI_SECRET_KEY=replace-with-a-long-random-value \
  ghcr.io/open-webui/open-webui:main

Ne vous fiez pas à latest dès que des données réelles existent. Consignez le digest utilisé, l’utilisateur du conteneur et les permissions du montage. Suivez le log de l’application pendant un test complet — connecter un endpoint de modèle distant, recevoir une réponse de chat en streaming, téléverser un document, lancer une recherche et rouvrir la conversation après un redémarrage — et notez les éventuelles migrations avant d’exposer la route au trafic de production.

Mettre à niveau Open WebUI sans deviner

Un health check au repos ne dit pas grand-chose sur Open WebUI. Surveillez la latence des modèles, les streams simultanés, les tâches d’embedding, la taille des fichiers téléversés et la croissance de l’index vectoriel, puis déclenchez une alerte sur le symptôme observé par les utilisateurs : l’échec de l’action « connecter un endpoint de modèle distant, recevoir une réponse de chat en streaming, téléverser un document, lancer une recherche et rouvrir la conversation après un redémarrage ». Gardez la liveness locale et peu coûteuse ; laissez la readiness signaler les migrations ou l’initialisation sans provoquer une restart storm.

La zone de mise à niveau à risque tient au fait que les migrations de base de données, les backends de recherche et les paramètres des endpoints de modèles peuvent évoluer indépendamment du frontend de chat. Lisez les release notes, créez un snapshot de l’état, déployez la version cible à partir d’une copie restaurée et répétez le test d’acceptation. Si OLLAMA_BASE_URL pointe vers localhost à l’intérieur du conteneur WebUI, corrélez la requête du client avec le premier log pertinent de l’application au lieu de supprimer aveuglément les données ou d’ajouter des redirections.

Cinq vérifications plus fiables que la santé du conteneur

Ne faites pas du trafic du premier utilisateur le test d’acceptation d’Open WebUI. Préparez un état de test sans risque et exécutez l’action complète « connecter un endpoint de modèle distant, recevoir une réponse de chat en streaming, téléverser un document, lancer une recherche et rouvrir la conversation après un redémarrage ». Notez l’URL publique exacte, le résultat, la référence de l’image et l’intervalle de logs associés à l’exécution.

Remplacez le conteneur et répétez l’opération sans reconstruire les données. Ensuite, effectuez une restauration sur un hôte vide ; la condition de restauration est que les comptes, les chats, les fichiers et les collections de recherche soient récupérés et que l’instance restaurée puisse atteindre le même endpoint de modèle. Observez la latence des modèles, les streams simultanés, les tâches d’embedding, la taille des fichiers téléversés et la croissance de l’index vectoriel à chaque passage, puis définissez une alerte autour de la dégradation de la transaction plutôt qu’autour des métriques d’un conteneur au repos.

Une dernière vérification doit échouer volontairement : interdisez temporairement à l’identité de test d’accéder à une API compatible avec OpenAI ou à un service Ollama accessible. Vérifiez que le message généré par Open WebUI identifie la frontière concernée au lieu de déclencher une suppression de données ou un redémarrage sans fin. Restaurez la condition valide et confirmez que la même transaction de test réussit. Conservez cet exercice rapide dans la checklist de release.

Identifier chaque donnée persistante dans Open WebUI

Pour Open WebUI, la sécurité lors d’un redeploy commence par les utilisateurs, les chats, les fichiers, les données vectorielles et la configuration de l’application. Montez /app/backend/data avant le bootstrap, écrivez des données de test sans risque et remplacez le conteneur pour prouver que ce chemin est réellement persistant. Testez le chemin en remplaçant le conteneur alors que les données de test sont présentes ; cela permet de repérer les montages pointant un répertoire trop haut ou trop bas dans l’arborescence.

Testez ensuite la reprise après sinistre sur un hôte vierge. Utilisez si nécessaire un export de base de données cohérent avec l’application et vérifiez que les comptes, les chats, les fichiers et les collections de recherche sont récupérés et que l’instance restaurée peut atteindre le même endpoint de modèle. Le guide des sauvegardes de base de données testées par une restauration fournit une cible plus fiable que la simple vérification de la création d’un fichier d’archive.

Ne donnez pas tous les privilèges de l’hôte à Open WebUI

Un déploiement sécurisé d’Open WebUI commence par la suppression des privilèges inutiles. Évitez de laisser les inscriptions ouvertes ou d’utiliser une WEBUI_SECRET_KEY éphémère ; désactivez plutôt les inscriptions publiques sauf si elles sont voulues, conservez un secret WebUI stable et limitez l’administration des modèles aux utilisateurs de confiance.

Traitez WEBUI_SECRET_KEY selon son rôle dans Open WebUI : gardez les valeurs sensibles hors de Git, documentez les effets d’une rotation et ne remplacez jamais un exemple public par cette valeur en production. Restreignez les routes d’administration, utilisez un DNS privé pour les dépendances et vérifiez chaque bind mount. Lorsque les logs sont envoyés vers un système centralisé, filtrez les secrets et le contenu privé avant qu’ils ne quittent le serveur.

Utiliser Dockup pour la couche plateforme

Dockup supprime le travail manuel lié au reverse proxy et au lifecycle autour d’Open WebUI. Le service reçoit une route HTTPS stable vers 8080, une configuration injectée et un stockage persistant lors des remplacements. Un serveur client associé suit le même modèle que le compute hébergé par Dockup.

Après le lancement, respectez le contrat de l’application : rendez l’endpoint de modèle accessible depuis le réseau des conteneurs, connectez et testez une API compatible avec OpenAI ou un service Ollama accessible, puis exécutez cette vérification : connecter un endpoint de modèle distant, recevoir une réponse de chat en streaming, téléverser un document, lancer une recherche et rouvrir la conversation après un redémarrage. Cela permet de conserver une expérience one-click utile sans masquer les détails qui rendent Open WebUI récupérable et sécurisé.

Foire aux questions

De quoi Open WebUI a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur Open WebUI sur le port 8080 via une seule origine HTTPS. La dépendance réseau correspond à une API compatible avec OpenAI ou à un service Ollama accessible. Ne considérez pas Open WebUI comme prêt tant que vous ne pouvez pas connecter un endpoint de modèle distant, recevoir une réponse de chat en streaming, téléverser un document, lancer une recherche et rouvrir la conversation après un redémarrage.

Quelles données d’Open WebUI doivent être incluses dans une sauvegarde ?

Rendez /app/backend/data persistant et incluez les utilisateurs, les chats, les fichiers, les données vectorielles et la configuration de l’application dans le même manifest de restauration. Une restauration propre d’Open WebUI n’est réussie que lorsque les comptes, les chats, les fichiers et les collections de recherche sont récupérés et que l’instance restaurée peut atteindre le même endpoint de modèle.

Open WebUI nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique d’Open WebUI et conservez le port 8080 sur la route interne. Appliquez correctement le paramètre Open WebUI : rendez l’endpoint de modèle accessible depuis le réseau des conteneurs. Pour Open WebUI, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et maintient un comportement cohérent du client dépendant de l’origine.

Comment tester une mise à niveau d’Open WebUI ?

Restaurez l’état actuel d’Open WebUI dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de base de données, les backends de recherche et les paramètres des endpoints de modèles peuvent évoluer indépendamment du frontend de chat. Conservez l’image Open WebUI précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.