Mga Alternatibo sa Open WebUI para sa VPS

Aling alternatibo sa Open WebUI ang angkop sa isang VPS

Halos palaging ikinukumpara ang mga alternatibo sa Open WebUI sa isang laptop, kung saan mura ang RAM at walang nakikinig sa public address. Nagbabago ang dalawang kundisyong ito sa isang VPS, kaya nagbabago rin ang pagkakasunod-sunod ng mga ito. Open WebUI pa rin ang tamang default kapag may ikalawang taong magla-log in, dahil mayroon itong totoong user accounts at admin panel. Nauungusan ng mas magagaan na project ang iba kapag nakikipag-agawan ang interface sa model para sa huling gigabyte ng RAM. Ang kapalit nito ay authentication: wala silang ganitong feature.

Ang lahat ng nasa ibaba ay batay sa sariling documentation ng bawat project, na binasa noong August 2026. Ang apat na pamantayan ay lumilitaw lamang kapag maa-access na ang server mula sa internet.

Apat na aspeto na mahalaga lamang kapag public IP

• Memory katabi ng model. Ang model server ang pinakamagastos na process sa server. Bawat megabyte na ginagamit ng interface ay megabyte na hindi magagamit ng model.
• Authentication. May user accounts at roles ang ilan sa mga project na ito. Ipinapalagay naman ng iba na sila lang ang tumatakbo sa iyong laptop, kaya wala silang login.
• Remote inference. Pinipilit ng UI na maa-access lamang ang 127.0.0.1:11434 na nasa parehong server ang model at interface.
• Maintenance. Ibang gawain ang isang container na may SQLite file kumpara sa anim na container na may MongoDB at vector database sa likod ng mga ito.

Gaano karaming RAM ang inilalaan ng model para sa interface

Hindi ang interface ang pinakamalaking kumokonsumo ng resources sa server. Ang model ang kumokonsumo nito. Ang mga published download size ang nagbibigay ng minimum na halaga, dahil kailangang manatili sa memory ang weights habang sumasagot ang model. Mas mataas ang aktuwal na memory use kaysa sa download size kapag nailaan na ang context cache.

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

Iyan ang mga figure na ipinakita ng Ollama library pages noong August 2026. Published sizes ang mga ito, hindi aktuwal na measurements. Sa isang 4 GB VPS, ang qwen3:4b na may 2.5 GB ay nag-iiwan ng wala pang 1.5 GB para sa operating system at lahat ng iba pa. Kumokonsumo rin ng karagdagang memory ang context cache habang humahaba ang conversation. Ang qwen3:8b na may 5.2 GB ay hindi talaga kasya sa server na iyon. Ito ang sitwasyong hindi tinatalakay sa mga laptop roundup, at dito makikita kung paano maaaring magpasya ang chat interface na kumokonsumo ng ilang daang megabytes kung tatakbo ang model. Kung nagse-size ka ng server para sa model na higit na malaki kaysa sa mga tag na ito, ipinapakita ng pagsusuri para sa 27B model sa CPU-only VPS kung gaano kabilis tumigil ang interface na maging pangunahing salik.

Magsagawa ng measurement sa halip na umasa sa anumang number sa isang roundup, kabilang na ang isang ito. Patakbuhin ang docker stats --no-stream isang oras matapos gamitin nang aktuwal, hindi isang minuto matapos magsimula ang container, dahil sa unang paggamit inilalaan ang memory na mahalaga sa measurement.

Open WebUI: default pa rin para sa higit sa isang user

Tumatakbo ang Open WebUI mula sa isang image at inilalagay ang data nito sa isang volume.

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

Ipinapublish ng command sa project README ang -p 3000:8080, na nakikinig sa lahat ng interface. Pinananatili ito ng prefix na 127.0.0.1: sa loopback. Sa isang VPS, mas mahalaga ang prefix na ito kaysa sa iba pang bahagi ng linya, dahil ang Docker mismo ang nagsusulat ng sarili nitong iptables rules at binabalewala ng published port ang deny rules ng ufw.

Puntahan ang page sa pamamagitan ng tunnel o proxy, na parehong inilalarawan sa ibaba, at gawin ang unang account. Magiging administrator ang account na iyon. Ang mga susunod na signup ay ginagawa gamit ang role na pending, ang dokumentadong default ng DEFAULT_USER_ROLE, kaya hindi magagamit ng estrangherong makakaabot sa page ang model mo hangga't hindi siya inaaprubahan ng admin.

