Open WebUI alternatieven voor een VPS vergelijken

Welk Open WebUI-alternatief hoort op een VPS

Alternatieven voor Open WebUI worden bijna altijd vergeleken op een laptop, waar RAM goedkoop is en niets luistert op een publiek adres. Een VPS verandert beide feiten, en dat verandert de rangschikking. Open WebUI blijft de juiste standaard zodra een tweede persoon inlogt, omdat het echte gebruikersaccounts en een beheerpaneel bevat. De lichtere projecten winnen wanneer de interface moet concurreren met het model om de laatste gigabyte aan RAM. De prijs van die winst is authenticatie: die ontbreekt bij hen volledig.

Alles hieronder is afkomstig uit de eigen documentatie van elk project, gelezen in augustus 2026. De vier assen zijn de assen die pas verschijnen zodra de server bereikbaar is vanaf het internet.

Vier assen die alleen relevant zijn bij een publiek IP-adres

• Geheugen naast het model. De modelserver is het kostbare proces op de machine. Elke megabyte die de interface in beslag neemt, is een megabyte die niet beschikbaar is voor het model.
• Authenticatie. Sommige van deze projecten bevatten gebruikersaccounts en rollen. Andere gaan ervan uit dat zij de enige applicatie op uw laptop zijn en beschikken helemaal niet over een inlogprocedure.
• Remote inference. Een UI die alleen 127.0.0.1:11434 kan bereiken, dwingt het model om op dezelfde machine te draaien als de interface.
• Onderhoud. Eén container met een SQLite-bestand is een andere taak dan zes containers met MongoDB en een vector-database erachter.

Hoeveel RAM laat het model over voor de interface

De interface is niet het grootste onderdeel op de server. Dat is het model. De gepubliceerde downloadgroottes geven u de ondergrens, omdat de gewichten in het geheugen geladen moeten zijn terwijl het model antwoordt. Het werkelijke geheugengebruik ligt hoger dan de downloadgrootte zodra de context-cache is toegewezen.

[
  {
    "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"
  }
]

Dit zijn de cijfers die in augustus 2026 op de bibliotheekpagina's van Ollama stonden. Het zijn gepubliceerde groottes, geen metingen. Op een VPS met 4 GB laat qwen3:4b met 2.5 GB minder dan 1,5 GB over voor het besturingssysteem en alle overige processen, en de context-cache snoept hiervan af naarmate een gesprek vordert. qwen3:8b met 5.2 GB past helemaal niet op die server. Dit is de situatie die in laptop-vergelijkingen nooit wordt behandeld, en het is het punt waarop een chat-interface die enkele honderden megabytes verbruikt, bepaalt of het model draait. Als u een server dimensioneert voor iets dat ruim boven deze labels ligt, laat de berekening voor een 27B-model op een VPS zonder GPU zien hoe snel de interface ophoudt de doorslaggevende factor te zijn.

Meet zelf in plaats van te vertrouwen op welk getal dan ook in een vergelijking, inclusief deze. Voer docker stats --no-stream uit na een uur werkelijk gebruik, niet één minuut nadat de container is gestart, omdat het geheugen dat ertoe doet wordt toegewezen bij het eerste gebruik.

Open WebUI: nog steeds de standaard voor meer dan één gebruiker

Open WebUI draait vanuit één image en slaat de data op in één 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

Het commando in de README van het project publiceert -p 3000:8080, dat op elke interface luistert. Het 127.0.0.1:-voorvoegsel houdt dit op loopback. Op een VPS is dat voorvoegsel belangrijker dan al het andere op de regel, omdat Docker zijn eigen iptables-regels schrijft en een gepubliceerde poort uw ufw deny-regels negeert.

Bereik de pagina via een tunnel of een proxy, beide hieronder beschreven, en maak vervolgens het eerste account aan. Dat account wordt de beheerder. Latere aanmeldingen worden aangemaakt met de rol pending, de gedocumenteerde standaard van DEFAULT_USER_ROLE, zodat een vreemde die de pagina bereikt uw model nog steeds niet kan gebruiken totdat een beheerder deze goedkeurt.

