Päiväkirjan hakemistoDockup / kenttämuistio
Note / self-host-open-webui

Open WebUIn itse isännöinti vuonna 2026: mallipäätepisteet, tallennus ja tietoturva

Käytännön opas Open WebUIn itse isännöintiin: Docker, portit, pysyvä data, TLS, tietoturva, varmuuskopiot ja tuotantokäytön estävät ongelmat vuonna 2026.

Käsittele Open WebUIta pienenä järjestelmänä, älä Docker-imagena. Open WebUIn käyttäjälle näkyvä tavoite on selkeä: chat-käyttöliittymä OpenAI-yhteensopiville ja paikallisille mallipäätepisteille. Käyttöönotto on hyväksyttävä vasta, kun voit yhdistää yhden etämallipäätepisteen, suoratoistaa chat-vastauksen, ladata dokumentin, suorittaa retrieval-haun ja avata keskustelun uudelleen uudelleenkäynnistyksen jälkeen.

Tämä erottelu paljastaa ongelman, jonka ylläpitäjät kohtaavat paikallisen testauksen jälkeen: OLLAMA_BASE_URL osoittaa localhost-osoitteeseen WebUI-kontin sisällä. Samalla varmuuskopiointi- ja päivityssuunnitelmasta tulee riittävän täsmällinen testattavaksi.

Valitse pienin toimiva Open WebUI -topologia

Aloita Open WebUIn network namespacesta: sen web-kuuntelija käyttää porttia 8080, ei laptop-oppaasta kopioitua host-porttia. Open WebUIn verkkosopimus on OpenAI-yhteensopiva API tai tavoitettavissa oleva Ollama-palvelu. Pidä yksityiset päätepisteet sisäisessä DNS:ssä, salli vain tarvittavat lähtevät yhteydet ja anna Open WebUIlle rajatun käyttöoikeuden service credential.

Kun vaatimus on täytetty, suorita koko käyttötapaus — yhdistä yksi etämallipäätepiste, suoratoista chat-vastaus, lataa dokumentti, suorita retrieval-haku ja avaa keskustelu uudelleen uudelleenkäynnistyksen jälkeen. Tallenna lokit ja mittaustiedot mallin latenssista, samanaikaisista streamauksista, embedding-töistä, ladattujen tiedostojen koosta ja vektori-indeksin kasvusta. Näistä tiedoista muodostuu ensimmäinen tunnetusti toimiva arkkitehtuuri, ja niiden avulla myöhemmät siirrot Dockupin laskentaan tai liitetylle palvelimelle voidaan testata.

TLS on helppo; generoidut URL-osoitteet eivät

TLS:n käyttöönotto on vain puolet Open WebUIn reitistä. Varmista, että mallipäätepisteeseen pääsee konttiverkosta. Ohjaa liikenne sisäisesti porttiin 8080 ja välitä ulkoinen scheme, jotta generoidut URL-osoitteet ja secure cookiet pysyvät yhdenmukaisina.

Käytä Open WebUIn täydellistä käyttötapausta puhtaasta verkosta, älä ainoastaan juurisivua. 502- tai sertifikaattivirhe voidaan eristää automaattisella domain- ja TLS-määrityksellä. Jos liikenne saavuttaa prosessin ja OLLAMA_BASE_URL osoittaa localhost-osoitteeseen WebUI-kontin sisällä, selvitä ongelma siinä kohdassa, jossa se ilmenee, äläkä lisää uudelleenohjauksia kerroksittain.

Käynnistä Open WebUI piilottamatta muuttuvia osia

Pidä alkuperäinen Open WebUI -käynnistys riittävän toistettavana, jotta se voidaan tarkistaa pull requestissa.

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

Älä luota latest-tagiin sen jälkeen, kun käytössä on oikeaa dataa. Tallenna toimiva digest, kontin käyttäjä ja mountin omistajuus. Seuraa sovelluslokia koko testin ajan — yhdistä yksi etämallipäätepiste, suoratoista chat-vastaus, lataa dokumentti, suorita retrieval-haku ja avaa keskustelu uudelleen uudelleenkäynnistyksen jälkeen — ja merkitse muistiin mahdolliset migraatiot ennen reitin avaamista tuotantoliikenteelle.

Päivitä Open WebUI arvailematta

