Open WebUI ou quelle alternative sur un VPS ?

Quelle alternative à Open WebUI choisir sur un VPS

Les alternatives à Open WebUI sont presque toujours comparées sur un laptop, où la RAM est peu coûteuse et où aucun service n’écoute sur une adresse publique. Un VPS change ces deux paramètres, ce qui modifie le classement. Open WebUI reste le choix par défaut dès qu’une deuxième personne se connecte, car il fournit de vrais comptes utilisateur et un panneau d’administration. Les projets plus légers sont avantagés lorsque l’interface se dispute le dernier gigaoctet de RAM avec le modèle. Le prix à payer est l’authentification : ils n’en proposent aucune.

Tout ce qui suit provient de la documentation de chaque projet, consultée en août 2026. Les quatre critères sont ceux qui ne deviennent pertinents qu’une fois le serveur accessible depuis Internet.

Quatre axes qui ne comptent que sur une IP publique

• Mémoire en regard du modèle. Le serveur de modèles est le processus le plus coûteux de la machine. Chaque mégaoctet utilisé par l’interface est un mégaoctet dont le modèle ne peut pas disposer.
• Authentification. Certains de ces projets proposent des comptes utilisateur et des rôles. D’autres partent du principe qu’ils sont les seuls à fonctionner sur votre ordinateur portable et ne proposent aucune connexion.
• Inférence à distance. Une interface qui ne peut atteindre que 127.0.0.1:11434 oblige à faire fonctionner le modèle sur la même machine que l’interface.
• Maintenance. Un conteneur avec un fichier SQLite ne représente pas le même travail que six conteneurs avec MongoDB et une base de données vectorielle en arrière-plan.

Quelle quantité de RAM le modèle laisse-t-il à l’interface

L’interface n’est pas l’élément le plus gourmand du serveur. Le modèle l’est. Les tailles de téléchargement publiées indiquent le minimum à prévoir, car les poids doivent rester en mémoire pendant les réponses du modèle. L’utilisation réelle de la mémoire est supérieure à la taille téléchargée dès que le cache de contexte est alloué.

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Voici les chiffres affichés par les pages de la bibliothèque Ollama en août 2026. Il s’agit de tailles publiées, pas de mesures. Sur un VPS de 4 GB, qwen3:4b à 2.5 GB laisse moins de 1.5 GB au système d’exploitation et à tout le reste. Le cache de contexte réduit encore cette marge à mesure que la conversation s’allonge. qwen3:8b à 5.2 GB ne tient pas du tout sur ce serveur. C’est un point que les comparatifs d’ordinateurs portables ne prennent jamais en compte. Pourtant, c’est ce qui détermine si une interface de chat utilisant quelques centaines de megabytes laisse suffisamment de mémoire au modèle pour fonctionner.

Mesurez plutôt que de faire confiance aux chiffres d’un comparatif, y compris à ceux-ci. Exécutez docker stats --no-stream une heure après le début d’une utilisation réelle, et non une minute après le démarrage du conteneur. La mémoire importante est allouée lors de la première utilisation.

Open WebUI : toujours le choix par défaut pour plusieurs utilisateurs

Open WebUI fonctionne à partir d’une seule image et conserve ses données dans un seul volume.

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

La commande du README du projet publie -p 3000:8080, qui écoute sur toutes les interfaces. Le préfixe 127.0.0.1: le limite à loopback. Sur un VPS, ce préfixe compte plus que tout le reste de la ligne, car Docker écrit ses propres règles iptables et un port publié ignore vos règles de refus ufw.

Accédez à la page par un tunnel ou un proxy, décrits tous les deux plus bas, puis créez le premier compte. Ce compte devient administrateur. Les inscriptions suivantes sont créées avec le rôle pending, la valeur par défaut documentée de DEFAULT_USER_ROLE. Ainsi, un tiers qui atteint la page ne peut pas utiliser votre modèle tant qu’un administrateur ne l’a pas approuvé.

