Sådan self-hoster du Open WebUI i 2026: modelendpoints, storage og sikkerhed

Betragt Open WebUI som et lille system, ikke som et Docker-image. Det brugerrettede mål for Open WebUI er klart: en chatgrænseflade til OpenAI-kompatible og lokale modelendpoints. Deploymentet er kun acceptabelt, når du kan forbinde ét remote modelendpoint, streame et chatsvar, uploade et dokument, køre retrieval og åbne samtalen igen efter en genstart.

Den skelnen afslører den fejltilstand, operatører møder efter lokal test: OLLAMA_BASE_URL peger på localhost inde i WebUI-containeren. Den gør også backup- og upgrade-planen tilstrækkeligt specifik til, at den kan testes.

Vælg den mindst mulige Open WebUI-topologi

Start med Open WebUIs network namespace: dens web listener er port 8080, ikke en host-port kopieret fra en laptop-tutorial. Netværkskontrakten for Open WebUI er en OpenAI-kompatibel API eller en Ollama-service, der kan nås. Hold private endpoints på intern DNS, tillad kun nødvendige outbound-kald, og giv Open WebUI en afgrænset service credential.

Når kravet er opfyldt, skal du køre hele scenariet — forbind ét remote modelendpoint, stream et chatsvar, upload et dokument, kør retrieval, og åbn samtalen igen efter en genstart. Registrer logs og målinger for modellatens, samtidige streams, embedding-jobs, størrelse på uploadede filer og vækst i vector-indexet. Disse data bliver den første kendte velfungerende arkitektur og gør senere flytninger mellem Dockup-compute og en tilknyttet server testbare.

TLS er nemt; genererede URL'er er ikke

Udstedelse af TLS er kun halvdelen af Open WebUI-ruten. Sørg for, at modelendpointet kan nås fra containernetværket. Send trafik internt til 8080, og forward den eksterne scheme, så genererede URL'er og secure cookies forbliver konsistente.

Brug det komplette Open WebUI-scenarie fra et rent netværk, ikke kun root-siden. En 502- eller certifikatfejl kan isoleres med automatisk domain- og TLS-opsætning. Hvis trafikken når processen, og OLLAMA_BASE_URL peger på localhost inde i WebUI-containeren, skal du diagnosticere tilstanden dér, hvor den opstår, i stedet for at stable redirects oven på hinanden.

Start Open WebUI uden at skjule de bevægelige dele

Hold den første Open WebUI-invocation reproducerbar nok til at kunne gennemgå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

Stol ikke på latest, når der først findes rigtige data. Gem det fungerende digest, container-brugeren og mount-ejerskabet. Følg applikationsloggen gennem en komplet test — forbind ét remote modelendpoint, stream et chatsvar, upload et dokument, kør retrieval, og åbn samtalen igen efter en genstart — og notér eventuelle migrations, før du sender ruten gennem produktions-trafik.

Opgradér Open WebUI uden at gætte

Et idle health check siger ikke meget om Open WebUI. Overvåg modellatens, samtidige streams, embedding-jobs, størrelse på uploadede filer og vækst i vector-indexet, og lav derefter alarmer på det symptom, brugerne oplever: at handlingen “forbind ét remote modelendpoint, stream et chatsvar, upload et dokument, kør retrieval, og åbn samtalen igen efter en genstart” fejler. Hold liveness lokal og billig; lad readiness rapportere migrations eller initialisering uden at forårsage en restart storm.

Det risikable ved en upgrade er, at database-migrations, retrieval backends og modelendpoint-indstillinger kan ændre sig uafhængigt af chatfrontendenden. Læs release notes, tag et snapshot af state, deploy target-versionen mod en restored kopi, og gentag acceptance-handlingen. Hvis OLLAMA_BASE_URL peger på localhost inde i WebUI-containeren, skal du korrelere klientrequesten med den første relevante applikationslog i stedet for blindt at slette state eller tilføje redirects.

Fem checks, der er stærkere end container health

Lad ikke den første brugertrafik være acceptancetesten for Open WebUI. Forbered ufarlig sample state, og kør den komplette handling “forbind ét remote modelendpoint, stream et chatsvar, upload et dokument, kør retrieval, og åbn samtalen igen efter en genstart”. Notér den præcise offentlige URL, resultatet, image-referencen og det loginterval, der er knyttet til kørslen.

Erstat containeren, og gentag uden at genopbygge data. Gendan derefter på en tom host; recovery-kravet er, at konti, chats, filer og retrieval collections kommer tilbage, og at den restored instans kan nå det samme modelendpoint. Observer modellatens, samtidige streams, embedding-jobs, størrelse på uploadede filer og vækst i vector-indexet ved hver kørsel, og definér en alarm omkring forringelse af transaktionen i stedet for omkring idle container-metrics.