Tyhjäkäynnin health check kertoo Open WebUIsta vain vähän. Seuraa mallin latenssia, samanaikaisia streamauksia, embedding-töitä, ladattujen tiedostojen kokoa ja vektori-indeksin kasvua. Hälytä sitten käyttäjien kokemasta oireesta: toiminto “yhdistä yksi etämallipäätepiste, suoratoista chat-vastaus, lataa dokumentti, suorita retrieval-haku ja avaa keskustelu uudelleen uudelleenkäynnistyksen jälkeen” epäonnistuu. Pidä liveness paikallisena ja kevyenä; anna readinessin ilmoittaa migraatioista tai alustuksesta ilman restart stormia.

Riskialtis päivitysalue liittyy siihen, että tietokantamigraatiot, retrieval-backendit ja mallipäätepisteiden asetukset voivat muuttua chat-frontendistä riippumatta. Lue release notes, ota tilasta snapshot, ota kohdeversion käyttöönotto käyttöön palautetun kopion päällä ja toista hyväksyntätoiminto. Jos OLLAMA_BASE_URL osoittaa localhost-osoitteeseen WebUI-kontin sisällä, yhdistä client-pyyntö ensimmäiseen asiaankuuluvaan sovelluslokiin sen sijaan, että poistaisit tilan tai lisäisit uudelleenohjauksia umpimähkään.

Viisi konttiterveyttä vahvempaa tarkistusta

Älä käytä ensimmäisen käyttäjän liikennettä Open WebUIn hyväksyntätestinä. Valmistele harmiton esimerkkitila ja suorita koko toiminto: “yhdistä yksi etämallipäätepiste, suoratoista chat-vastaus, lataa dokumentti, suorita retrieval-haku ja avaa keskustelu uudelleen uudelleenkäynnistyksen jälkeen”. Merkitse muistiin suoritukseen liittyvä tarkka julkinen URL, tulos, image reference ja lokijakso.

Korvaa kontti ja toista testi rakentamatta dataa uudelleen. Palauta seuraavaksi ympäristö tyhjälle hostille; palautuksen ehtona on, että käyttäjätilit, chatit, tiedostot ja retrieval-kokoelmat palaavat ja palautettu instanssi saavuttaa saman mallipäätepisteen. Seuraa mallin latenssia, samanaikaisia streamauksia, embedding-töitä, ladattujen tiedostojen kokoa ja vektori-indeksin kasvua jokaisella kierroksella. Määritä hälytys transaktion heikkenemisen, ei tyhjäkäyvän kontin metriikoiden, perusteella.

Yhden viimeisen tarkistuksen tulee epäonnistua tarkoituksella: estä testikäyttäjän pääsy OpenAI-yhteensopivaan APIin tai tavoitettavissa olevaan Ollama-palveluun. Varmista, että Open WebUIn ilmoitus tunnistaa oikean rajapinnan eikä käynnistä datan poistamista tai loputonta restartia. Palauta toimiva tila ja varmista, että sama esimerkkitransaktio onnistuu. Pidä tämä lyhyt harjoitus mukana release checklistissä.

Etsi jokainen Open WebUIn pysyvä tavu

Open WebUIn tapauksessa uudelleenkäyttöönoton turvallisuus alkaa käyttäjistä, chateista, tiedostoista, vektoreista ja sovelluksen konfiguraatiosta. Mounttaa /app/backend/data ennen bootstrapia, kirjoita harmitonta esimerkkidataa ja korvaa kontti varmistaaksesi, että polku on todella pysyvä. Testaa polku korvaamalla kontti, kun harmiton esimerkkidata on olemassa; näin paljastuvat mountit, jotka osoittavat yhden hakemiston liian ylös tai alas.

Testaa seuraavaksi disaster recovery tyhjällä hostilla. Käytä tarvittaessa sovelluksen kannalta yhdenmukaista tietokantavientiä ja varmista, että käyttäjätilit, chatit, tiedostot ja retrieval-kokoelmat palaavat ja palautettu instanssi saavuttaa saman mallipäätepisteen. Palautustestattu tietokannan varmuuskopiointiopas tarjoaa vahvemman tavoitteen kuin pelkkä sen tarkistaminen, että archive-tiedosto luotiin.

Älä anna Open WebUIlle koko hostia