Mas maraming memory ang ginagamit ng Open WebUI kaysa sa mga project sa ibaba dahil mas marami itong ginagawa. Tinutukoy sa sarili nitong performance page ang mga bahaging kumokonsumo nito ng resources. Nilo-load ng default embedding engine ang isang sentence-transformers model sa loob ng container, at ayon sa documentation, humigit-kumulang 500 MB ito bawat worker process. Ipinapasa ng pagtatakda ng RAG_EMBEDDING_ENGINE=ollama ang trabahong ito sa model server na pinapatakbo mo na. Pinipigilan ng AUDIO_STT_ENGINE=webapi ang pag-load ng lokal na speech-to-text model. Kapag SQLite ang ginagamit at hindi nakatakda ang DATABASE_POOL_SIZE, bumabalik ang pool sa malaking internal size at lumalaki ang sariling page cache at memory map ng bawat connection. Kaya, sa maliit na server, itakda ang DATABASE_POOL_SIZE=8 at DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. Pinipigilan ng ENABLE_AUTOCOMPLETE_GENERATION=False ang interface na humingi ng completion sa model habang nagta-type pa ang user.

LibreChat: multi-user, na may stack sa likod nito

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

Sumasagot ang interface sa port 3080. Ang LibreChat ang dapat piliin kapag kailangan mo ng identity system sa halip na simpleng login box. Idinodokumento nito ang LDAP at OAuth2 login, at may kasama itong admin panel para sa mga user at role. Kasama sa capability na ito ang isang 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"
  }
]

Ang default compose file ay nagsisimula ng 6 services: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Wala sa mga ito ang model. Kailangan ng MongoDB at pgvector ng sarili nilang memory, at sa isang 4 GB na server, ang memory na iyon ay kailangan din ng model.

Git operation ang proseso ng upgrade, at dito madalas nagkakamali ang mga user.

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

Humihinto ang git pull na may conflict kapag inedit mo ang tracked na docker-compose.yml, kaya kalahati lamang ang naia-apply na upgrade. Ilagay ang mga pagbabago mo sa docker-compose.override.yml, na inilaan ng project para rito, at itago ang mga secret sa .env. Untracked ang dalawang file, kaya hindi sila gagalawin ng git pull.

Ituro ang LibreChat sa sarili mong model server gamit ang custom endpoint sa 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"

Palitan ang model-host ng address ng server na nagpapatakbo ng Ollama. Kailangang naroon ang field na apiKey kahit binabalewala ng Ollama ang value nito, kaya sapat na ang placeholder. Kung tumatakbo ang LibreChat sa Docker at ang Ollama ay tumatakbo sa parehong machine, ang localhost sa loob ng container ay tumutukoy sa container mismo, kaya gamitin ang host.docker.internal doon sa halip.

Hollama at OrionChat: browser ang gumagawa

Nagsisilbi ang Hollama ng browser application mula sa isang maliit na container. Nasa storage ng browser ang mga chat, hindi sa server.

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

Ginagamit ng bersyon sa README ng command na ito ang --rm, na nagde-delete ng container kapag huminto ito. Dahil dito, hindi na bumabalik ang interface pagkatapos ng reboot. Kapag nasa likod ito ng reverse proxy, idagdag ang -e VITE_ALLOWED_HOSTS='chat.example.com', dahil host na localhost lamang ang pinapayagan ng image. Sa request na ibang hostname, nagbabalik ito ng blocked-host error sa halip na buksan ang app.

Mas limitado pa ang server component ng OrionChat: wala talaga itong server component. I-clone ang repository at i-serve ang folder gamit ang web server na tumatakbo na, o buksan ang index.html mula sa disk. Naka-store ang API keys sa localStorage ng browser, nananatili sa browser ang chat history, at dine-delete ng app ang pinakamatatandang chat kapag lumampas sa 512 ang bilang.

Walang login ang alinmang project, dahil walang server ang alinman sa mga ito na maaaring mag-check nito. Ayos ito sa laptop. Sa VPS, nangangahulugan itong hindi dapat kailanman i-publish ang page sa 0.0.0.0. May isa pang madaling makaligtaang punto: ang browser ang tumatawag sa model, hindi ang server.

Dahil dito, natutukoy kung saan magagamit ang dalawang ito. Kailangang direktang maabot ng browser mo ang Ollama. Kaya dapat makinig ang Ollama sa higit pa sa loopback, at wala itong anumang authentication. Dalawang browser rule ang sumusunod dito. Hindi maaaring tumawag ang page na naka-serve sa HTTPS sa plain HTTP endpoint. Ipinapakita ng console ang 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.. Tinatanggihan ang call sa anumang ibang origin gamit ang has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource hanggang sa payagan mo ang origin na iyon.

Ang documented na paraan ng Ollama para baguhin ang alinman sa dalawang setting ay 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

