Mbadala wa Open WebUI kwa VPS: Linganisha chaguo bora

Ni mbadala gani wa Open WebUI unaofaa kwenye VPS

Mbadala wa Open WebUI karibu kila mara hulinganishwa kwenye kompyuta ya mkononi, ambapo RAM ni ya bei nafuu na hakuna huduma inayolenga 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. Gharama 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 inapoweza kufikiwa kutoka kwenye Internet.

Mhimili minne inayozingatiwa kwenye IP ya umma

• Kumbukumbu karibu na model. Seva ya model ndiyo mchakato wa gharama kubwa kwenye mashine. Kila megabyte inayotumiwa na interface ni megabyte ambayo model haiwezi kutumia.
• Authentication. Baadhi ya miradi hii ina akaunti za watumiaji na majukumu. Mingine hudhani kuwa ndiyo kitu pekee kinachoendeshwa kwenye laptop yako, na haina login yoyote.
• 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 vector database nyuma yake.

Kiasi gani cha RAM ambacho modeli huachia kiolesura

Kiolesura si kitu kikubwa zaidi kwenye seva. Modeli ndiyo kubwa. Ukubwa wa upakuaji uliotangazwa unakupa msingi, kwa sababu uzito (weights) lazima uwe kwenye kumbukumbu wakati modeli inajibu, na matumizi halisi ya kumbukumbu ni makubwa kuliko saizi ya upakuaji pindi cache ya muktadha (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 ni takwimu zilizochapishwa kwenye kurasa za maktaba ya Ollama mnamo Agosti 2026. Ni saizi zilizochapishwa, si vipimo. 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 cache ya muktadha hula sehemu ya kumbukumbu hiyo kadiri mazungumzo yanavyokua. qwen3:8b yenye 5.2 GB haitoshi kwenye seva hiyo kabisa. Hii ni hali ambayo makala za mapitio ya kompyuta hazizungumzii, na hapa ndipo kiolesura cha gumzo kinachotumia mamia machache ya megabytes huamua kama modeli itaweza kufanya kazi. Ikiwa unapanga ukubwa wa seva kwa ajili ya kitu kikubwa zaidi ya lebo hizi, hesabu za modeli ya 27B kwenye VPS inayotumia CPU pekee zinaonyesha jinsi kiolesura kinavyoacha kuwa namba inayoamua chochote kwa haraka.

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.

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 pekee. 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 uzuiaji za ufw.

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 hutaja sehemu zinazotumia kumbukumbu hiyo. Injini ya embedding ya chaguo-msingi hupakia model ya sentence-transformers ndani ya container, ambayo imeandikwa kutumia 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 ukubwa mkubwa wa ndani na kila muunganisho hukua na page cache na memory map yake yenyewe, kwa hivyo kwenye mashine ndogo weka DATABASE_POOL_SIZE=8 na DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False huzuia interface kumuuliza model kukamilisha sentensi 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 chaguo la kuzingatia unapohitaji mfumo wa utambulisho badala ya kisanduku cha kuingia (login box) tu: ina nyaraka za LDAP na OAuth2 logins, na inakuja na paneli ya usimamizi kwa watumiaji na majukumu (roles). 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 chaguo-msingi la compose huanzisha 6 services: 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 (upgrades) 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 kuleta mgongano ikiwa umehariri docker-compose.yml inayofuatiliwa, na kisha uboreshaji hutekelezwa nusu. Weka mabadiliko yako kwenye docker-compose.override.yml, ambayo mradi huu hutoa kwa ajili hiyo, na weka siri (secrets) kwenye .env. Faili zote mbili hazifuatiliwi, kwa hivyo git pull haizigusi.

Elekeza LibreChat kwenye seva yako ya model kwa kutumia 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 ndicho kinachofanya 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 amri hii lililo kwenye README linatumia --rm, ambalo hufuta container inapozimwa, hivyo kiolesura hakirudi baada ya reboot. Ukiwa 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 kutoa hitilafu ya blocked-host badala ya programu.

OrionChat inaenda mbali zaidi na haina sehemu yoyote ya seva. Clone repository hiyo na uweke folda hiyo kwenye web server unayotumia 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 idadi ikizidi 512.

Miradi yote miwili haina mfumo wa kuingia (login), kwa sababu hakuna seva inayoweza kuhakiki mtumiaji. Kwenye laptop hilo ni sawa. Kwenye VPS inamaanisha ukurasa huo 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 ndio unaoamua mahali ambapo miradi hii miwili inaweza kutumika. Kivinjari chako lazima kifikie Ollama moja kwa moja, kwa hivyo Ollama lazima isikilize kwenye anwani 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 kwenye origin nyingine hukataliwa kwa has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource hadi utakapoiruhusu origin hiyo.

Njia iliyoandikwa kwenye nyaraka za Ollama ya kubadilisha mpangilio wowote kati ya hiyo ni kutumia 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 mahali ilipochapisha 127.0.0.1:11434 hapo awali. Fanya mabadiliko hayo tu wakati firewall au proxy inayohakiki watumiaji 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 inaepuka 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 ya 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 wa placeholder uleule hufanya kazi nje ya dirisha la gumzo pia, ambayo ndiyo yote inahitajika ili kuelekeza wakala wa usimbaji kwenye modeli unayohifadhi tayari.

Hollama na OrionChat zinaweza kuelekeza kwenye endpoint yoyote unayoiandika kwenye mipangilio yao, lakini ombi hilo 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 unalolipata 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).