Open WebUI consomme plus de mémoire que les projets suivants, car il offre davantage de fonctionnalités. Sa page consacrée aux performances indique les composants responsables de cette consommation. Le moteur d’embeddings par défaut charge un modèle sentence-transformers dans le conteneur, avec une consommation documentée d’environ 500 MB par processus worker. Définir RAG_EMBEDDING_ENGINE=ollama confie cette tâche au serveur de modèles que vous exécutez déjà. AUDIO_STT_ENGINE=webapi évite de charger un modèle local de speech-to-text. Avec SQLite et DATABASE_POOL_SIZE non défini, le pool utilise une taille interne élevée par défaut, et chaque connexion crée son propre page cache et sa propre memory map. Sur une petite machine, définissez donc DATABASE_POOL_SIZE=8 et DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False empêche l’interface de demander une completion au modèle pendant qu’un utilisateur est encore en train de saisir du texte.

LibreChat : multi-utilisateur, avec une stack

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

L’interface répond sur le port 3080. LibreChat est le bon choix lorsque vous avez besoin d’un système d’identités plutôt que d’un simple formulaire de connexion : sa documentation décrit les connexions LDAP et OAuth2, et le logiciel inclut un panneau d’administration pour les utilisateurs et les rôles. Cette fonctionnalité s’accompagne d’une stack.

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

Le fichier Compose par défaut démarre 6 services : api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Aucun d’eux n’est le modèle. MongoDB et pgvector ont chacun besoin de leur propre mémoire, et sur une machine de 4 GB, cette mémoire est prise sur celle dont le modèle a besoin.

Les mises à niveau passent par une opération git, et c’est là que les erreurs sont fréquentes.

docker compose down
git pull
docker compose pull
docker compose up -d

git pull s’arrête avec un conflit si vous avez modifié le fichier suivi docker-compose.yml, puis la mise à niveau reste partiellement appliquée. Placez vos modifications dans docker-compose.override.yml, prévu à cet effet par le projet, et conservez les secrets dans .env. Ces deux fichiers ne sont pas suivis, donc git pull ne les modifie pas.

Configurez LibreChat pour utiliser votre propre serveur de modèles avec un endpoint personnalisé dans librechat.yaml.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

Remplacez model-host par l’adresse de la machine qui exécute Ollama. Le champ apiKey doit être présent même si Ollama ignore sa valeur ; un placeholder convient donc. Si LibreChat s’exécute dans Docker et Ollama sur la même machine, localhost désigne le conteneur lui-même, et non la machine hôte. Utilisez donc host.docker.internal à cet endroit.

Hollama et OrionChat : le navigateur fait le travail

Hollama fournit une application web depuis un petit conteneur. Les conversations sont stockées dans le navigateur, pas sur le serveur.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

La version de cette commande présente dans le README utilise --rm, qui supprime le conteneur à son arrêt. L’interface ne revient donc pas après un redémarrage. Derrière un reverse proxy, ajoutez -e VITE_ALLOWED_HOSTS='chat.example.com', car l’image n’autorise que l’hôte localhost. Pour tout autre nom d’hôte, elle renvoie une erreur d’hôte bloqué au lieu de servir l’application.

OrionChat va plus loin et ne possède aucun composant serveur. Clonez le dépôt et servez le dossier avec le serveur web que vous utilisez déjà, ou ouvrez index.html depuis le disque. Les clés API sont stockées dans le localStorage du navigateur, l’historique des conversations reste dans le navigateur et l’application supprime les conversations les plus anciennes lorsque leur nombre dépasse 512.

Aucun des deux projets ne propose de connexion, car aucun ne possède de serveur capable de la vérifier. Sur un ordinateur portable, ce n’est pas un problème. Sur un VPS, la page ne doit jamais être publiée sur 0.0.0.0. Un autre point est plus facile à manquer : c’est le navigateur qui appelle le modèle, pas le serveur.

Ce point détermine les cas où ces deux applications sont utilisables. Votre navigateur doit pouvoir joindre Ollama directement. Ollama doit donc écouter sur une adresse autre que loopback et ne propose aucune authentification. Cela entraîne deux règles liées au navigateur. Une page servie en HTTPS ne peut pas appeler un endpoint HTTP simple, et la console affiche Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked.. Tout appel vers une autre origine est refusé avec has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource tant que vous n’autorisez pas cette origine.

La méthode documentée par Ollama pour modifier l’un ou l’autre de ces paramètres consiste à utiliser un override systemd.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss doit maintenant afficher 0.0.0.0:11434, alors qu’il affichait 127.0.0.1:11434 auparavant. N’effectuez cette modification que si un firewall ou un proxy avec authentification contrôle déjà l’accès au port, car un port 11434 ouvert expose un serveur de modèles et les scanners automatisés atteignent rapidement un nouveau port public. Le tunnel SSH ci-dessous évite entièrement ce problème : la page s’exécute alors depuis une origine localhost, qu’Ollama autorise par défaut, et le port ne quitte jamais la machine.

