Slik selvhoster du Open WebUI i 2026: modellendepunkter, lagring og sikkerhet

Betrakt Open WebUI som et lite system, ikke som et Docker-image. Målet på brukersiden med Open WebUI er tydelig: et chatgrensesnitt for OpenAI-kompatible og lokale modellendepunkter. Deployen er først godkjent når du kan koble til ett eksternt modellendepunkt, strømme et chatsvar, laste opp et dokument, kjøre retrieval og åpne samtalen igjen etter en omstart.

Dette skillet avdekker feilen operatører møter etter lokal testing: OLLAMA_BASE_URL peker på localhost inne i WebUI-containeren. Det gjør også planen for sikkerhetskopiering og oppgraderinger konkret nok til å kunne testes.

Velg den minste levedyktige Open WebUI-topologien

Start med Open WebUI sitt network namespace: web-lytteren bruker port 8080, ikke en host-port kopiert fra en laptop-tutorial. Nettverkskontrakten for Open WebUI er et OpenAI-kompatibelt API eller en Ollama-tjeneste som er tilgjengelig fra nettverket. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Open WebUI en avgrenset service credential.

Når kravet er oppfylt, kjører du hele scenarioet — koble til ett eksternt modellendepunkt, strøm et chatsvar, last opp et dokument, kjør retrieval og åpne samtalen igjen etter en omstart. Registrer logger og målinger for modell-latens, samtidige streams, embedding-jobber, størrelse på opplastede filer og vekst i vektorindeksen. Dette blir den første kjente, fungerende arkitekturen og gjør senere flyttinger mellom Dockup compute og en tilkoblet server testbare.

TLS er enkelt; genererte URL-er er det ikke

TLS-utstedelse er bare halvparten av Open WebUI-ruten. Sørg for at modellendepunktet er tilgjengelig fra container-nettverket. Send trafikken internt til 8080, og videresend det eksterne scheme-et slik at genererte URL-er og sikre cookies forblir konsistente.

Bruk hele Open WebUI-scenarioet fra et rent nettverk, ikke bare rotadressen. En 502-feil eller sertifikatfeil kan isoleres med automatisk domene- og TLS-oppsett. Hvis trafikken når prosessen og OLLAMA_BASE_URL peker på localhost inne i WebUI-containeren, må du diagnostisere denne tilstanden der den oppstår i stedet for å legge på flere redirects.

Start Open WebUI uten å skjule de bevegelige delene

Hold den første Open WebUI-invokeringen så reproduserbar at den kan gjennomgås i en pull request.

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

Ikke stol på latest når det finnes reelle data. Ta vare på den fungerende digest-en, container-brukeren og mount-eierskapet. Følg applikasjonsloggen gjennom en full test — koble til ett eksternt modellendepunkt, strøm et chatsvar, last opp et dokument, kjør retrieval og åpne samtalen igjen etter en omstart — og noter eventuelle migreringer før du legger ruten bak produksjonstrafikk.

Oppgrader Open WebUI uten å gjette

En passiv health check sier lite om Open WebUI. Følg med på modell-latens, samtidige streams, embedding-jobber, størrelse på opplastede filer og vekst i vektorindeksen. Varsle deretter på symptomet brukerne faktisk opplever: at handlingen «koble til ett eksternt modellendepunkt, strøm et chatsvar, last opp et dokument, kjør retrieval og åpne samtalen igjen etter en omstart» mislykkes. Hold liveness lokal og rimelig; la readiness rapportere migreringer eller initialisering uten å utløse en restart storm.

Det risikable ved en oppgradering er at databasemigreringer, retrieval-backend-er og innstillinger for modellendepunkter kan endres uavhengig av chatfrontend-en. Les release notes, ta et snapshot av tilstanden, deploy målversjonen mot en gjenopprettet kopi og gjenta akseptansetesten. Hvis OLLAMA_BASE_URL peker på localhost inne i WebUI-containeren, må du korrelere klientforespørselen med den første relevante applikasjonsloggen i stedet for å slette data eller legge til redirects ukritisk.

Fem kontroller som er bedre enn container health

Ikke bruk den første brukertrafikken som akseptansetest for Open WebUI. Forbered ufarlige eksempeldata og kjør hele handlingen «koble til ett eksternt modellendepunkt, strøm et chatsvar, last opp et dokument, kjør retrieval og åpne samtalen igjen etter en omstart». Noter den nøyaktige offentlige URL-en, resultatet, image-referansen og loggintervallet som hører til kjøringen.

Bytt ut containeren og gjenta uten å bygge dataene på nytt. Gjenopprett deretter til en tom host; gjenopprettingskravet er at kontoer, chatter, filer og retrieval-samlinger kommer tilbake, og at den gjenopprettede instansen kan nå det samme modellendepunktet. Observer modell-latens, samtidige streams, embedding-jobber, størrelse på opplastede filer og vekst i vektorindeksen i hver gjennomgang, og definer et varsel rundt forringelse av transaksjonen i stedet for rundt inaktive container-målinger.

