Quelle alternative à Open WebUI choisir sur un VPS ?

Quelle alternative à Open WebUI choisir sur un VPS

Les alternatives à Open WebUI sont presque toujours comparées sur un ordinateur portable, où la RAM coûte peu 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 à côté 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 gèrent des comptes utilisateur et des rôles. D’autres partent du principe qu’ils sont les seuls à fonctionner sur votre ordinateur et ne proposent aucune connexion.
• Inférence distante. Une interface qui ne peut communiquer qu’avec 127.0.0.1:11434 oblige à 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 utilisant 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 lourd du serveur. C’est le modèle. 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"
  }
]

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 au reste. Le cache de contexte réduit encore cette marge à mesure que la conversation s’allonge. C’est pourquoi la valeur de num_ctx que vous définissez est autant une décision de mémoire que de qualité. 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. Une interface de chat qui consomme quelques centaines de mégaoctets peut déterminer si le modèle fonctionne. Si vous dimensionnez un serveur pour un modèle nettement supérieur à ces valeurs, le calcul pour un modèle 27B sur un VPS avec CPU uniquement 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 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. Ollama libère également les poids après cinq minutes d’inactivité. Une mesure effectuée entre deux conversations sous-estime donc le pic. Le message suivant doit alors recharger l’ensemble du modèle, sauf si vous gardez le modèle en mémoire avec keep_alive.

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 est plus important 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 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, une personne étrangère qui accède à la page ne peut pas utiliser votre modèle tant qu’un administrateur ne l’a pas approuvée.

Open WebUI consomme plus de mémoire que les projets ci-dessous, car il fournit davantage de fonctionnalités. Sa page consacrée aux performances indique quels composants en sont responsables. 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 model server 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 grande taille interne par défaut, et chaque connexion crée son propre cache de pages et son 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 en arrière-plan

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 à privilégier lorsque vous avez besoin d’un système d’identités plutôt que d’une simple boîte de connexion : sa documentation couvre les connexions LDAP et OAuth2, et il intègre 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 ne correspond au 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 surviennent souvent.

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. La mise à niveau reste alors appliquée à moitié. 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 n’y touche 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 à l’intérieur du conteneur. Utilisez donc host.docker.internal à cet endroit.

Hollama et OrionChat : le navigateur fait le travail

Hollama sert 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 lorsqu’il s’arrête. L’interface ne revient donc jamais 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. Elle répond à toute requête utilisant un autre nom d’hôte par une erreur d’hôte bloqué au lieu d’afficher l’application.

OrionChat va plus loin et ne possède aucun composant serveur. Clonez le dépôt et servez le répertoire 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 possède de mécanisme de connexion, car aucun ne dispose d’un serveur capable de le vérifier. Sur un ordinateur portable, ce n’est pas un problème. Sur un VPS, cela signifie que la page ne doit jamais être publiée sur 0.0.0.0. Cela implique aussi un point 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 projets sont utilisables. Votre navigateur doit pouvoir joindre Ollama directement. Ollama doit donc écouter sur une adresse autre que loopback, et il ne fournit aucune authentification. Deux règles du navigateur en découlent. 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 à créer une surcharge 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 pare-feu ou un proxy avec authentification contrôle déjà les 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 le configure pour utiliser 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. 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 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 interfaces, 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. C’est également le moment de 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 en même temps. Si le serveur de modèles n’existe pas encore, commencez par exécuter Ollama sur un VPS. Sur une machine uniquement équipée d’un CPU, lisez comment Ollama se compare à 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 un reverse proxy avec authentification. Un projet sans authentification mérite au minimum 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, si curl -sI http://YOUR.VPS.IP:3000 répond à HTTP/1.1 200 OK, cela confirme la même chose de manière plus explicite.

Désactiver l’authentification d’Open WebUI avec WEBUI_AUTH=False est un réglage mono-utilisateur destiné à une machine inaccessible aux autres utilisateurs. Ce réglage ne s’applique pas non plus à une installation qui possède déjà des comptes. Open WebUI affiche alors le message You can't turn off authentication because there are existing users.

Modèle 1 : lier le service à loopback et y accéder avec SSH. Publiez chaque port sur 127.0.0.1, puis transférez uniquement 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 détecté par un scan. 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 ce modèle dépend entièrement de votre configuration SSH. Associez-le donc à un accès SSH par clé uniquement et à un sshd renforcé.

Modèle 2 : 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 l’authentification unique devant l’application. Traefik configuré avec les labels Docker Compose et Authentik comme fournisseur d’identité donnent à chaque application de la machine 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 par rapport à sa valeur par défaut 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.

Le modèle 2 ne protège pas les projets qui fonctionnent uniquement dans le navigateur. Un proxy placé devant la page ne protège pas le endpoint du modèle. De plus, une requête fetch envoyée depuis cette page vers un autre hostname ne transmet pas le 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 le modèle 1.

Choisir la bonne solution

Si d’autres personnes que vous doivent 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 sécurisation 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 dans les ressources disponibles avant d’en dépendre. Si une seule personne l’utilise sur une petite machine où le modèle consomme 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 solution consiste à publier l’un de ces services sur 0.0.0.0 sans authentification en amont.

FAQ

L’interface Open WebUI peut-elle être exposée directement sur une IP publique en toute sécurité ?

Sa page consacrée au durcissement la décrit 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. Open WebUI gère bien de vrais comptes : le premier compte devient administrateur, tandis que les suivants restent pending jusqu’à leur approbation. L’outil 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, un système de single sign-on. Publiez le port du conteneur sous la forme 127.0.0.1:3000:8080 afin que les règles iptables de Docker ne l’exposent pas à Internet à votre insu.

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

Les applications accessibles depuis le 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 hébergé sur une autre machine ?

Open WebUI et LibreChat le permettent, car la connexion est établie par leur serveur. Les restrictions du navigateur ne s’appliquent donc pas. Définissez OLLAMA_BASE_URL pour Open WebUI, ou baseURL dans un endpoint personnalisé 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 provient alors de votre navigateur. L’endpoint doit donc être accessible depuis celui-ci.

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 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 n’est pas ajoutée à OLLAMA_ORIGINS. Si la page est en HTTPS et l’endpoint en HTTP, le navigateur bloque la requête comme contenu mixte 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.