Mbadala bora wa Open WebUI kwa seva ya VPS

Ni mbadala gani wa Open WebUI unaofaa kwenye VPS

Mbadala wa Open WebUI mara nyingi hulinganishwa kwenye kompyuta ya mkononi, ambapo RAM ni ya bei nafuu na hakuna huduma inayosikiliza kwenye anwani ya umma. VPS hubadilisha ukweli huu wote, na hilo hubadilisha mpangilio wa ubora. Open WebUI inabaki kuwa chaguo sahihi la msingi wakati mtu wa pili anapoingia kwenye mfumo, kwa sababu inakuja na akaunti halisi za watumiaji na paneli ya usimamizi. Miradi midogo hushinda wakati kiolesura kinaposhindana na modeli kwa ajili ya gigabyte ya mwisho ya RAM. Bei ya ushindi huo ni uthibitishaji: miradi hiyo haina uthibitishaji wowote.

Kila kitu hapa chini kinatoka kwenye nyaraka za kila mradi, zilizosomwa mnamo Agosti 2026. Mhimili minne ni ile inayojitokeza tu wakati seva inafikika kutoka kwenye Internet.

Mhimili minne inayozingatiwa kwenye IP ya umma

• Kumbukumbu karibu na model. Seva ya model ndiyo mchakato wa gharama kubwa zaidi kwenye seva. Kila megabyte inayotumiwa na interface ni megabyte ambayo model haiwezi kuitumia.
• Authentication. Baadhi ya miradi hii ina akaunti za watumiaji na majukumu. Mingine hudhani kuwa ndiyo kitu pekee kinachoendeshwa kwenye kompyuta yako, na haina mfumo wowote wa kuingia (login).
• Remote inference. UI inayoweza kufikia 127.0.0.1:11434 pekee hulazimisha model kuwa kwenye mashine moja na interface.
• Upkeep. Container moja yenye faili ya SQLite ni kazi tofauti na container sita zenye MongoDB na hifadhidata ya vector nyuma yake.

Kiasi gani cha RAM ambacho model huachia interface

Interface si kitu kikubwa zaidi kwenye seva. Model ndiyo kubwa. Ukubwa wa faili za kupakua uliotangazwa unakupa msingi wa chini, kwa sababu weights lazima zikae kwenye kumbukumbu wakati model inajibu, na matumizi halisi ya kumbukumbu huwa makubwa kuliko ukubwa wa faili pindi context cache inapopangwa.

[
  {
    "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"
  }
]

Hizo ndizo takwimu zilizochapishwa kwenye kurasa za maktaba ya Ollama mnamo Agosti 2026. Ni ukubwa uliotangazwa, si vipimo halisi. Kwenye VPS ya 4 GB, qwen3:4b yenye 2.5 GB huacha chini ya 1.5 GB kwa mfumo wa uendeshaji na kila kitu kingine, na context cache hula sehemu hiyo mazungumzo yanapokua, ndiyo maana num_ctx unayoweka ni uamuzi wa kumbukumbu kama ulivyo uamuzi wa ubora. qwen3:8b yenye 5.2 GB haitoshi kabisa kwenye seva hiyo. Hii ni hali ambayo makala za mapitio ya kompyuta hazigusi, na hapa ndipo interface ya chat inayotumia mamia machache ya megabytes huamua kama model itaweza kufanya kazi. Ikiwa unapanga ukubwa wa seva kwa ajili ya kitu kikubwa zaidi ya lebo hizi, hesabu za model ya 27B kwenye VPS ya CPU pekee zinaonyesha jinsi interface inavyoacha kuwa namba inayoamua chochote.

Pima badala ya kuamini namba yoyote kwenye mapitio, ikiwemo hii. Endesha docker stats --no-stream baada ya saa moja ya matumizi halisi, si dakika moja baada ya container kuanza, kwa sababu kumbukumbu muhimu hutengwa wakati wa matumizi ya kwanza. Ollama pia huachia weights baada ya dakika tano za kutofanya kazi, kwa hivyo usomaji uliofanywa kati ya mazungumzo hupunguza ukubwa wa kilele, na ujumbe unaofuata utalazimika kupakia mzigo wote tena isipokuwa ukiiweka model kwenye kumbukumbu kwa kutumia keep_alive.