Én siste kontroll skal feile med hensikt: nekt testidentiteten midlertidig tilgang til et OpenAI-kompatibelt API eller en Ollama-tjeneste som er tilgjengelig fra nettverket. Kontroller at Open WebUI-meldingen som oppstår, identifiserer den relevante grensen i stedet for å utløse sletting av data eller en endeløs restart. Gjenopprett den gyldige tilstanden og bekreft at den samme eksempeltransaksjonen lykkes. Ta med denne korte øvelsen i release-sjekklisten.

Finn hver varige byte i Open WebUI

For Open WebUI starter sikker redeploy med brukere, chatter, filer, vektordata og applikasjonskonfigurasjon. Mount /app/backend/data før bootstrap, skriv ufarlige eksempeldata og bytt ut containeren for å bevise at banen faktisk er persistent. Test banen ved å bytte ut containeren mens ufarlige eksempeldata finnes; dette avdekker mounts som peker én katalog for høyt eller lavt.

Test deretter disaster recovery på en tom host. Bruk en applikasjonskonsistent databaseeksport ved behov, og bekreft at kontoer, chatter, filer og retrieval-samlinger kommer tilbake, og at den gjenopprettede instansen kan nå det samme modellendepunktet. Guiden til database-backup som er testet ved gjenoppretting gir et bedre mål enn bare å kontrollere at en arkivfil ble opprettet.

Ikke gi Open WebUI hele hosten

En sikker Open WebUI-deploy starter med å fjerne privilegier. Unngå å la registrering være åpen eller å bruke en flyktig WEBUI_SECRET_KEY. Deaktiver i stedet offentlig registrering med mindre det er tilsiktet, behold en stabil WebUI-hemmelighet og begrens modelladministrasjon til brukere du stoler på.

Behandle WEBUI_SECRET_KEY i tråd med rollen den har i Open WebUI: hold sensitive verdier ute av Git, dokumenter konsekvensene av rotasjon og bruk aldri et offentlig eksempel i produksjon. Begrens administrative ruter, bruk privat DNS for avhengigheter og gjennomgå hvert bind mount. Når logger sendes til et sentralt system, må du filtrere bort secrets og privat innhold før de forlater serveren.

Bruk Dockup for plattformlaget

Dockup fjerner manuelt reverse-proxy- og lifecycle-arbeid rundt Open WebUI. Tjenesten får en stabil HTTPS-rute til 8080, injisert konfigurasjon og persistent storage ved utskiftinger. En tilkoblet kundeserver følger samme modell som Dockup-hostet compute.

Etter lansering må du oppfylle applikasjonskontrakten: gjør modellendepunktet tilgjengelig fra container-nettverket, koble til og test et OpenAI-kompatibelt API eller en Ollama-tjeneste som er tilgjengelig fra nettverket, og kjør denne verifiseringen: koble til ett eksternt modellendepunkt, strøm et chatsvar, last opp et dokument, kjør retrieval og åpne samtalen igjen etter en omstart. Slik forblir one-click-opplevelsen nyttig uten å skjule detaljene som gjør Open WebUI gjenopprettbart og sikkert.

Vanlige spørsmål

Hva trenger Open WebUI for en produksjonsdeploy?

Rout Open WebUI-containeren på port 8080 gjennom én HTTPS-origin. Det støttende nettverkskravet er et OpenAI-kompatibelt API eller en Ollama-tjeneste som er tilgjengelig fra nettverket. Ikke erklær Open WebUI som klar før du kan koble til ett eksternt modellendepunkt, strømme et chatsvar, laste opp et dokument, kjøre retrieval og åpne samtalen igjen etter en omstart.

Hvilke Open WebUI-data hører hjemme i en sikkerhetskopi?

Gjør /app/backend/data persistent, og inkluder brukere, chatter, filer, vektordata og applikasjonskonfigurasjon i det samme gjenopprettingsmanifestet. En ren Open WebUI-gjenoppretting er først vellykket når kontoer, chatter, filer og retrieval-samlinger kommer tilbake, og den gjenopprettede instansen kan nå det samme modellendepunktet.

Krever Open WebUI HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Open WebUI-originen, og behold port 8080 på den interne ruten. Bruk Open WebUI-innstillingen riktig: gjør modellendepunktet tilgjengelig fra container-nettverket. For Open WebUI beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for at origin-sensitiv klientadferd forblir konsistent.

Hvordan bør en Open WebUI-oppgradering testes?

Gjenopprett den aktuelle Open WebUI-tilstanden i en isolert deploy, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom, fordi databasemigreringer, retrieval-backend-er og innstillinger for modellendepunkter kan endres uavhengig av chatfrontend-en. Behold det forrige Open WebUI-imaget til grensen for datamigrering og rollback er forstått.