Chaque interface peut-elle utiliser un endpoint Ollama ou vLLM distant

Open WebUI le permet, et la connexion est établie côté serveur. OLLAMA_BASE_URL=http://model-host:11434 pointe vers Ollama. Pour vLLM ou tout autre serveur compatible avec l’API OpenAI, définissez OPENAI_API_BASE_URL=http://model-host:8000/v1 avec un OPENAI_API_KEY non vide et conservez le suffixe /v1, qui est obligatoire. OPENAI_API_BASE_URLS accepte plusieurs backends séparés par des points-virgules.

LibreChat le permet via le baseURL de l’endpoint personnalisé présenté plus haut. Cette requête quitte également le serveur. Aucune règle du navigateur ne s’applique donc.

Hollama et OrionChat peuvent pointer vers n’importe quel endpoint saisi dans leurs paramètres, mais la requête quitte votre navigateur. Tout ce qui est indiqué dans la section précédente s’applique à ces deux applications, et à aucune autre ici.

Séparer l’interface du modèle est le principal avantage d’un endpoint distant. Placez l’interface sur une petite machine et le modèle là où se trouve la mémoire nécessaire. C’est également à ce moment qu’il faut décider si Ollama ou vLLM doit traiter les requêtes, car leur comportement devient très différent lorsque plusieurs personnes utilisent le modèle simultanément. Si le serveur de modèles n’existe pas encore, commencez par exécuter Ollama sur un VPS et, sur une machine équipée uniquement d’un CPU, consultez la comparaison entre Ollama et llama.cpp avant de choisir un runner.

Ne publiez jamais une interface de chat sans authentification sur 0.0.0.0

La page de sécurisation d’Open WebUI indique que le projet est « conçu pour des réseaux privés et de confiance, comme d’autres infrastructures auto-hébergées telles que les bases de données, les registres de conteneurs et les serveurs CI ». Elle recommande de le placer derrière un VPN ou derrière un reverse proxy avec authentification. Un projet qui ne propose aucune authentification mérite au moins les mêmes précautions.

Vérifiez ce qui est en écoute avant de faire confiance à quoi que ce soit.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

Une ligne contenant 127.0.0.1:3000 est le résultat attendu. Une ligne contenant 0.0.0.0:3000 signifie que votre interface de chat est accessible depuis Internet. Depuis votre propre machine, le fait que curl -sI http://YOUR.VPS.IP:3000 réponde à HTTP/1.1 200 OK indique la même chose, plus directement.

Désactiver l’authentification d’Open WebUI avec WEBUI_AUTH=False est un réglage prévu pour un seul utilisateur, sur une machine inaccessible aux autres. Ce réglage refuse également de s’appliquer à une installation qui possède déjà des comptes, avec le message You can't turn off authentication because there are existing users.

Méthode 1 : lier le service à loopback et y accéder avec SSH. Publiez chaque port sur 127.0.0.1, puis transférez ceux dont vous avez besoin : ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, et ouvrez http://localhost:3000 sur votre ordinateur portable. Rien n’est publié, donc rien ne peut être analysé. Pour Hollama ou OrionChat, transférez le port du modèle dans la même commande avec -L 11434:127.0.0.1:11434 et laissez Ollama lié à loopback. Cette méthode est seulement aussi sûre que votre configuration SSH. Associez-la donc à SSH avec clés uniquement et sshd renforcé.

Méthode 2 : un reverse proxy qui authentifie la requête avant que l’application ne la reçoive. Laissez l’application liée à loopback, laissez le proxy gérer le port 443 et placez un système d’authentification unique devant l’application. Traefik piloté par les labels Docker Compose avec Authentik comme fournisseur d’identité donne à chaque application du serveur une authentification et un certificat uniques. Avec Open WebUI derrière TLS (transport layer security), définissez WEBUI_SESSION_COOKIE_SECURE=true et WEBUI_SESSION_COOKIE_SAME_SITE=strict. Réduisez également JWT_EXPIRES_IN, dont la valeur par défaut est de quatre semaines, car Open WebUI indique que, sans Redis, une déconnexion n’invalide pas le token : celui-ci reste utilisable jusqu’à son expiration automatique.