Open WebUI: bado ndiyo chaguo-msingi kwa watumiaji zaidi ya mmoja

Open WebUI huendeshwa kutoka image moja na kuhifadhi data zake kwenye volume moja.

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

Amri iliyo kwenye README ya mradi huu huchapisha -p 3000:8080, ambayo husikiliza kwenye kila interface. Kiambishi 127.0.0.1: huiweka kwenye loopback. Kwenye VPS, kiambishi hicho ni muhimu zaidi kuliko kitu kingine chochote kwenye mstari huo, kwa sababu Docker huandika sheria zake za iptables na port iliyochapishwa hupuuza sheria zako za ufw deny.

Fikia ukurasa huo kupitia tunnel au proxy, zote zimefafanuliwa hapa chini, kisha tengeneza akaunti ya kwanza. Akaunti hiyo inakuwa ya msimamizi (administrator). Usajili wa baadaye huundwa na role ya pending, ambayo ni chaguo-msingi lililoandikwa la DEFAULT_USER_ROLE, kwa hivyo mgeni anayefikia ukurasa huo bado hawezi kutumia model yako hadi msimamizi amuidhinishe.

Open WebUI hutumia kumbukumbu (memory) nyingi zaidi kuliko miradi iliyo hapa chini kwa sababu hufanya kazi nyingi zaidi, na ukurasa wake wa utendaji (performance page) hutaja sehemu zinazotumia kumbukumbu hiyo. Injini ya embedding ya chaguo-msingi hupakia model ya sentence-transformers ndani ya container, ambayo imeandikwa kuwa inatumia takriban 500 MB kwa kila worker process. Kuweka RAG_EMBEDDING_ENGINE=ollama hukabidhi kazi hiyo kwa seva ya model unayoendesha tayari. AUDIO_STT_ENGINE=webapi huepuka kupakia model ya ndani ya speech-to-text. Kwenye SQLite ikiwa DATABASE_POOL_SIZE haijawekwa, pool hurejea kwenye saizi kubwa ya ndani na kila muunganisho (connection) hukua na page cache na memory map yake yenyewe, kwa hivyo kwenye seva ndogo weka DATABASE_POOL_SIZE=8 na DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False huzuia interface kumuuliza model kwa ajili ya kukamilisha (completion) wakati mtumiaji bado anaandika.

LibreChat: watumiaji wengi, ikiwa na stack nyuma yake

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

Kiolesura hujibu kwenye port 3080. LibreChat ndiyo unayopaswa kuitazama unapohitaji mfumo wa utambulisho badala ya kisanduku cha kuingia tu: ina nyaraka za LDAP na OAuth2 logins, na inakuja na paneli ya usimamizi kwa watumiaji na majukumu. Uwezo huo huja na 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"
  }
]

Faili ya kawaida ya compose huanzisha 6 huduma: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Hakuna hata moja kati ya hizo iliyo model. MongoDB na pgvector kila moja inahitaji kumbukumbu yake, na kwenye seva ya 4 GB hiyo ni kumbukumbu ambayo model ilihitaji.

Uboreshaji ni operesheni ya git, ambayo ndiyo sehemu watu hukosea.

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

git pull husimama na mgongano ikiwa umehariri docker-compose.yml inayofuatiliwa, na kisha uboreshaji hutumika nusu. Weka mabadiliko yako kwenye docker-compose.override.yml, ambayo mradi hutoa kwa ajili hii, na weka siri kwenye .env. Faili zote mbili hazifuatiliwi, kwa hivyo git pull haizigusi.

Elekeza LibreChat kwenye seva yako ya model yenye endpoint maalum katika 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"

Badilisha model-host na anwani ya seva inayoendesha Ollama. Sehemu ya apiKey lazima iwepo ingawa Ollama hupuuza thamani yake, kwa hivyo placeholder inafaa. Ikiwa LibreChat inaendeshwa ndani ya Docker na Ollama inaendeshwa kwenye mashine hiyo hiyo, localhost ndani ya container inamaanisha container yenyewe, kwa hivyo tumia host.docker.internal hapo badala yake.

Hollama na OrionChat: kivinjari hufanya kazi

Hollama hutoa programu ya kivinjari kutoka kwenye container moja ndogo. Mazungumzo huhifadhiwa kwenye hifadhi ya kivinjari chako, si kwenye seva.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

