Open WebUI zelf hosten in 2026: model-endpoints, opslag en beveiliging

Behandel Open WebUI als een klein systeem, niet als een Docker-image. Het doel voor gebruikers van Open WebUI is duidelijk: een chatinterface voor OpenAI-compatibele en lokale model-endpoints. De deployment is pas geschikt wanneer je één remote model-endpoint kunt verbinden, een chatantwoord kunt streamen, een document kunt uploaden, retrieval kunt uitvoeren en het gesprek na een herstart opnieuw kunt openen.

Dat onderscheid brengt de foutmodus aan het licht die operators na lokale tests tegenkomen: OLLAMA_BASE_URL verwijst binnen de WebUI-container naar localhost. Het maakt het back-up- en upgradeplan bovendien specifiek genoeg om te testen.

Kies de kleinst mogelijke Open WebUI-topologie

Begin met de network namespace van Open WebUI: de weblistener gebruikt poort 8080, niet een hostpoort die je uit een laptoptutorial hebt overgenomen. Het netwerkcontract voor Open WebUI is een OpenAI-compatibele API of een bereikbare Ollama-service. Houd private endpoints op interne DNS, sta alleen de vereiste uitgaande verbindingen toe en geef Open WebUI een beperkte servicecredential.

Voer, zodra aan de vereiste is voldaan, het volledige scenario uit — verbind één remote model-endpoint, stream een chatantwoord, upload een document, voer retrieval uit en open het gesprek opnieuw na een herstart. Leg logs en metingen vast voor modellatentie, gelijktijdige streams, embedding-jobs, de grootte van geüploade bestanden en de groei van de vector-index. Dit bewijs vormt de eerste bekende goede architectuur en maakt latere verplaatsingen tussen Dockup-compute en een aangesloten server testbaar.

TLS is eenvoudig; gegenereerde URL's niet

Het uitgeven van TLS is slechts de helft van de Open WebUI-route. Zorg dat het model-endpoint bereikbaar is vanaf het containernetwerk. Stuur verkeer intern naar 8080 en geef het externe scheme door, zodat gegenereerde URL's en secure cookies consistent blijven.

Gebruik het volledige Open WebUI-scenario vanaf een schoon netwerk, niet alleen de rootpagina. Een 502- of certificaatfout kun je isoleren met automatische domein- en TLS-configuratie. Als het verkeer het proces bereikt en OLLAMA_BASE_URL binnen de WebUI-container naar localhost verwijst, diagnoseer je die situatie op de plek waar ze optreedt in plaats van redirects op elkaar te stapelen.

Start Open WebUI zonder de bewegende delen te verbergen

Houd de eerste aanroep van Open WebUI voldoende reproduceerbaar om in een pull request te kunnen reviewen.

docker run -d \
  --name open-webui \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v open-webui-data:/app/backend/data \
  -e WEBUI_SECRET_KEY=replace-with-a-long-random-value \
  ghcr.io/open-webui/open-webui:main

Vertrouw niet op latest zodra er echte data bestaat. Leg de werkende digest, container user en mount-eigenaarschap vast. Volg de applicatielog tijdens een volledige test — verbind één remote model-endpoint, stream een chatantwoord, upload een document, voer retrieval uit en open het gesprek opnieuw na een herstart — en noteer eventuele migrations voordat je de route achter productie­verkeer plaatst.

Upgrade Open WebUI zonder te gokken

Een inactieve health check zegt weinig over Open WebUI. Houd modellatentie, gelijktijdige streams, embedding-jobs, de grootte van geüploade bestanden en de groei van de vector-index in de gaten en alarmeer op het symptoom dat gebruikers ervaren: het mislukken van de actie “verbind één remote model-endpoint, stream een chatantwoord, upload een document, voer retrieval uit en open het gesprek opnieuw na een herstart”. Houd liveness lokaal en goedkoop; laat readiness migrations of initialisatie rapporteren zonder een restart storm te veroorzaken.

Het risicovolle deel van een upgrade is dat database migrations, retrieval-backends en model-endpointinstellingen onafhankelijk van de chatfrontend kunnen veranderen. Lees de release notes, maak een snapshot van de state, deploy de doelversie tegen een herstelde kopie en herhaal de acceptatieactie. Als OLLAMA_BASE_URL binnen de WebUI-container naar localhost verwijst, breng je het clientverzoek in verband met de eerste relevante applicatielog in plaats van blind state te verwijderen of redirects toe te voegen.

Vijf controles die sterker zijn dan container health

Maak verkeer van de eerste gebruiker niet tot de acceptatietest voor Open WebUI. Bereid onschadelijke voorbeelddata voor en voer de volledige actie uit: “verbind één remote model-endpoint, stream een chatantwoord, upload een document, voer retrieval uit en open het gesprek opnieuw na een herstart”. Noteer de exacte publieke URL, het resultaat, de image-referentie en het loginterval dat bij de run hoort.