La méthode 2 ne protège pas les projets utilisables uniquement depuis un navigateur. Un proxy placé devant la page ne protège pas le endpoint du modèle. De plus, une requête fetch envoyée par cette page vers un autre hostname ne transmet pas votre cookie de session. Le proxy d’authentification placé devant Ollama répond donc par une redirection vers un formulaire de connexion, et le chat échoue. Faites passer le endpoint du modèle sous le même hostname que la page ou utilisez la méthode 1.

Laquelle choisir

Si d’autres personnes que vous doivent l’utiliser, déployez Open WebUI. Il gère de vrais comptes, place les nouveaux utilisateurs dans une file d’attente d’approbation et ses mainteneurs publient des recommandations de hardening que vous pouvez appliquer. Si vous avez besoin de LDAP ou d’un panneau d’administration, déployez LibreChat et vérifiez avec docker stats que ses six services, ainsi que votre modèle, tiennent réellement avant de vous appuyer dessus. S’il s’agit d’une seule personne sur une petite machine où le modèle utilise déjà la majeure partie de la RAM, servez Hollama ou OrionChat via un tunnel SSH et laissez le navigateur conserver l’état. Sur un VPS, la mauvaise réponse consiste à publier l’un de ces services sur 0.0.0.0 sans authentification en amont.

FAQ

Open WebUI est-il sûr à exposer directement sur une IP publique ?

Sa page de hardening le présente comme un logiciel destiné aux réseaux privés de confiance, au même titre qu’une base de données ou qu’un serveur CI. Il gère bien de vrais comptes : le premier compte devient administrateur, tandis que les suivants restent pending jusqu’à leur approbation. Il est donc bien plus sûr qu’une interface sans authentification. Placez-le tout de même derrière un reverse proxy avec TLS et, lorsque c’est possible, un système de single sign-on. Publiez le port du conteneur sur 127.0.0.1:3000:8080 afin que les règles iptables de Docker ne puissent pas l’ouvrir à Internet à votre insu.

Quelle alternative à Open WebUI utilise le moins de RAM sur un VPS ?

Les interfaces accessibles depuis le navigateur, Hollama et OrionChat, car l’application s’exécute côté client. Le serveur envoie uniquement des fichiers statiques, et OrionChat n’a même pas besoin d’un conteneur applicatif. Open WebUI conserve en mémoire un processus Python, une base de données et, par défaut, un modèle local d’embeddings. Sa documentation indique environ 500 MB par worker pour le modèle d’embeddings seul. Vérifiez ces valeurs sur votre propre serveur avec docker stats --no-stream, car elles varient selon les fonctionnalités activées.

Ces interfaces de chat peuvent-elles utiliser un serveur Ollama sur un autre hôte ?

Open WebUI et LibreChat le peuvent. Leur serveur établit la connexion, donc aucune règle du navigateur ne s’applique. Définissez OLLAMA_BASE_URL pour Open WebUI, ou baseURL dans un custom endpoint pour LibreChat. Pour vLLM ou un autre serveur compatible avec l’API OpenAI, utilisez OPENAI_API_BASE_URL avec le suffixe /v1 et une clé API non vide. Hollama et OrionChat peuvent également pointer vers n’importe quelle adresse, mais la requête part de votre navigateur. L’endpoint doit donc aussi être accessible depuis votre navigateur.

Pourquoi mon interface de chat dans le navigateur n’arrive-t-elle pas à joindre Ollama ?

Deux causes couvrent presque tous les cas. Ollama écoute sur 127.0.0.1:11434 par défaut. Un navigateur installé sur une autre machine ne peut donc pas le joindre tant que OLLAMA_HOST n’est pas modifiée. Ollama accepte également les requêtes cross-origin provenant uniquement de localhost. Une page servie depuis votre propre domaine est donc refusée avec No 'Access-Control-Allow-Origin' header is present on the requested resource tant que cette origine ne figure pas dans OLLAMA_ORIGINS. Si la page est en HTTPS et l’endpoint en HTTP, le navigateur bloque la requête comme contenu mixte avant qu’Ollama ne la reçoive. Définissez les deux variables dans une surcharge systemctl edit ollama.service, ou transférez le port avec SSH : le problème disparaîtra.