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 beheerderspaneel 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 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 het model niet kan gebruiken.
• Authenticatie. Sommige van deze projecten hebben gebruikersaccounts en rollen. Andere gaan ervan uit dat zij de enige applicatie op uw laptop zijn en hebben helemaal geen 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 vectordatabase 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 de Ollama-bibliotheekpagina's in augustus 2026 vermeldden. Het zijn gepubliceerde groottes, geen metingen. Op een 4 GB VPS laat qwen3:4b met 2.5 GB minder dan 1,5 GB over voor het besturingssysteem en alle overige processen. De context-cache snoept hiervan af naarmate een gesprek vordert; daarom is de num_ctx die u instelt net zozeer een beslissing over geheugen als over kwaliteit. qwen3:8b met 5.2 GB past helemaal niet op die server. Dit is de situatie die laptop-overzichten nooit behandelen, 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 bepalende factor te zijn.

Meet zelf in plaats van te vertrouwen op een getal in een overzicht, inclusief dit overzicht. 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. Ollama geeft de gewichten bovendien vrij na vijf minuten inactiviteit. Een meting tussen gesprekken door onderschat daarom de piekbelasting, en het volgende bericht zorgt opnieuw voor de volledige belasting, tenzij u het model in het geheugen houdt met keep_alive.

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 luistert op elke interface. 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 daarna 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 projecten hieronder omdat het meer functionaliteit biedt, en de eigen prestatiepagina benoemt de onderdelen die dit kosten. 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. Op SQLite met DATABASE_POOL_SIZE uitgeschakeld, valt de pool terug op een grote interne omvang en elke verbinding vergroot zijn eigen page cache en geheugenmap; stel daarom op een kleine machine 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 van deze is het model. MongoDB en pgvector vereisen elk hun eigen geheugen, en op een 4 GB server is dat geheugen dat het model nodig had.

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

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

git pull stopt met een conflict als u de 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 herstart 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 inlogfunctie, omdat geen van beide een server heeft die deze kan verifiëren. Op een laptop is dat prima. 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 plain HTTP-endpoint 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 tonen 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, want een open 11434 is een open modelserver en massascanners vinden een nieuwe publieke poort snel. De onderstaande SSH-tunnel omzeilt de hele kwestie: de pagina draait dan op een localhost origin, wat Ollama standaard toestaat, en de poort verlaat nooit de server.

Kan elke interface een extern Ollama- of vLLM-endpoint gebruiken?

Open WebUI kan dit, waarbij de verbinding aan de serverzijde wordt opgezet. 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 endpoint. Dat verzoek verlaat eveneens de server, dus er zijn geen browserregels van toepassing. Dezelfde basis-URL en dezelfde placeholder-sleutel werken ook buiten een chatvenster; dat is alles wat nodig is om een codeer-agent te koppelen aan het model dat u al host.

Hollama en OrionChat kunnen verwijzen naar elk endpoint dat u in hun instellingen invoert, maar het verzoek verlaat hierbij uw browser. Alles in de bovenstaande sectie is van toepassing op deze applicaties en op niets anders in dit overzicht.

Het scheiden van de interface en het model is het grootste voordeel van een extern endpoint. Plaats de interface op een kleine server en het model op een systeem met voldoende geheugen. Dit is ook het moment om te bepalen of Ollama of vLLM de verzoeken moet afhandelen, omdat beide zich heel anders gedragen zodra meerdere gebruikers tegelijkertijd met het model communiceren. Als de modelserver nog niet bestaat, begin dan met het draaien van Ollama op een VPS, en lees op een systeem zonder GPU hoe Ollama zich verhoudt tot llama.cpp voordat u een keuze maakt voor de runner.

Publiceer nooit een chat-UI zonder inlogscherm op 0.0.0.0

De hardening-pagina van Open WebUI stelt dat het project is "gebouwd voor private, vertrouwde netwerken, vergelijkbaar met andere zelfgehoste 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 inlogbeveiliging verdient ten minste dezelfde behandeling.

Controleer wat er luistert voordat u de beveiliging 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 inlogfunctie van Open WebUI met WEBUI_AUTH=False is een instelling voor een enkele 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, stuur vervolgens door 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 stuurt u de modelpoort door 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 ontvangt. 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 inlogmethode 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 vanaf 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 antwoordt 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 optie moet u kiezen

Als iemand anders dan u de tool gaat gebruiken, draai dan Open WebUI. Deze 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, gebruik 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 al het grootste deel van het RAM-geheugen 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 tools op 0.0.0.0 te publiceren zonder inlogscherm ervoor.

FAQ

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

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 administrator 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 heeft helemaal geen applicatiecontainer nodig. Open WebUI houdt een Python-proces, een database en, standaard, een lokaal embedding-model in het geheugen; dit is 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, en hun server maakt de verbinding, 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 de aanroep als mixed content voordat Ollama deze überhaupt ziet. Stel beide variabelen in via een systemctl edit ollama.service-override, of stuur de poort door via SSH en het probleem is opgelost.