En sidste check skal fejle med vilje: Afvis midlertidigt testidentitetens adgang til en OpenAI-kompatibel API eller en Ollama-service, der kan nås. Kontrollér, at den resulterende Open WebUI-meddelelse identificerer den relevante grænse i stedet for at udløse sletning af data eller en endeløs restart. Gendan den gyldige tilstand, og bekræft, at den samme sample-transaktion lykkes. Behold denne korte øvelse i release-checklisten.

Find alle persistente bytes i Open WebUI

For Open WebUI starter redeploy-sikkerhed med brugere, chats, filer, vectordata og applikationskonfiguration. Mount /app/backend/data før bootstrap, skriv ufarlige sample data, og erstat containeren for at bevise, at stien faktisk er persistent. Test stien ved at erstatte containeren, mens de ufarlige sample data stadig findes; det afslører mounts, der peger én mappe for højt eller lavt.

Test derefter disaster recovery på en tom host. Brug et application-consistent database-export, hvor det er nødvendigt, og verificér, at konti, chats, filer og retrieval collections kommer tilbage, og at den restored instans kan nå det samme modelendpoint. Guiden til database-backups, der er blevet restore-testet giver et stærkere mål end blot at kontrollere, at der er blevet oprettet en archive-fil.

Giv ikke Open WebUI hele hosten

Et sikkert Open WebUI-deployment starter med at fjerne rettigheder. Undgå at lade signup stå åbent eller bruge en ephemeral WEBUI_SECRET_KEY; deaktivér i stedet public sign-up, medmindre det er tilsigtet, behold en stabil WebUI-secret, og begræns modeladministration til trusted users.

Behandl WEBUI_SECRET_KEY i overensstemmelse med dens rolle i Open WebUI: Hold sensitive værdier ude af Git, dokumentér konsekvenserne af rotation, og brug aldrig et offentligt eksempel i produktion. Begræns administrative routes, brug privat DNS til dependencies, og gennemgå hvert bind mount. Når logs sendes centralt, skal secrets og privat indhold filtreres, før de forlader serveren.

Brug Dockup til platformlaget

Dockup fjerner manuelt reverse-proxy- og lifecycle-arbejde omkring Open WebUI. Servicen får en stabil HTTPS-route til 8080, injected konfiguration og persistent storage ved udskiftninger. En tilknyttet kundeserver følger samme model som Dockup-hostet compute.

Efter launch skal du opfylde applikationskontrakten: Sørg for, at modelendpointet kan nås fra containernetværket, forbind til og test en OpenAI-kompatibel API eller en Ollama-service, der kan nås, og kør dette proof: forbind ét remote modelendpoint, stream et chatsvar, upload et dokument, kør retrieval, og åbn samtalen igen efter en genstart. Det holder one-click-oplevelsen nyttig uden at udviske de detaljer, der gør Open WebUI gendanneligt og sikkert.

Ofte stillede spørgsmål

Hvad har Open WebUI brug for i et produktionsdeployment?

Route Open WebUI-containeren på port 8080 gennem én HTTPS-origin. Det understøttende netværkskrav er en OpenAI-kompatibel API eller en Ollama-service, der kan nås. Kald ikke Open WebUI klar, før du kan forbinde ét remote modelendpoint, streame et chatsvar, uploade et dokument, køre retrieval og åbne samtalen igen efter en genstart.

Hvilke Open WebUI-data skal med i en backup?

Gør /app/backend/data persistent, og inkludér brugere, chats, filer, vectordata og applikationskonfiguration i det samme recovery-manifest. En ren Open WebUI-restore er kun vellykket, når konti, chats, filer og retrieval collections kommer tilbage, og den restored instans kan nå det samme modelendpoint.

Kræver Open WebUI HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Open WebUI-origin, og behold port 8080 på den interne route. Anvend Open WebUI-indstillingen korrekt: Sørg for, at modelendpointet kan nås fra containernetværket. For Open WebUI beskytter HTTPS credentials eller brugerindhold under transport og holder origin-følsom klientadfærd konsistent.

Hvordan skal en Open WebUI-upgrade testes?

Restore den aktuelle Open WebUI-state til et isoleret deployment, anvend kandidatversionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi database-migrations, retrieval backends og modelendpoint-indstillinger kan ændre sig uafhængigt af chatfrontendenden. Behold det tidligere Open WebUI-image, indtil dets data-migrations- og rollback-grænse er forstået.