Pinakamagandang Open WebUI alternatives para sa VPS

Aling alternatibo sa Open WebUI ang dapat ilagay sa isang VPS

Ang mga alternatibo sa Open WebUI ay halos palaging ikinukumpara sa laptop, kung saan mura ang RAM at walang nakikinig sa public address. Binabago ng VPS ang dalawang katotohanang ito, at binabago rin nito ang ranking. Ang Open WebUI ang nananatiling tamang default sa sandaling may pangalawang tao na mag-log in, dahil mayroon itong mga totoong user account at admin panel. Ang mga mas magaan na proyekto ang nananalo kapag ang interface ay nakikipag-agawan sa model para sa huling gigabyte ng RAM. Ang kapalit ng panalong ito ay authentication: wala silang ganito.

Ang lahat ng nasa ibaba ay nagmula sa sariling dokumentasyon ng bawat proyekto, na binasa noong Agosto 2026. Ang apat na axis ay ang mga lumalabas lamang kapag ang server ay maaari nang ma-access mula sa internet.

Apat na aspeto na mahalaga lang sa public IP

• Memory na malapit sa model. Ang model server ang pinakamahal na proseso sa loob ng box. Bawat megabyte na kinakain ng interface ay megabyte na hindi magagamit ng model.
• Authentication. Ang ilang proyekto ay may user account at roles. Ang iba naman ay nag-aakalang sila lang ang tumatakbo sa iyong laptop, kaya wala silang login.
• Remote inference. Ang UI na makakaabot lang sa 127.0.0.1:11434 ay nagpipilit na ilagay ang model sa parehong box kung nasaan ang interface.
• Upkeep. Ang isang container na may SQLite file ay ibang trabaho kumpara sa anim na container na may MongoDB at vector database sa likod nito.

Gaano karaming RAM ang natitira para sa interface

Hindi ang interface ang pinakamalaking kumakain ng resources sa server. Ang model ang siyang pinakamalaki. Ang mga published download size ay nagsisilbing baseline lamang, dahil kailangang manatili ang mga weight sa memory habang sumasagot ang model, at mas mataas ang aktwal na memory usage kaysa sa download size kapag na-allocate 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 nakasaad sa mga pahina ng Ollama library noong Agosto 2026. Ang mga ito ay published sizes at hindi mga aktuwal na sukat. Sa isang 4 GB VPS, ang qwen3:4b na may 2.5 GB ay nag-iiwan ng kulang sa 1.5 GB para sa operating system at iba pang proseso, at kinakain din ito ng context cache habang humahaba ang usapan. Ito ang dahilan kung bakit ang num_ctx na itinakda mo ay isang desisyon sa memory gaya ng pagpili sa kalidad. Ang qwen3:8b na may 5.2 GB ay hindi kakasya sa server na iyon. Ito ang sitwasyong hindi tinatalakay sa mga laptop roundup, at dito nagdedesisyon ang isang chat interface na kumakain ng ilang daang megabytes kung tatakbo ang model o hindi. Kung nagpaplano ka ng server para sa mga model na mas malaki sa mga ito, ipinapakita ng arithmetic para sa isang 27B model sa isang CPU-only VPS kung gaano kabilis mawalan ng saysay ang interface bilang basehan ng memory usage.

Mas mainam na mag-measure kaysa magtiwala sa anumang numero sa mga roundup, kabilang ang isang ito. Patakbuhin ang docker stats --no-stream pagkalipas ng isang oras ng totoong paggamit, hindi isang minuto matapos mag-start ang container, dahil ang memory na mahalaga ay na-a-allocate sa unang paggamit. Inilalabas din ng Ollama ang mga weight pagkalipas ng limang minutong idle time, kaya ang reading na kinuha sa pagitan ng mga usapan ay hindi nagpapakita ng peak usage, at ang susunod na mensahe ay muling magpapasan ng buong load maliban kung pananatilihin mong resident ang model gamit ang keep_alive.

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

Ang Open WebUI ay tumatakbo mula sa iisang image at iniimbak ang data nito sa iisang 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

Ang command sa README ng proyekto ay nag-pu-publish ng -p 3000:8080, na nakikinig sa bawat interface. Ang prefix na 127.0.0.1: ay nagpapanatili rito sa loopback. Sa isang VPS, mas mahalaga ang prefix na iyon kaysa sa kahit ano pa man sa linya, dahil nagsusulat ang Docker ng sarili nitong iptables rules at ang published port ay binabalewala ang iyong ufw deny rules.

Ma-a-access ang page sa pamamagitan ng tunnel o proxy, na parehong nakadetalye sa ibaba, pagkatapos ay gawin ang unang account. Ang account na iyon ang magiging administrator. Ang mga susunod na signup ay gagawin na may role na pending, ang dokumentadong default ng DEFAULT_USER_ROLE, kaya ang isang estranghero na makaka-access sa page ay hindi pa rin magagamit ang iyong model hangga't hindi sila ina-approve ng admin.