Open WebUI verbruikt meer geheugen dan de onderstaande projecten omdat het meer functionaliteit biedt, en de eigen prestatiepagina benoemt de onderdelen die dit veroorzaken. De standaard embedding-engine laadt een sentence-transformers model in de container, gedocumenteerd op ongeveer 500 MB per worker-proces. Het instellen van RAG_EMBEDDING_ENGINE=ollama delegeert die taak aan de modelserver die u al draait. AUDIO_STT_ENGINE=webapi voorkomt het laden van een lokaal speech-to-text model. Bij SQLite met DATABASE_POOL_SIZE uitgeschakeld, valt de pool terug op een grote interne omvang en bouwt elke verbinding een eigen page cache en geheugenmap op; stel daarom op een kleine server DATABASE_POOL_SIZE=8 en DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 in. ENABLE_AUTOCOMPLETE_GENERATION=False voorkomt dat de interface het model om een voltooiing vraagt terwijl een gebruiker nog aan het typen is.

LibreChat: multi-user, met een stack erachter

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

De interface reageert op poort 3080. LibreChat is de juiste keuze wanneer u een identiteitssysteem nodig heeft in plaats van slechts een inlogscherm: het documenteert LDAP- en OAuth2-logins en bevat een beheerderspaneel voor gebruikers en rollen. Die functionaliteit komt met een 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"
  }
]

Het standaard compose-bestand start 6 services: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Geen daarvan is het model. MongoDB en pgvector vereisen elk hun eigen geheugen, en op een server met 4 GB is dat geheugen dat het model nodig had.

Upgrades zijn een git-operatie, en dat is het onderdeel waar mensen fouten maken.

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

git pull stopt met een conflict als u het gevolgde docker-compose.yml heeft bewerkt, waardoor de upgrade slechts gedeeltelijk wordt toegepast. Plaats uw wijzigingen in docker-compose.override.yml, waarvoor het project dit bestand aanbiedt, en bewaar geheimen in .env. Beide bestanden worden niet gevolgd door git, dus git pull laat ze ongemoeid.

Wijs LibreChat naar uw eigen modelserver met een aangepast eindpunt in 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"

Vervang model-host door het adres van de server waarop Ollama draait. Het veld apiKey moet aanwezig zijn, ook al negeert Ollama de waarde ervan; een tijdelijke aanduiding volstaat dus. Als LibreChat in Docker draait en Ollama op dezelfde machine, betekent localhost binnen de container de container zelf; gebruik daar in plaats daarvan host.docker.internal.

Hollama en OrionChat: de browser doet het werk

Hollama serveert een browserapplicatie vanuit één kleine container. Chats worden opgeslagen in de opslag van uw browser, niet op de server.

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

De README-versie van dit commando gebruikt --rm, wat de container verwijdert zodra deze stopt; hierdoor is de interface na een reboot niet meer beschikbaar. Voeg achter een reverse proxy -e VITE_ALLOWED_HOSTS='chat.example.com' toe, omdat de image alleen de host localhost toestaat en bij een verzoek voor een andere hostnaam een 'blocked-host'-foutmelding geeft in plaats van de app.

OrionChat gaat verder en heeft helemaal geen servercomponent. Kloon de repository en serveer de map met de webserver die u al gebruikt, of open index.html vanaf de schijf. API-sleutels worden opgeslagen in de localStorage van de browser, de chatgeschiedenis blijft in de browser en de app verwijdert de oudste chats zodra het aantal de 512 overschrijdt.

Geen van beide projecten heeft een inlogprocedure, omdat geen van beide een server heeft die deze zou kunnen verifiëren. Op een laptop is dat geen probleem. Op een VPS betekent dit dat de pagina nooit op 0.0.0.0 gepubliceerd mag worden, en het betekent iets dat makkelijker over het hoofd wordt gezien: de browser roept het model aan, niet de server.

Dat ene feit bepaalt waar deze twee bruikbaar zijn. Uw browser moet Ollama rechtstreeks kunnen bereiken, dus Ollama moet op meer dan alleen loopback luisteren, en Ollama heeft geen enkele vorm van authenticatie. Hieruit volgen twee browserregels. Een pagina die via HTTPS wordt geserveerd, kan geen onbeveiligd HTTP-eindpunt aanroepen, en de console toont 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.. Een aanroep naar een andere origin wordt geweigerd met has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource totdat u die origin toestaat.

De gedocumenteerde manier van Ollama om beide instellingen te wijzigen is een systemd-override.

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 zou nu 0.0.0.0:11434 moeten weergeven waar het voorheen 127.0.0.1:11434 toonde. Breng deze wijziging alleen aan wanneer een firewall of een authenticerende proxy al controleert wie de poort kan bereiken, omdat een open 11434 een open modelserver is en massale scanners een nieuwe publieke poort snel vinden. De onderstaande SSH-tunnel omzeilt de hele kwestie: de pagina draait dan op een localhost origin, wat Ollama standaard toestaat, en de poort verlaat de machine nooit.