Toleo la README la amri hii linatumia --rm, ambalo hufuta container inapozimwa, hivyo kiolesura hakirudi baada ya reboot. Nyuma ya reverse proxy, ongeza -e VITE_ALLOWED_HOSTS='chat.example.com', kwa sababu image hiyo inaruhusu host localhost pekee na hujibu ombi la hostname nyingine yoyote kwa hitilafu ya blocked-host badala ya programu.

OrionChat huenda mbali zaidi na haina sehemu yoyote ya seva. Clone repository hiyo na utoe folda hiyo kwa kutumia web server unayoiendesha tayari, au fungua index.html kutoka kwenye diski. API keys huhifadhiwa kwenye localStorage ya kivinjari, historia ya mazungumzo hubaki kwenye kivinjari, na programu hufuta mazungumzo ya zamani zaidi pindi idadi inapozidi 512.

Miradi yote miwili haina login, kwa sababu hakuna seva inayoweza kuhakiki login. Kwenye laptop hiyo ni sawa. Kwenye VPS inamaanisha ukurasa haupaswi kamwe kuchapishwa kwenye 0.0.0.0, na inamaanisha jambo ambalo ni rahisi kulisahau: kivinjari ndicho kinachopiga simu kwenye model, si seva.

Ukweli huo mmoja huamua mahali ambapo miradi hii miwili inaweza kutumika. Kivinjari chako lazima kifike Ollama moja kwa moja, kwa hivyo Ollama lazima isikilize kwenye mtandao zaidi ya loopback, na Ollama haina uthibitishaji wa aina yoyote. Sheria mbili za kivinjari hufuata kutoka hapo. Ukurasa unaotolewa kupitia HTTPS hauwezi kupiga simu kwenye endpoint ya HTTP ya kawaida, na console huchapisha 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.. Simu yoyote kwa origin nyingine hukataliwa na has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource hadi utakapoiruhusu origin hiyo.

Njia iliyoandikwa ya Ollama ya kubadilisha mpangilio wowote kati ya hiyo ni 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 sasa inapaswa kuchapisha 0.0.0.0:11434 ambapo ilichapisha 127.0.0.1:11434 hapo awali. Fanya mabadiliko hayo tu wakati firewall au proxy inayohakiki mtumiaji inadhibiti nani anayeweza kufikia port hiyo, kwa sababu port 11434 iliyo wazi ni seva ya model iliyo wazi na skana za umma hufikia port mpya ya umma haraka. SSH tunnel iliyo hapa chini huepuka swali zima: ukurasa huo basi huendeshwa kwenye origin ya localhost, ambayo Ollama huiruhusu kwa chaguo-msingi, na port hiyo haitoki kamwe nje ya seva.

Je, kila moja inaweza kutumia endpoint ya mbali ya Ollama au vLLM

Open WebUI inaweza, na muunganisho hufanyika upande wa seva. OLLAMA_BASE_URL=http://model-host:11434 huielekeza kwenye Ollama. Kwa vLLM au seva nyingine yoyote inayooana na OpenAI, weka OPENAI_API_BASE_URL=http://model-host:8000/v1 ikiwa na OPENAI_API_KEY isiyo tupu, na uweke suffix ya /v1, ambayo ni lazima. OPENAI_API_BASE_URLS hukubali backend kadhaa zilizotenganishwa na semicolons.

LibreChat inaweza, kupitia baseURL ya endpoint maalum iliyoonyeshwa hapo juu. Ombi hilo pia hutoka kwenye seva, kwa hivyo hakuna sheria ya kivinjari inayotumika. URL ya msingi ileile na ufunguo uleule wa kishika nafasi hufanya kazi nje ya dirisha la gumzo pia, jambo ambalo ndilo linalohitajika ili kuelekeza wakala wa usimbaji kwenye modeli unayoiendesha tayari.

Hollama na OrionChat zinaweza kuelekeza kwenye endpoint yoyote unayoiandika kwenye mipangilio yao, lakini ombi hutoka kwenye kivinjari chako. Kila kitu katika sehemu iliyo hapo juu kinatumika kwao na si kwa kitu kingine chochote hapa.