Dapat mag-print ngayon ang ss ng 0.0.0.0:11434, kung saan dati itong nag-print ng 127.0.0.1:11434. Gawin lamang ang pagbabagong ito kapag may firewall o authenticating proxy na kumokontrol kung sino ang maaaring makaabot sa port. Ang bukas na 11434 ay bukas na model server, at mabilis na naaabot ng mass scanner ang bagong public port. Iniiwasan ng SSH tunnel sa ibaba ang buong isyung ito: tumatakbo ang page sa localhost origin, na pinapayagan ng Ollama bilang default, at hindi lumalabas sa machine ang port.

Maaari bang gumamit ang bawat isa ng remote Ollama o vLLM endpoint

Magagawa ito ng Open WebUI, at server side ginagawa ang connection. Tinuturo ito ng OLLAMA_BASE_URL=http://model-host:11434 sa Ollama. Para sa vLLM o anumang server na compatible sa OpenAI, itakda ang OPENAI_API_BASE_URL=http://model-host:8000/v1 na may hindi bakanteng OPENAI_API_KEY, at panatilihin ang suffix na /v1, dahil required ito. Tumatanggap ang OPENAI_API_BASE_URLS ng ilang backend na pinaghihiwalay ng semicolon.

Magagawa rin ito ng LibreChat sa pamamagitan ng baseURL ng custom endpoint na ipinakita sa itaas. Lumalabas din sa server ang request na iyon, kaya walang browser rule na nalalapat. Gumagana rin ang parehong base URL at parehong placeholder key sa labas ng chat window, kaya sapat na ito para ituro ang coding agent sa model na naka-host mo na.

Maaaring ituro ng Hollama at OrionChat ang anumang endpoint na ilalagay mo sa kanilang settings, pero lumalabas sa browser ang request. Nalalapat sa mga ito ang lahat ng nasa seksyon sa itaas, at wala nang iba rito.

Ang paghihiwalay ng interface at model ang pinakamahalagang pakinabang ng remote endpoint. Ilagay ang interface sa maliit na box at ang model sa machine na may sapat na memory. Dito rin dapat magpasya kung Ollama o vLLM ang dapat mag-serve ng mga request, dahil magkaiba nang malaki ang behavior ng dalawa kapag sabay-sabay na gumagamit ng model ang maraming tao. Kung wala pa ang model server, magsimula sa pagpapatakbo ng Ollama sa isang VPS, at kung CPU-only ang box, basahin muna kung paano inihahambing ang Ollama sa llama.cpp bago pumili ng runner.

Huwag mag-publish ng chat UI na walang login sa 0.0.0.0

Sinasabi sa hardening page ng Open WebUI na ang proyekto ay “binuo para sa private at trusted network, gaya ng iba pang self-hosted infrastructure tulad ng database, container registry, at CI server,” at inirerekomenda nitong ilagay ito sa likod ng VPN o reverse proxy na may authentication. Ang proyektong walang login ay dapat tratuhin nang hindi bababa sa ganito.

Suriin muna kung ano ang nakikinig bago mo pagkatiwalaan ang alinman dito.

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

Ang linyang 127.0.0.1:3000 ang kailangan mo. Ang linyang 0.0.0.0:3000 ay nangangahulugang nasa public internet ang chat interface mo. Mula sa sarili mong machine, mas tahasang ipinapakita ng pagsagot ng curl -sI http://YOUR.VPS.IP:3000 sa HTTP/1.1 200 OK ang parehong sitwasyon.

Ang pag-off ng login ng Open WebUI gamit ang WEBUI_AUTH=False ay setting para sa iisang user sa machine na walang ibang makaka-access. Hindi rin ito gumagana sa installation na mayroon nang mga account. Ipinapakita nito ang mensaheng You can't turn off authentication because there are existing users.

Pattern one: mag-bind sa loopback at i-access gamit ang SSH. I-publish ang bawat port sa 127.0.0.1, pagkatapos ay i-forward ang kailangan mo: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, at buksan ang http://localhost:3000 sa laptop mo. Walang na-publish, kaya walang maaaring i-scan. Para sa Hollama o OrionChat, i-forward ang model port sa parehong command gamit ang -L 11434:127.0.0.1:11434 at iwan ang Ollama sa loopback. Kasinglakas lamang ng SSH setup mo ang pattern na ito, kaya ipares ito sa SSH na key-only at pinatibay na sshd.

Pattern two: reverse proxy na nagsasagawa ng authentication bago makita ng app ang request. Panatilihin ang app sa loopback, ipaubaya sa proxy ang port 443, at ilagay ang single sign-on sa unahan nito. Ang Traefik na pinapatakbo gamit ang Docker Compose labels kasama ang Authentik bilang identity provider ay nagbibigay sa bawat app sa machine ng iisang login at iisang certificate. Kapag nasa likod ng TLS (transport layer security) ang Open WebUI, itakda ang WEBUI_SESSION_COOKIE_SECURE=true at WEBUI_SESSION_COOKIE_SAME_SITE=strict. Paikliin din ang JWT_EXPIRES_IN mula sa default na apat na linggo, dahil nakadokumento sa Open WebUI na kapag walang Redis, hindi napapawalang-bisa ng pag-sign out ang token: magagamit pa rin ito hanggang sa awtomatiko itong mag-expire.