Vervang de container en herhaal de test zonder de data opnieuw op te bouwen. Herstel vervolgens naar een lege host; de herstelvoorwaarde is dat accounts, chats, bestanden en retrieval-collecties terugkomen en dat de herstelde instance hetzelfde model-endpoint kan bereiken. Observeer bij elke run modellatentie, gelijktijdige streams, embedding-jobs, de grootte van geüploade bestanden en de groei van de vector-index en definieer een alert rond verslechtering van de transactie, niet rond metrics van een inactieve container.

Eén laatste controle moet bewust mislukken: blokkeer tijdelijk de toegang van de testidentiteit tot een OpenAI-compatibele API of bereikbare Ollama-service. Controleer of het resulterende Open WebUI-bericht de relevante grens identificeert in plaats van dataverwijdering of een eindeloze restart te veroorzaken. Herstel de geldige situatie en bevestig dat dezelfde voorbeeldtransactie slaagt. Neem deze korte oefening op in de releasechecklist.

Vind elke persistente byte in Open WebUI

Voor Open WebUI begint veilige redeployment bij gebruikers, chats, bestanden, vectordata en applicatieconfiguratie. Mount /app/backend/data vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Test het pad door de container te vervangen terwijl de onschadelijke voorbeelddata aanwezig is; zo ontdek je mounts die één directory te hoog of te laag wijzen.

Test vervolgens disaster recovery op een lege host. Gebruik waar nodig een applicatieconsistente database-export en controleer of accounts, chats, bestanden en retrieval-collecties terugkomen en of de herstelde instance hetzelfde model-endpoint kan bereiken. De handleiding voor database-back-ups die je hebt getest met een restore biedt een sterker doel dan alleen controleren of er een archiefbestand is aangemaakt.

Geef Open WebUI niet de volledige host

Een veilige Open WebUI-deployment begint met het intrekken van bevoegdheden. Laat signup niet openstaan en gebruik geen ephemeral WEBUI_SECRET_KEY; schakel publieke signup in plaats daarvan uit tenzij die bewust gewenst is, behoud een stabiele WebUI-secret en beperk modelbeheer tot vertrouwde gebruikers.

Behandel WEBUI_SECRET_KEY overeenkomstig zijn rol binnen Open WebUI: houd gevoelige waarden buiten Git, documenteer de gevolgen van rotation en gebruik in productie nooit een publiek voorbeeld. Beperk administratieve routes, gebruik private DNS voor dependencies en controleer elke bind mount. Wanneer logs centraal worden verzonden, filter je secrets en private content voordat ze de server verlaten.

Gebruik Dockup voor de platformlaag

Dockup neemt het handmatige reverse-proxy- en lifecyclewerk rond Open WebUI weg. De service krijgt tijdens replacements een stabiele HTTPS-route naar 8080, geïnjecteerde configuratie en persistente opslag. Een aangesloten klantserver volgt hetzelfde model als door Dockup gehoste compute.

Voer na de launch het applicatiecontract uit: zorg dat het model-endpoint bereikbaar is vanaf het containernetwerk, verbind een OpenAI-compatibele API of bereikbare Ollama-service en voer dit bewijs uit: verbind één remote model-endpoint, stream een chatantwoord, upload een document, voer retrieval uit en open het gesprek opnieuw na een herstart. Zo blijft de one-click-ervaring nuttig zonder de details weg te abstraheren die Open WebUI herstelbaar en veilig maken.

Veelgestelde vragen

Wat heeft Open WebUI nodig voor een productie­deployment?

Routeer de Open WebUI-container op poort 8080 via één HTTPS-origin. De ondersteunende netwerkvereiste is een OpenAI-compatibele API of bereikbare Ollama-service. Verklaar Open WebUI pas gereed wanneer je één remote model-endpoint kunt verbinden, een chatantwoord kunt streamen, een document kunt uploaden, retrieval kunt uitvoeren en het gesprek na een herstart opnieuw kunt openen.

Welke Open WebUI-data hoort in een back-up?

Maak /app/backend/data persistent en neem gebruikers, chats, bestanden, vectordata en applicatieconfiguratie op in hetzelfde recovery manifest. Een schone Open WebUI-restore is alleen geslaagd wanneer accounts, chats, bestanden en retrieval-collecties terugkomen en de herstelde instance hetzelfde model-endpoint kan bereiken.

Heeft Open WebUI HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Open WebUI-origin en houd poort 8080 op de interne route. Pas de Open WebUI-instelling correct toe: zorg dat het model-endpoint bereikbaar is vanaf het containernetwerk. Voor Open WebUI beschermt HTTPS credentials of gebruikerscontent tijdens transport en houdt het origin-gevoelig clientgedrag consistent.

Hoe moet een Open WebUI-upgrade worden getest?

Herstel de huidige Open WebUI-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let vooral op database migrations, retrieval-backends en model-endpointinstellingen, omdat die onafhankelijk van de chatfrontend kunnen veranderen. Bewaar de vorige Open WebUI-image totdat de grenzen van datamigratie en rollback duidelijk zijn.