Kan elk exemplaar een extern Ollama- of vLLM-eindpunt gebruiken?

Open WebUI kan dit, waarbij de verbinding aan de serverzijde wordt gemaakt. OLLAMA_BASE_URL=http://model-host:11434 wijst naar Ollama. Voor vLLM of elke andere OpenAI-compatibele server stelt u OPENAI_API_BASE_URL=http://model-host:8000/v1 in met een niet-lege OPENAI_API_KEY, en behoudt u het /v1-achtervoegsel, wat vereist is. OPENAI_API_BASE_URLS accepteert meerdere backends gescheiden door puntkomma's.

LibreChat kan dit via de baseURL van het hierboven getoonde aangepaste eindpunt. Dat verzoek verlaat ook de server, dus er zijn geen browserregels van toepassing. Dezelfde basis-URL en dezelfde tijdelijke sleutel werken ook buiten een chatvenster; dat is alles wat nodig is om een codeer-agent te laten wijzen naar het model dat u al host.

Hollama en OrionChat kunnen wijzen naar elk eindpunt dat u in hun instellingen typt, maar het verzoek verlaat uw browser. Alles in de bovenstaande sectie is van toepassing op hen en op niets anders hier.

Het scheiden van de interface van het model is het grootste voordeel van een extern eindpunt. Plaats de interface op een kleine machine en het model daar waar het geheugen beschikbaar is. Dit is ook het moment om te beslissen of Ollama of vLLM de verzoeken moet afhandelen, omdat de twee zich heel anders gedragen zodra meerdere mensen tegelijkertijd met het model praten. Als de modelserver nog niet bestaat, begin dan met het draaien van Ollama op een VPS, en lees op een machine zonder GPU hoe Ollama zich verhoudt tot llama.cpp voordat u een runner kiest.

Publiceer nooit een chat-UI zonder login op 0.0.0.0

De hardening-pagina van Open WebUI stelt dat het project is "gebouwd voor private, vertrouwde netwerken, vergelijkbaar met andere self-hosted infrastructuur zoals databases, container registries en CI-servers". Het adviseert om de applicatie achter een VPN of een reverse proxy met authenticatie te plaatsen. Een project zonder enige vorm van login verdient op zijn minst dezelfde behandeling.

Controleer wat er luistert voordat u de configuratie vertrouwt.

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

Een regel met 127.0.0.1:3000 is wat u wilt zien. Een regel met 0.0.0.0:3000 betekent dat uw chat-interface op het publieke internet staat. Vanaf uw eigen machine zegt curl -sI http://YOUR.VPS.IP:3000 met het antwoord HTTP/1.1 200 OK hetzelfde, maar dan directer.

Het uitschakelen van de login van Open WebUI met WEBUI_AUTH=False is een instelling voor één gebruiker op een machine die voor niemand anders bereikbaar is. Deze instelling wordt bovendien geweigerd bij een installatie waar al accounts aanwezig zijn, met de melding You can't turn off authentication because there are existing users.

Patroon één: bind aan loopback en benader het via SSH. Publiceer elke poort op 127.0.0.1 en forward vervolgens wat u nodig heeft: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, en open http://localhost:3000 op uw laptop. Er wordt niets gepubliceerd, dus er kan niets worden gescand. Voor Hollama of OrionChat forwardt u de modelpoort in hetzelfde commando met -L 11434:127.0.0.1:11434 en laat u Ollama op loopback staan. Dit patroon is slechts zo sterk als uw SSH-configuratie; combineer het daarom met SSH met alleen sleutels en een beveiligde sshd.

Patroon twee: een reverse proxy die authenticeert voordat de app het verzoek ziet. Houd de app op loopback, laat de proxy poort 443 beheren en plaats single sign-on ervoor. Traefik aangestuurd door Docker Compose labels met Authentik als identity provider geeft elke app op de server één login en één certificaat. Met Open WebUI achter TLS (transport layer security), stelt u WEBUI_SESSION_COOKIE_SECURE=true en WEBUI_SESSION_COOKIE_SAME_SITE=strict in. Verkort ook JWT_EXPIRES_IN van de standaardwaarde van vier weken, omdat Open WebUI documenteert dat zonder Redis een uitlogactie het token niet ongeldig maakt: het blijft bruikbaar totdat het vanzelf verloopt.