Hindi nalulutas ng pattern two ang mga proyektong browser-only. Hindi pinoprotektahan ng proxy sa harap ng page ang model endpoint. Hindi rin ipinapadala ng fetch mula sa page patungo sa ibang hostname ang session cookie mo. Dahil dito, sasagot ang authenticating proxy sa harap ng Ollama ng redirect patungo sa login form at mabibigo ang chat. I-route ang model endpoint sa ilalim ng parehong hostname ng page, o gamitin ang pattern one.

Alin ang pipiliin

Kung may ibang gagamit nito bukod sa iyo, gamitin ang Open WebUI. May mga aktuwal itong account, inilalagay ang mga bagong user sa approval queue, at naglalathala ang mga maintainer nito ng hardening guidance na maaari mong sundin. Kung kailangan mo ng LDAP o admin panel, gamitin ang LibreChat, at tiyaking tugma ang anim nitong service kasama ang iyong model gamit ang docker stats bago ka umasa rito. Kung iisang tao lang ang gagamit sa maliit na server at halos lahat ng RAM ay ginagamit na ng model, i-serve ang Hollama o OrionChat sa pamamagitan ng SSH tunnel at hayaan ang browser na magpanatili ng state. Ang maling setup sa isang VPS ay ang pag-publish ng alinman sa mga ito sa 0.0.0.0 nang walang login sa harap nito.

FAQ

Ligtas bang direktang i-expose ang Open WebUI sa public IP?

Inilalarawan ito ng sarili nitong hardening page bilang software para sa private at trusted network, kapareho ng database o CI server. May aktuwal itong mga account, at nagiging administrator ang unang account habang nananatiling pending ang mga kasunod hanggang ma-approve, kaya mas ligtas ito kaysa sa UI na walang login. Gayunman, ilagay pa rin ito sa likod ng reverse proxy na may TLS at, kung maaari, single sign-on. I-publish ang container port bilang 127.0.0.1:3000:8080 upang hindi ito mabuksan ng sariling iptables rules ng Docker sa internet nang hindi mo nalalaman.

Aling Open WebUI alternative ang gumagamit ng pinakamaliit na RAM sa VPS?

Ang mga browser-based na option, gaya ng Hollama at OrionChat, dahil tumatakbo ang application sa client. Static files lamang ang ipinapadala ng server, at hindi na kailangan ng OrionChat ng application container. Gumagamit ang Open WebUI ng Python process, database, at bilang default, local embedding model sa memory; nakadokumento ito na humigit-kumulang 500 MB bawat worker para sa embedding model lamang. I-confirm ang mga numerong ito sa sarili mong server gamit ang docker stats --no-stream, dahil nagbabago ang mga ito batay sa mga feature na naka-enable.

Magagamit ba ng mga chat UI na ito ang Ollama server sa ibang host?

Magagamit ito ng Open WebUI at LibreChat, at ang server nila ang kumokonekta, kaya walang browser rule na nalalapat. I-set ang OLLAMA_BASE_URL para sa Open WebUI, o ang baseURL sa custom endpoint para sa LibreChat. Para sa vLLM o ibang OpenAI-compatible server, gamitin ang OPENAI_API_BASE_URL kasama ang /v1 suffix at non-empty na API key. Maaari ring ituro ng Hollama at OrionChat ang koneksyon sa kahit anong address, ngunit mula sa browser mo nanggagaling ang request, kaya dapat reachable mula sa browser mo ang endpoint.

Bakit hindi maabot ng browser chat UI ko ang Ollama?

Dalawang sanhi ang sumasaklaw sa halos lahat ng kaso. Bilang default, nagbi-bind ang Ollama sa 127.0.0.1:11434, kaya hindi ito maaabot ng browser sa ibang machine hangga't hindi nagbabago ang OLLAMA_HOST. Tumatanggap din ang Ollama ng cross-origin request mula lamang sa localhost, kaya tatanggihan ang page na naka-serve mula sa sarili mong domain na may No 'Access-Control-Allow-Origin' header is present on the requested resource hangga't hindi nakalista ang origin na iyon sa OLLAMA_ORIGINS. Kung HTTPS ang page at HTTP ang endpoint, bina-block ng browser ang call bilang mixed content bago pa ito makita ng Ollama. I-set ang dalawang variable sa isang systemctl edit ollama.service override, o i-forward ang port gamit ang SSH upang mawala ang problemang ito.