Mas malakas kumain ng memory ang Open WebUI kaysa sa mga proyekto sa ibaba dahil mas marami itong ginagawa, at ang sarili nitong performance page ang nagtutukoy sa mga bahaging kumakain nito. Ang default embedding engine ay naglo-load ng sentence-transformers model sa loob ng container, na dokumentadong nasa 500 MB bawat worker process. Ang pag-set ng RAG_EMBEDDING_ENGINE=ollama ay naglilipat ng trabahong iyon sa model server na pinapatakbo mo na. Iniiwasan ng AUDIO_STT_ENGINE=webapi ang pag-load ng local speech-to-text model. Sa SQLite na may unset na DATABASE_POOL_SIZE, ang pool ay bumabalik sa malaking internal size at ang bawat connection ay nagpapalaki ng sarili nitong page cache at memory map, kaya sa maliliit na box, i-set ang DATABASE_POOL_SIZE=8 at DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. Pinipigilan ng ENABLE_AUTOCOMPLETE_GENERATION=False ang interface sa paghingi 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

Ang interface ay tumutugon sa port 3080. Ang LibreChat ang dapat mong tingnan kung kailangan mo ng identity system sa halip na simpleng login box: dokumentado rito ang LDAP at OAuth2 logins, at may kasama itong admin panel para sa mga user at role. Ang kakayahang iyon ay dumarating kasama ng 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 nagpapatakbo ng 6 na serbisyo: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Wala sa mga ito ang mismong model. Ang MongoDB at pgvector ay parehong nangangailangan ng sariling memory, at sa isang 4 GB na box, ito ang memory na kailangan sana ng model.

Ang mga upgrade ay isang git operation, at ito ang bahaging madalas magkamali ang mga tao.

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

Ang git pull ay humihinto nang may conflict kung in-edit mo ang tracked na docker-compose.yml, at magreresulta ito sa hindi kumpletong upgrade. Ilagay ang iyong mga pagbabago sa docker-compose.override.yml, na ibinigay ng project para sa layuning ito, at panatilihin ang mga secret sa .env. Ang parehong file ay untracked, 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 box kung saan tumatakbo ang Ollama. Ang field na apiKey ay dapat naroon kahit na binabalewala ng Ollama ang value nito, kaya ayos lang ang isang placeholder. Kung ang LibreChat ay tumatakbo sa Docker at ang Ollama ay nasa parehong machine, ang localhost sa loob ng container ay nangangahulugang ang container mismo, kaya gamitin ang host.docker.internal sa halip.

Hollama at OrionChat: ang browser ang gumagawa ng trabaho

Ang Hollama ay nagse-serve ng browser application mula sa isang maliit na container. Ang mga chat ay nakaimbak sa storage ng iyong browser, hindi sa server.

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

Ang bersyon ng command na ito sa README ay gumagamit ng --rm, na nagbubura sa container kapag ito ay huminto, kaya hindi na babalik ang interface pagkatapos ng reboot. Sa likod ng isang reverse proxy, magdagdag ng -e VITE_ALLOWED_HOSTS='chat.example.com', dahil ang image ay nagpapahintulot lamang sa host na localhost at sumasagot sa request para sa anumang ibang hostname gamit ang blocked-host error sa halip na ipakita ang app.

Ang OrionChat ay mas malayo ang nararating at wala itong server component. I-clone ang repository at i-serve ang folder gamit ang web server na ginagamit mo na, o buksan ang index.html mula sa disk. Ang mga API key ay nakaimbak sa localStorage ng browser, ang chat history ay nananatili sa browser, at binubura ng app ang pinakamatandang mga chat kapag lumampas na ang bilang sa 512.

Walang login ang alinman sa mga proyektong ito, dahil wala silang server na makakapag-verify nito. Sa isang laptop, ayos lang ito. Sa isang VPS, nangangahulugan ito na hindi dapat i-publish ang page sa 0.0.0.0, at may isang bagay na madaling makaligtaan: ang browser ang tumatawag sa model, hindi ang server.

