Quelle alternative à Open WebUI 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’est accessible sur une adresse publique. Un VPS change ces deux conditions, 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 avantageux lorsque l’interface se partage avec le modèle le dernier gigaoctet de RAM disponible. 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 comptent uniquement avec une IP publique

• Mémoire utilisée à côté du modèle. Le serveur de modèle est le processus le plus coûteux de la machine. Chaque mégaoctet consommé par l’interface est un mégaoctet dont le modèle ne peut pas disposer.
• Authentification. Certains de ces projets prennent en charge des comptes et des rôles utilisateur. D’autres partent du principe qu’ils sont les seuls à fonctionner sur votre ordinateur portable et ne proposent aucune connexion.
• Inférence distante. Une interface qui ne peut accéder qu’à 127.0.0.1:11434 impose d’exécuter le modèle sur la même machine que l’interface.
• Maintenance. Un conteneur avec un fichier SQLite ne demande pas le même travail que six conteneurs s’appuyant sur MongoDB et une base de données vectorielle.

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

L’interface n’est pas l’élément le plus volumineux du serveur. Le modèle l’est. Les tailles de téléchargement publiées donnent un minimum, car les poids doivent rester en mémoire pendant que le modèle répond. La consommation réelle 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"
  }
]

Ce sont 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 une contrainte que les comparatifs d’ordinateurs portables ne couvrent jamais. C’est aussi dans ce contexte qu’une interface de chat occupant quelques centaines de megabytes peut déterminer si le modèle s’exécute. Si vous dimensionnez un serveur pour un modèle dépassant largement ces tags, le calcul pour un modèle 27B sur un VPS utilisant uniquement le CPU montre à quelle vitesse l’interface cesse d’être le facteur déterminant.

Mesurez la consommation au lieu de faire confiance aux chiffres d’un comparatif, y compris à celui-ci. Exécutez docker stats --no-stream après une heure d’utilisation réelle, et non une minute après le démarrage du conteneur, car 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 s’exécute depuis 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, tous deux décrits ci-dessous, puis créez le premier compte. Ce compte devient l’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 inconnu 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 ci-dessous, 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 revient à une taille interne élevée. Chaque connexion crée alors son propre cache de pages 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 derrière

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 choix à retenir 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 il 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 n’est le modèle. MongoDB et pgvector ont chacun besoin de mémoire, et sur une machine dotée de 4 GB, cette mémoire manque au modèle.

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, que le projet fournit à cette fin, et conservez les secrets dans .env. Ces deux fichiers ne sont pas suivis par git, donc git pull les laisse intacts.

Pointez LibreChat vers votre propre model server avec un custom endpoint 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 depuis le conteneur. Utilisez donc host.docker.internal à la place.

Hollama et OrionChat : le navigateur effectue 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. Cette option supprime le conteneur lorsqu’il s’arrête. 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 charger l’application.

OrionChat va plus loin et ne comporte 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. L’application supprime les conversations les plus anciennes lorsque leur nombre dépasse 512.

Aucun des deux projets ne possède de login, car aucun ne dispose d’un serveur capable de le vérifier. Sur un laptop, ce fonctionnement convient. 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 environnements dans lesquels ces deux applications sont utilisables. Votre navigateur doit pouvoir joindre Ollama directement. Ollama doit donc écouter sur une adresse autre que loopback, et il ne possède aucun mécanisme d’authentification. Deux règles du navigateur en découlent. Une page servie en HTTPS ne peut pas appeler un endpoint HTTP simple. 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’avez pas autorisé cette origine.

La méthode documentée par Ollama pour modifier ces deux 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 auparavant 127.0.0.1:11434. N’effectuez cette modification que si un firewall ou un proxy avec authentification contrôle déjà l’accès au port. Un port 11434 ouvert expose un model server accessible. 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 le 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, donc aucune règle du navigateur ne s’applique. La même URL de base et la même clé factice fonctionnent aussi en dehors d’une fenêtre de chat. Il suffit alors de configurer un agent de programmation pour utiliser le modèle que vous hébergez déjà.