Usichapishe kamwe kiolesura cha gumzo bila kuingia (login) kwenye 0.0.0.0

Ukurasa wa kuimarisha usalama (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 seva za CI", na unakushauri kuiweka nyuma ya VPN au nyuma ya reverse proxy yenye uthibitishaji (authentication). Mradi usio na mfumo wa kuingia hata kidogo unahitaji angalau hatua kama hiyo.

Kagua kile 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 kuwa kiolesura chako cha gumzo kiko kwenye Internet ya 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 mfumo wa kuingia wa Open WebUI kwa kutumia 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 fanya forwarding ya kile unachohitaji: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, na ufungue http://localhost:3000 kwenye laptop yako. Hakuna kinachochapishwa hadharani, kwa hivyo hakuna kinachoweza kuchunguzwa (scanned). Kwa Hollama au OrionChat, fanya forwarding ya 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 SSH ya ufunguo pekee na sshd iliyoimarishwa.

Muundo wa pili: reverse proxy inayothibitisha mtumiaji kabla ya programu kuona ombi. Iache programu kwenye loopback, acha proxy imiliki port 443, na uweke single sign-on mbele yake. Traefik inayoendeshwa na Docker Compose labels pamoja na Authentik kama mtoa utambulisho huipa kila programu kwenye seva hiyo kuingia mara 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 kivinjari pekee (browser-only). Proxy iliyo mbele ya ukurasa hailindi endpoint ya model, na ombi (fetch) kutoka ukurasa huo kwenda hostname tofauti halibebi cookie yako ya session, kwa hivyo proxy inayothibitisha iliyo mbele ya Ollama inajibu kwa kuelekeza kwenye fomu ya kuingia na gumzo linashindwa kufanya kazi. Aidha elekeza endpoint ya model chini ya hostname moja na ukurasa, au tumia muundo wa kwanza.

Ipi ya kuchagua

Ikiwa kuna mtu mwingine yeyote isipokuwa wewe atakayeitumia, endesha Open WebUI. Ina akaunti halisi, watumiaji wapya huwekwa 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 imeshatumia sehemu kubwa ya RAM, tumia Hollama au OrionChat kupitia SSH tunnel na uache kivinjari kishikilie hali (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 na inayoaminika, ikiwa katika kundi moja na database au seva ya CI. Ina akaunti halisi, na akaunti ya kwanza huwa ya msimamizi (administrator) huku akaunti nyingine zikibaki pending hadi zitakapoidhinishwa, kwa hivyo ni salama zaidi kuliko UI isiyo na mfumo wa kuingia. Hata hivyo, iweke nyuma ya reverse proxy yenye TLS na, ikiwezekana, tumia single sign-on. Chapisha port ya container kama 127.0.0.1:3000:8080 ili sheria za iptables za Docker zisifungue huduma hiyo kwenye Internet bila wewe kujua.

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

Zile zinazotegemea kivinjari (browser), kama Hollama na OrionChat, kwa sababu programu huendeshwa kwenye kifaa cha mtumiaji. Seva hutuma faili tuli pekee, na OrionChat haihitaji container ya programu hata kidogo. Open WebUI huendesha mchakato wa Python, database, na kwa kawaida, mfano wa embedding wa ndani kwenye kumbukumbu (memory), ambao umeandikwa kutumia takriban 500 MB kwa kila worker kwa ajili ya mfano wa embedding pekee. Thibitisha namba hizi kwenye seva yako kwa kutumia docker stats --no-stream, kwa sababu hubadilika kulingana na vipengele unavyowasha.

Je, UI hizi za chat 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 UI yangu ya chat kwenye kivinjari 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 itakapobadilishwa. Na Ollama hukubali maombi ya cross-origin kutoka localhost pekee, kwa hivyo ukurasa unaotolewa kutoka domain yako hukataliwa kwa No 'Access-Control-Allow-Origin' header is present on the requested resource hadi origin hiyo itakapoorodheshwa 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 hiyo kupitia SSH na tatizo litaisha.