Ang katotohanang iyon ang nagtatakda kung saan magagamit ang dalawang ito. Kailangang maabot ng iyong browser ang Ollama nang direkta, kaya kailangang makinig ang Ollama sa higit pa sa loopback, at ang Ollama ay walang anumang uri ng authentication. Dalawang panuntunan sa browser ang sumusunod dito. Ang isang page na served sa HTTPS ay hindi maaaring tumawag sa isang plain HTTP endpoint, at ang console ay magpi-print ng 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.. Ang anumang tawag sa ibang origin ay tinatanggihan 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 dokumentadong paraan ng Ollama para baguhin ang alinman sa mga setting na ito ay sa pamamagitan ng 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 nang i-print ng ss ang 0.0.0.0:11434 kung saan 127.0.0.1:11434 ang na-print nito dati. Gawin lamang ang pagbabagong ito kung may firewall o authenticating proxy na kumokontrol kung sino ang makakaabot sa port, dahil ang isang bukas na 11434 ay isang bukas na model server at mabilis na naaabot ng mga mass scanner ang isang bagong public port. Iniiwasan ng SSH tunnel sa ibaba ang buong isyung ito: ang page ay tatakbo sa isang localhost origin, na pinapayagan ng Ollama bilang default, at ang port ay hindi kailanman lalabas sa box.

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

Ang Open WebUI ay may kakayahang gawin ito, at ang koneksyon ay ginagawa sa server side. Itinuturo ito ng OLLAMA_BASE_URL=http://model-host:11434 sa Ollama. Para sa vLLM o anumang server na compatible sa OpenAI, i-set ang OPENAI_API_BASE_URL=http://model-host:8000/v1 gamit ang hindi bakanteng OPENAI_API_KEY, at panatilihin ang /v1 suffix, dahil kailangan ito. Tumatanggap ang OPENAI_API_BASE_URLS ng ilang backends na pinaghihiwalay ng semicolons.

Ang LibreChat ay may kakayahan din nito, sa pamamagitan ng baseURL ng custom endpoint na ipinakita sa itaas. Ang request na iyon ay lumalabas din sa server, kaya walang browser rule na nalalapat. Ang parehong base URL at ang parehong placeholder key ay gumagana rin sa labas ng chat window, na siyang kailangan lamang para ituro ang isang coding agent sa model na na-host mo na.

Ang Hollama at OrionChat ay maaaring ituro sa anumang endpoint na ita-type mo sa kanilang settings, ngunit ang request ay lumalabas sa iyong browser. Ang lahat ng nasa seksyon sa itaas ay nalalapat sa kanila at sa wala nang iba pa rito.

Ang paghihiwalay ng interface mula sa model ang pinaka-kapaki-pakinabang na bagay na makukuha mo sa isang remote endpoint. Ilagay ang interface sa isang maliit na box at ang model sa lugar kung saan naroon ang memory. Ito rin ang punto para magdesisyon kung Ollama o vLLM ang dapat mag-serve ng mga request, dahil ang dalawa ay magkaiba ang gawi kapag maraming tao ang sabay-sabay na nakikipag-usap sa model. Kung wala pa ang model server, magsimula sa pagtakbo ng Ollama sa isang VPS, at sa isang CPU-only na box, basahin ang kung paano ikumpara ang Ollama sa llama.cpp bago ka pumili ng runner.

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

Sinasabi sa hardening page ng Open WebUI na ang project ay "ginawa para sa mga private, trusted network, gaya ng iba pang self-hosted infrastructure tulad ng mga database, container registry, at CI server," at pinapayuhan kang ilagay ito sa likod ng VPN o reverse proxy na may authentication. Ang isang project na walang login ay dapat tratuhin nang may parehong antas ng pag-iingat.

Suriin kung ano ang nakikinig (listening) bago mo ito pagkatiwalaan.

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

Ang linyang nagbabasa ng 127.0.0.1:3000 ang gusto mong makita. Ang linyang nagbabasa ng 0.0.0.0:3000 ay nangangahulugang ang chat interface mo ay nasa public internet. Mula sa sarili mong machine, ang curl -sI http://YOUR.VPS.IP:3000 na sumasagot ng HTTP/1.1 200 OK ay nagsasabi ng parehong bagay nang mas direkta.

Ang pag-off sa login ng Open WebUI gamit ang WEBUI_AUTH=False ay isang single-user setting para sa machine na hindi maaabot ng iba. Tumanggi rin itong gumana sa installation na mayroon nang mga account, na may mensaheng You can't turn off authentication because there are existing users.

Pattern one: mag-bind sa loopback at i-access ito sa pamamagitan ng 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 iyong laptop. Walang naka-publish, kaya walang ma-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 iwanan ang Ollama sa loopback. Ang pattern na ito ay kasing-tibay lang ng iyong SSH setup, kaya ipares ito sa key-only SSH at hardened sshd.

Pattern two: isang reverse proxy na nag-a-authenticate bago makita ng app ang request. Panatilihin ang app sa loopback, hayaan ang proxy na humawak sa port 443, at maglagay ng single sign-on sa harap nito. Ang Traefik na pinapatakbo ng Docker Compose labels kasama ang Authentik bilang identity provider ay nagbibigay sa bawat app sa box ng iisang login at iisang certificate. Kapag ang Open WebUI ay nasa likod ng TLS (transport layer security), i-set ang WEBUI_SESSION_COOKIE_SECURE=true at WEBUI_SESSION_COOKIE_SAME_SITE=strict. Paikliin din ang JWT_EXPIRES_IN mula sa default nitong apat na linggo, dahil dokumentado sa Open WebUI na kung walang Redis, ang sign-out ay hindi nagpapawalang-bisa sa token: mananatili itong magagamit hanggang sa mag-expire ito nang kusa.