Kutenganisha kiolesura na modeli ndilo jambo la manufaa zaidi unalopata kutoka kwa endpoint ya mbali. Weka kiolesura kwenye mashine ndogo na modeli mahali penye kumbukumbu ya kutosha. Hiyo pia ndiyo hatua ya kuamua kama Ollama au vLLM inapaswa kuhudumia maombi hayo, kwa sababu hizo mbili hufanya kazi kwa njia tofauti sana mara watu kadhaa wanapozungumza na modeli kwa wakati mmoja. Ikiwa seva ya modeli haipo bado, anza kwa kuendesha Ollama kwenye VPS, na kwenye mashine ya CPU pekee soma jinsi Ollama inavyolinganishwa na llama.cpp kabla ya kuchagua kiongozi (runner).

Usiwahi kuchapisha chat UI bila login kwenye 0.0.0.0

Ukurasa wa hardening wa Open WebUI unasema mradi huu "umejengwa kwa ajili ya mitandao ya kibinafsi na inayoaminika, sawa na miundombinu mingine ya self-hosted kama database, container registries, na CI servers", na unakushauri kuiweka nyuma ya VPN au nyuma ya reverse proxy yenye authentication. Mradi usio na login yoyote unastahili angalau hatua hiyo hiyo.

Kagua kinachosikiliza (listening) kabla ya kukiamini.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

Mstari unaosomeka 127.0.0.1:3000 ndio unaotakiwa. Mstari unaosomeka 0.0.0.0:3000 unamaanisha interface yako ya chat iko kwenye mtandao wa umma. Kutoka kwenye mashine yako mwenyewe, curl -sI http://YOUR.VPS.IP:3000 inayojibu HTTP/1.1 200 OK inasema jambo hilo hilo kwa uwazi zaidi.

Kuzima login ya Open WebUI kwa WEBUI_AUTH=False ni mpangilio wa mtumiaji mmoja kwa ajili ya mashine ambayo hakuna mtu mwingine anayeweza kuifikia. Pia inakataa kutumika kwenye usakinishaji ambao tayari una akaunti, kwa ujumbe You can't turn off authentication because there are existing users.

Muundo wa kwanza: funga kwenye loopback na uifikie kupitia SSH. Chapisha kila port kwenye 127.0.0.1, kisha forward unachohitaji: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, na ufungue http://localhost:3000 kwenye laptop yako. Hakuna kinachochapishwa, kwa hivyo hakuna kinachoweza kuchunguzwa (scanned). Kwa Hollama au OrionChat, forward port ya model kwa amri hiyo hiyo na -L 11434:127.0.0.1:11434 na uache Ollama kwenye loopback. Muundo huu una nguvu kulingana na usanidi wako wa SSH, kwa hivyo uunganishe na key-only SSH na sshd iliyoimarishwa.

Muundo wa pili: reverse proxy inayothibitisha utambulisho kabla ya programu kuona ombi. Iweke programu kwenye loopback, acha proxy imiliki port 443, na uweke single sign-on mbele. Traefik inayoendeshwa na Docker Compose labels pamoja na Authentik kama mtoa utambulisho huipa kila programu kwenye seva login moja na cheti kimoja. Open WebUI ikiwa nyuma ya TLS (transport layer security), weka WEBUI_SESSION_COOKIE_SECURE=true na WEBUI_SESSION_COOKIE_SAME_SITE=strict. Fupisha JWT_EXPIRES_IN kutoka muda wake wa kawaida wa wiki nne, kwa sababu Open WebUI inaeleza kuwa bila Redis, kutoka (sign-out) hakufuti uhalali wa token: inabaki kutumika hadi itakapomaliza muda wake yenyewe.

Muundo wa pili hausaidii miradi ya browser pekee. Proxy iliyo mbele ya ukurasa haikulindi endpoint ya model, na fetch kutoka ukurasa huo kwenda hostname tofauti haibebi session cookie yako, kwa hivyo proxy inayothibitisha utambulisho mbele ya Ollama inajibu kwa redirect kwenda kwenye fomu ya login na chat inafeli. Aidha elekeza endpoint ya model chini ya hostname moja na ukurasa, au tumia muundo wa kwanza.

Chagua ipi