Patroon twee biedt geen oplossing voor projecten die alleen in de browser draaien. Een proxy voor de pagina beschermt het model-eindpunt niet, en een fetch vanaf die pagina naar een andere hostnaam bevat uw sessie-cookie niet. Hierdoor reageert de authenticerende proxy voor Ollama met een redirect naar een inlogformulier en mislukt de chat. Route het model-eindpunt onder dezelfde hostnaam als de pagina, of gebruik patroon één.

Welke keuze maken

Als iemand anders dan u de applicatie gaat gebruiken, draai dan Open WebUI. Het beschikt over echte accounts, nieuwe gebruikers komen in een wachtrij voor goedkeuring terecht en de beheerders publiceren richtlijnen voor hardening die u kunt volgen. Als u LDAP of een beheerpaneel nodig heeft, draai dan LibreChat en controleer met docker stats of de zes services plus uw model daadwerkelijk in het geheugen passen voordat u hiervan afhankelijk wordt. Als het voor één persoon op een kleine server is waar het model het grootste deel van het RAM-geheugen al in beslag neemt, serveer dan Hollama of OrionChat via een SSH-tunnel en laat de browser de status bijhouden. Het verkeerde antwoord op een VPS is om een van deze applicaties te publiceren op 0.0.0.0 zonder inlogscherm ervoor.

FAQ

Is Open WebUI veilig om direct op een publiek IP-adres te publiceren?

De eigen hardening-pagina beschrijft het als software voor private, vertrouwde netwerken, in dezelfde categorie als een database of een CI-server. Het beschikt wel over echte accounts, waarbij het eerste account een beheerder wordt en latere accounts pending blijven totdat ze zijn goedgekeurd; het is dus aanzienlijk veiliger dan een interface zonder inlogprocedure. Plaats het desondanks achter een reverse proxy met TLS en, waar mogelijk, single sign-on. Publiceer de containerpoort als 127.0.0.1:3000:8080 zodat de eigen iptables-regels van Docker deze niet onbedoeld openstellen voor het internet.

Welk Open WebUI-alternatief verbruikt het minste RAM op een VPS?

De browsergebaseerde opties, Hollama en OrionChat, omdat de applicatie op de client draait. De server verstuurt enkel statische bestanden en OrionChat vereist zelfs helemaal geen applicatiecontainer. Open WebUI houdt een Python-proces, een database en, standaard, een lokaal embedding-model in het geheugen; dit wordt gedocumenteerd op ongeveer 500 MB per worker voor enkel het embedding-model. Controleer de cijfers op uw eigen systeem met docker stats --no-stream, aangezien deze variëren afhankelijk van de functies die u inschakelt.

Kunnen deze chat-interfaces een Ollama-server op een andere host gebruiken?

Open WebUI en LibreChat kunnen dit, waarbij hun server de verbinding tot stand brengt, waardoor er geen browserbeperkingen gelden. Stel OLLAMA_BASE_URL in voor Open WebUI, of baseURL in een aangepast eindpunt voor LibreChat. Gebruik voor vLLM of een andere OpenAI-compatibele server OPENAI_API_BASE_URL met het /v1-achtervoegsel en een niet-lege API-sleutel. Hollama en OrionChat kunnen ook naar elke locatie verwijzen, maar het verzoek komt vanuit uw browser, dus het eindpunt moet ook vanuit uw browser bereikbaar zijn.

Waarom kan mijn browser-chat-interface Ollama niet bereiken?

Twee oorzaken verklaren bijna elk geval. Ollama bindt standaard aan 127.0.0.1:11434, waardoor een browser op een andere machine het nooit bereikt totdat OLLAMA_HOST wordt gewijzigd. Daarnaast accepteert Ollama alleen cross-origin-verzoeken vanaf localhost, waardoor een pagina die vanaf uw eigen domein wordt geserveerd wordt geweigerd met No 'Access-Control-Allow-Origin' header is present on the requested resource totdat die oorsprong is vermeld in OLLAMA_ORIGINS. Als de pagina HTTPS is en het eindpunt HTTP, blokkeert de browser het verzoek als mixed content voordat Ollama het überhaupt ziet. Stel beide variabelen in via een systemctl edit ollama.service-override, of stuur de poort door via SSH en het probleem is verholpen.