Turvallinen Open WebUI -käyttöönotto alkaa valtuuksien karsimisesta. Älä jätä rekisteröitymistä avoimeksi tai käytä ephemeral WEBUI_SECRET_KEY -arvoa. Poista sen sijaan julkinen rekisteröityminen käytöstä, ellei sille ole tarkoituksellista tarvetta, säilytä pysyvä WebUI-salaisuus ja rajaa mallien hallinta luotetuille käyttäjille.

Käsittele WEBUI_SECRET_KEY-arvoa sen Open WebUI -roolin mukaisesti: pidä arkaluonteiset arvot poissa Gitistä, dokumentoi rotaation vaikutukset äläkä korvaa tuotantoarvoa julkisella esimerkillä. Rajoita hallinnollisia reittejä, käytä riippuvuuksille yksityistä DNS:ää ja tarkista jokainen bind mount. Kun lokit toimitetaan keskitetysti, suodata salaisuudet ja yksityinen sisältö ennen niiden poistumista palvelimelta.

Käytä Dockupia alustakerrokseen

Dockup poistaa Open WebUIn ympäriltä manuaalisen reverse proxyn ja lifecycle-työn. Palvelu saa vakaan HTTPS-reitin porttiin 8080, injektoidun konfiguraation ja pysyvän tallennustilan korvausten aikana. Liitetty asiakaspalvelin noudattaa samaa mallia kuin Dockupin isännöimä laskenta.

Käynnistyksen jälkeen täytä sovelluksen sopimus: varmista, että mallipäätepisteeseen pääsee konttiverkosta, yhdistä OpenAI-yhteensopiva API tai tavoitettavissa oleva Ollama-palvelu ja suorita tämä todiste: yhdistä yksi etämallipäätepiste, suoratoista chat-vastaus, lataa dokumentti, suorita retrieval-haku ja avaa keskustelu uudelleen uudelleenkäynnistyksen jälkeen. Näin one-click-kokemus pysyy hyödyllisenä ilman, että Open WebUIn palautettavuuden ja turvallisuuden kannalta olennaiset yksityiskohdat häivytetään.

Usein kysytyt kysymykset

Mitä Open WebUI tarvitsee tuotantokäyttöönottoon?

Reititä Open WebUI -kontti portissa 8080 yhden HTTPS-originiin kautta. Taustalla tarvitaan OpenAI-yhteensopiva API tai tavoitettavissa oleva Ollama-palvelu. Älä pidä Open WebUIta valmiina, ennen kuin voit yhdistää yhden etämallipäätepisteen, suoratoistaa chat-vastauksen, ladata dokumentin, suorittaa retrieval-haun ja avata keskustelun uudelleen uudelleenkäynnistyksen jälkeen.

Mitkä Open WebUIn tiedot kuuluvat varmuuskopioon?

Säilytä /app/backend/data ja sisällytä käyttäjät, chatit, tiedostot, vektoritiedot ja sovelluksen konfiguraatio samaan palautusmanifestiin. Puhdas Open WebUI -palautus onnistuu vain, kun käyttäjätilit, chatit, tiedostot ja retrieval-kokoelmat palaavat ja palautettu instanssi saavuttaa saman mallipäätepisteen.

Tarvitseeko Open WebUI HTTPS:ää reverse proxyn takana?

Käytä julkisessa Open WebUI -originissa HTTPS:ää ja pidä portti 8080 sisäisessä reitissä. Määritä Open WebUIn asetus oikein: varmista, että mallipäätepisteeseen pääsee konttiverkosta. Open WebUIn tapauksessa HTTPS suojaa tunnistetietoja tai käyttäjäsisältöä siirron aikana ja pitää originista riippuvan client-käyttäytymisen yhdenmukaisena.

Miten Open WebUIn päivitys pitäisi testata?

Palauta nykyinen Open WebUI -tila eristettyyn käyttöönottoon, ota ehdokasversio käyttöön ja toista sen hyväksyntätransaktio. Kiinnitä erityistä huomiota siihen, että tietokantamigraatiot, retrieval-backendit ja mallipäätepisteiden asetukset voivat muuttua chat-frontendistä riippumatta. Säilytä aiempi Open WebUI -image, kunnes sen datamigraation ja rollbackin rajat on ymmärretty.