Hindi nasasalba ng pattern two ang mga browser-only project. Ang proxy sa harap ng page ay hindi pinoprotektahan ang model endpoint, at ang fetch mula sa page na iyon patungo sa ibang hostname ay hindi nagdadala ng iyong session cookie, kaya ang authenticating proxy sa harap ng Ollama ay sasagot ng redirect sa login form at mabibigo ang chat. I-route ang model endpoint sa ilalim ng parehong hostname gaya ng page, o gamitin ang pattern one.

Alin ang dapat piliin

Kung may ibang gagamit nito maliban sa iyo, patakbuhin ang Open WebUI. Mayroon itong mga totoong account, ang mga bagong user ay napupunta sa isang approval queue, at ang mga maintainer nito ay naglalathala ng hardening guidance na maaari mong sundin. Kung kailangan mo ng LDAP o admin panel, patakbuhin ang LibreChat, at kumpirmahin gamit ang docker stats kung ang anim na serbisyo nito kasama ang iyong model ay talagang kakasya bago ka umasa rito. Kung ito ay para sa isang tao lamang sa isang maliit na box kung saan ang model ay kinuha na ang halos lahat ng RAM, i-serve ang Hollama o OrionChat sa pamamagitan ng isang SSH tunnel at hayaan ang browser ang humawak ng state. Ang maling sagot sa isang VPS ay ang pag-publish ng alinman sa mga ito sa 0.0.0.0 nang walang login sa harap.

FAQ

Ligtas bang i-expose ang Open WebUI nang direkta sa isang public IP?

Inilalarawan ito ng sarili nitong hardening page bilang software para sa mga private at trusted network, na kapareho ng kategorya ng database o CI server. Mayroon itong mga totoong account, at ang unang account ay nagiging administrator habang ang mga susunod ay mananatiling pending hanggang sa ma-approve, kaya mas ligtas ito kaysa sa UI na walang login. Gayunpaman, ilagay pa rin ito sa likod ng isang reverse proxy na may TLS at, kung maaari, gumamit ng 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 alternatibo sa Open WebUI ang gumagamit ng pinakamaliit na RAM sa isang VPS?

Ang mga browser-based gaya ng Hollama at OrionChat, dahil ang application ay tumatakbo sa client. Ang server ay nagpapadala lamang ng mga static file, at ang OrionChat ay hindi nangangailangan ng application container. Ang Open WebUI ay nagpapanatili ng Python process, database, at default na local embedding model sa memory, na ayon sa dokumentasyon ay nasa 500 MB bawat worker para sa embedding model pa lamang. I-verify ang mga numero sa sarili mong box gamit ang docker stats --no-stream, dahil nagbabago ang mga ito depende sa mga feature na iyong i-enable.

Maaari bang gumamit ang mga chat UI na ito ng Ollama server sa ibang host?

Ang Open WebUI at LibreChat ay maaari, at ang kanilang server ang gumagawa ng koneksyon, kaya hindi nalalapat ang anumang browser rule. I-set ang OLLAMA_BASE_URL para sa Open WebUI, o baseURL sa isang custom endpoint para sa LibreChat. Para sa vLLM o iba pang OpenAI-compatible server, gamitin ang OPENAI_API_BASE_URL kasama ang /v1 suffix at isang non-empty API key. Ang Hollama at OrionChat ay maaari ring tumuro kahit saan, ngunit dahil ang request ay nanggagaling sa iyong browser, dapat ay reachable ang endpoint mula sa iyong browser.

Bakit hindi maabot ng aking browser chat UI ang Ollama?

Dalawang dahilan ang sumasaklaw sa halos lahat ng kaso. Ang Ollama ay naka-bind sa 127.0.0.1:11434 bilang default, kaya hindi ito maaabot ng browser sa ibang machine hangga't hindi nababago ang OLLAMA_HOST. Tinatanggap din ng Ollama ang mga cross-origin request mula sa localhost lamang, kaya ang page na served mula sa iyong sariling domain ay tatanggihan na may No 'Access-Control-Allow-Origin' header is present on the requested resource hanggang sa mailista ang origin na iyon sa OLLAMA_ORIGINS. Kung ang page ay HTTPS at ang endpoint ay HTTP, iba-block ng browser ang call bilang mixed content bago pa man ito makita ng Ollama. I-set ang parehong variable sa isang systemctl edit ollama.service override, o i-forward ang port sa pamamagitan ng SSH at mawawala ang problema.