Ikiwa kuna mtu mwingine yeyote isipokuwa wewe atakayeitumia, endesha Open WebUI. Ina akaunti halisi, watumiaji wapya huingia kwenye foleni ya idhini, na watunza programu hiyo huchapisha mwongozo wa kuimarisha usalama (hardening) ambao unaweza kuufuata. Ikiwa unahitaji LDAP au paneli ya usimamizi, endesha LibreChat, na uthibitishe kwa docker stats kama huduma zake sita pamoja na modeli yako zinatoshea kikweli kabla ya kuitegemea. Ikiwa ni mtu mmoja kwenye seva ndogo ambapo modeli imetumia sehemu kubwa ya RAM, tumia Hollama au OrionChat kupitia SSH tunnel na uache kivinjari kihifadhi hali ya matumizi (state). Jibu lisilo sahihi kwenye VPS ni yoyote kati ya hizo kuchapishwa kwenye 0.0.0.0 bila kuweka login mbele yake.

FAQ

Je, ni salama kuweka Open WebUI moja kwa moja kwenye IP ya umma?

Ukurasa wake wa usalama unaielezea kama programu ya mitandao ya kibinafsi inayotegemewa, ikiwa katika kundi moja na database au seva ya CI. Ina akaunti halisi, na akaunti ya kwanza huwa ya msimamizi (administrator) wakati zile zinazofuata hubaki pending hadi zikubaliwe, kwa hivyo ni salama zaidi kuliko UI isiyo na mfumo wa kuingia. Hata hivyo, iweke nyuma ya reverse proxy yenye TLS na, inapowezekana, tumia single sign-on. Chapisha port ya container kama 127.0.0.1:3000:8080 ili sheria za iptables za Docker zisiweze kuifungua kwa Internet bila wewe kujua.

Ni mbadala gani wa Open WebUI unaotumia RAM kidogo zaidi kwenye VPS?

Zile zinazotumia kivinjari (browser), kama Hollama na OrionChat, kwa sababu programu huendeshwa kwenye kifaa cha mtumiaji. Seva hutuma faili tuli pekee, na OrionChat haihitaji application container hata kidogo. Open WebUI huweka mchakato wa Python, database na, kwa chaguo-msingi, embedding model ya ndani kwenye kumbukumbu, ambayo huchukua takriban 500 MB kwa kila worker kwa ajili ya embedding model pekee. Thibitisha namba hizi kwenye seva yako mwenyewe kwa kutumia docker stats --no-stream, kwa sababu hubadilika kulingana na vipengele unavyowasha.

Je, hizi chat UI zinaweza kutumia seva ya Ollama iliyo kwenye host nyingine?

Open WebUI na LibreChat zinaweza, na seva zao ndizo hufanya muunganisho, kwa hivyo sheria za kivinjari hazitumiki. Weka OLLAMA_BASE_URL kwa ajili ya Open WebUI, au baseURL kwenye endpoint maalum kwa ajili ya LibreChat. Kwa vLLM au seva nyingine inayooana na OpenAI, tumia OPENAI_API_BASE_URL pamoja na kiambishi /v1 na API key isiyo tupu. Hollama na OrionChat pia zinaweza kuelekezwa popote, lakini ombi hutoka kwenye kivinjari chako, kwa hivyo endpoint lazima iweze kufikika kutoka kwenye kivinjari chako pia.

Kwa nini chat UI ya kivinjari changu haiwezi kufikia Ollama?

Sababu mbili hufunika karibu kila kisa. Ollama hufungwa kwenye 127.0.0.1:11434 kwa chaguo-msingi, kwa hivyo kivinjari kwenye mashine nyingine hakiwezi kuifikia hadi OLLAMA_HOST ibadilishwe. Na Ollama hukubali maombi ya cross-origin kutoka localhost pekee, kwa hivyo ukurasa unaotolewa kutoka domain yako mwenyewe hukataliwa kwa No 'Access-Control-Allow-Origin' header is present on the requested resource hadi origin hiyo iorodheshwe kwenye OLLAMA_ORIGINS. Ikiwa ukurasa ni HTTPS na endpoint ni HTTP, kivinjari huzuia ombi hilo kama mixed content kabla Ollama haijaliona. Weka vigezo vyote viwili kwenye override ya systemctl edit ollama.service, au peleka port kupitia SSH na tatizo litaisha.