Hollama et OrionChat peuvent utiliser n’importe quel endpoint que vous saisissez 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 outils, et à aucun autre dans cette section.

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 le moment de décider si Ollama ou vLLM doit traiter les requêtes, car leur comportement diffère fortement lorsque plusieurs personnes utilisent le modèle en même temps. Si le serveur de modèles n’existe pas encore, commencez par exécuter Ollama sur un VPS et, sur une machine limitée au 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 renforcement de la sécurité 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 totalement dépourvu d’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, une réponse curl -sI http://YOUR.VPS.IP:3000 à HTTP/1.1 200 OK indique la même chose plus directement.

Désactiver la connexion d’Open WebUI avec WEBUI_AUTH=False est un réglage mono-utilisateur destiné à une machine inaccessible aux autres utilisateurs. 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 : effectuer la liaison sur loopback et y accéder avec SSH. Publiez chaque port sur 127.0.0.1, puis transférez celui 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. Aucun port n’est publié, donc aucun 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 sur loopback. La sécurité de cette méthode dépend entièrement de votre configuration SSH. Associez-la donc à un accès SSH par clé uniquement et à un sshd renforcé.

Méthode 2 : utiliser un reverse proxy qui authentifie la requête avant que l’application ne la reçoive. Laissez l’application sur loopback, confiez le port 443 au proxy et placez un système de single sign-on devant l’application. Traefik configuré avec des labels Docker Compose et Authentik comme fournisseur d’identité fournissent à chaque application de la machine une authentification et un certificat communs. 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 la documentation d’Open WebUI précise 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 accessibles uniquement depuis le navigateur. Un proxy placé devant la page ne protège pas l’endpoint du modèle. De plus, une requête fetch envoyée depuis 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. Acheminez l’endpoint du modèle sous le même hostname que la page, ou utilisez la méthode 1.

Quel outil choisir

Si d’autres personnes que vous vont l’utiliser, choisissez Open WebUI. Il gère de vrais comptes, place les nouveaux utilisateurs dans une file d’attente de validation et ses mainteneurs publient des recommandations de durcissement que vous pouvez appliquer. Si vous avez besoin de LDAP ou d’un panneau d’administration, choisissez LibreChat et vérifiez avec docker stats que ses six services, ainsi que votre modèle, tiennent réellement sur la machine avant de vous en remettre à cette solution. S’il s’agit d’une seule personne sur une petite machine où le modèle utilise déjà la plus grande 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 outils sur 0.0.0.0 sans authentification en amont.

FAQ

Open WebUI peut-il être exposé directement sur une IP publique sans risque ?

Sa page de durcissement le décrit comme un logiciel destiné aux réseaux privés et de confiance, au même titre qu’une base de données ou qu’un serveur CI. Il gère bien de véritables 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, si possible, avec un système de single sign-on. Publiez le port du conteneur en 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 applications accessibles depuis un navigateur, Hollama et OrionChat, car l’application s’exécute sur le client. Le serveur envoie uniquement des fichiers statiques, et OrionChat n’a besoin d’aucun 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 seul modèle d’embeddings. 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. La connexion est établie par leur serveur, donc les règles du navigateur ne s’appliquent pas. Définissez OLLAMA_BASE_URL pour Open WebUI, ou baseURL dans un endpoint personnalisé pour LibreChat. Pour vLLM ou un autre serveur compatible 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 vient de votre navigateur. L’endpoint doit donc être accessible depuis votre navigateur.

Pourquoi mon interface de chat dans le navigateur ne peut-elle pas joindre Ollama ?

Deux causes couvrent presque tous les cas. Ollama écoute sur 127.0.0.1:11434 par défaut. Un navigateur situé sur une autre machine ne peut donc pas le joindre tant que OLLAMA_HOST n’est pas modifiée. Ollama n’accepte également que les requêtes cross-origin provenant 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 utilise HTTPS et l’endpoint HTTP, le navigateur bloque la requête en raison d’un mixed content avant même 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.