VPS साठी Open WebUI चे सर्वोत्तम पर्याय कोणते?

VPS वर कोणता Open WebUI पर्याय योग्य आहे

Open WebUI पर्यायांची तुलना जवळजवळ नेहमी laptop वर केली जाते. तेथे RAM स्वस्त असते आणि कोणतीही सेवा सार्वजनिक address वर listening करत नसते. VPS मध्ये ही दोन्ही परिस्थिती बदलतात. त्यामुळे क्रमवारीही बदलते. दुसरी व्यक्ती login करताच Open WebUI हा योग्य default पर्याय राहतो, कारण त्यात प्रत्यक्ष user accounts आणि admin panel उपलब्ध असतात. Interface आणि model यांच्यात RAM मधील शेवटच्या gigabyte साठी स्पर्धा सुरू असेल, तेव्हा हलके projects अधिक चांगली कामगिरी करतात. मात्र त्यासाठी authentication द्यावे लागते. या projects मध्ये authentication नसते.

खालील सर्व माहिती प्रत्येक project च्या स्वतःच्या documentation मधून घेतली आहे आणि ती August 2026 मध्ये वाचली होती. इंटरनेटवरून server उपलब्ध झाल्यानंतरच महत्त्वाचे ठरणारे चार निकष येथे वापरले आहेत.

सार्वजनिक IP वर महत्त्वाचे ठरणारे चार निकष

• मॉडेलच्या शेजारी असलेली memory. मशीनवरील model server ही सर्वाधिक संसाधने वापरणारी प्रक्रिया आहे. Interface ने वापरलेला प्रत्येक megabyte म्हणजे मॉडेलसाठी उपलब्ध नसलेला एक megabyte.
• प्रमाणीकरण. यापैकी काही प्रकल्पांमध्ये user accounts आणि roles असतात. इतर प्रकल्प असे गृहीत धरतात की ते तुमच्या laptop वर चालणारे एकमेव सॉफ्टवेअर आहेत आणि त्यांच्यात login ची कोणतीही सुविधा नसते.
• Remote inference. फक्त 127.0.0.1:11434 पर्यंत पोहोचू शकणारा UI मॉडेलला interface चालत असलेल्या त्याच मशीनवर ठेवण्यास भाग पाडतो.
• देखभाल. SQLite file असलेला एक container सांभाळणे आणि त्यामागे MongoDB व vector database असलेले सहा containers सांभाळणे ही वेगवेगळी कामे आहेत.

मॉडेल इंटरफेससाठी किती RAM शिल्लक ठेवते

या मशीनवरील सर्वात मोठा घटक इंटरफेस नाही. तो मॉडेल आहे. प्रकाशित download sizes किमान मर्यादा दर्शवतात, कारण मॉडेलची उत्तरे तयार होत असताना weights memory मध्ये उपलब्ध असणे आवश्यक असते. Context cache साठी जागा राखून ठेवल्यानंतर प्रत्यक्ष memory वापर download size पेक्षा अधिक असतो.

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

हे Ollama library pages ने August 2026 मध्ये दाखवलेले आकडे आहेत. हे प्रकाशित sizes आहेत; मोजमाप नाहीत. 4 GB VPS वर qwen3:4b साठी 2.5 GB वापरले जातात. त्यामुळे operating system आणि इतर सर्व घटकांसाठी 1.5 GB पेक्षा कमी RAM उरते. Conversation वाढत गेल्यावर context cache ही उरलेली RAM वापरते. qwen3:8b साठी 5.2 GB आवश्यक असल्याने ते त्या मशीनवर मुळीच बसत नाही. Laptop roundups मध्ये या परिस्थितीचा विचार केला जात नाही. Chat interface काहीशे megabytes धरून ठेवत असताना मॉडेल चालेल की नाही, हे येथे ठरते. या tags पेक्षा लक्षणीय मोठ्या मॉडेलसाठी मशीनचा आकार ठरवत असल्यास, CPU-only VPS वर 27B मॉडेलसाठीचे गणित इंटरफेसचा memory वापर कोणताही निर्णायक आकडा का राहत नाही हे दाखवते.

Roundup मधील कोणत्याही आकड्यावर, यातील आकड्यावरही, विश्वास ठेवण्याऐवजी प्रत्यक्ष मोजमाप करा. docker stats --no-stream वास्तविक वापर सुरू झाल्यानंतर एक तासाने चालवा. Container सुरू झाल्यानंतर एक मिनिटाने ते चालवू नका, कारण महत्त्वाची memory पहिल्यांदा वापर केल्यावर allocate केली जाते.

Open WebUI: एकापेक्षा जास्त वापरकर्त्यांसाठीही अजूनही default

Open WebUI एका image मधून चालते आणि तिचा data एका 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

प्रकल्पाच्या README मधील command -p 3000:8080 प्रकाशित करते. त्यामुळे ते प्रत्येक interface वर listen करते. 127.0.0.1: prefix मुळे ते loopback वरच राहते. VPS वर या ओळीतील इतर कोणत्याही घटकापेक्षा हा prefix अधिक महत्त्वाचा आहे, कारण Docker स्वतःचे iptables rules लिहिते आणि published port तुमचे ufw deny rules दुर्लक्षित करते.

खाली वर्णन केलेल्या tunnel किंवा proxy द्वारे page उघडा आणि पहिला account तयार करा. हा account administrator बनतो. त्यानंतर होणाऱ्या signups ना pending role दिली जाते. DEFAULT_USER_ROLE हे documented default आहे. त्यामुळे page पर्यंत पोहोचलेली अनोळखी व्यक्ती admin ने मंजुरी देईपर्यंत तुमचे model वापरू शकत नाही.

खालील projects पेक्षा Open WebUI अधिक memory वापरते, कारण तिची कार्यक्षमता अधिक आहे. तिच्या performance page मध्ये memory खर्च करणारे घटक नमूद केले आहेत. Default embedding engine container मध्ये sentence-transformers model load करते. प्रत्येक worker process साठी सुमारे 500 MB वापरले जाते, असे documentation मध्ये नमूद आहे. RAG_EMBEDDING_ENGINE=ollama सेट केल्यास हे काम तुम्ही आधीच चालवत असलेल्या model server कडे सोपवले जाते. AUDIO_STT_ENGINE=webapi सेट केल्यास स्थानिक speech-to-text model load करणे टाळले जाते. SQLite मध्ये DATABASE_POOL_SIZE unset असल्यास pool मोठ्या internal size वर fallback होतो. प्रत्येक connection स्वतःचा page cache आणि memory map वाढवते. त्यामुळे लहान server वर DATABASE_POOL_SIZE=8 आणि DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 सेट करा. ENABLE_AUTOCOMPLETE_GENERATION=False मुळे user अजून type करत असताना interface model कडे completion मागत नाही.

LibreChat: त्यामागे stack असलेले multi-user

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

Interface port 3080 वर उपलब्ध असते. Login box ऐवजी identity system आवश्यक असल्यास LibreChat निवडा: त्याच्या दस्तऐवजांमध्ये LDAP आणि OAuth2 logins नमूद आहेत आणि users व roles साठी admin panel समाविष्ट आहे. ही क्षमता 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"
  }
]

Default compose file 6 services सुरू करते: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. यापैकी एकही model नाही. MongoDB आणि pgvector या दोघांनाही स्वतंत्र memory आवश्यक असते. 4 GB box वर ती memory model साठी उपलब्ध राहत नाही.

Upgrades ही git operation असते. याच ठिकाणी अनेकांकडून चूक होते.

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

तुम्ही tracked docker-compose.yml मध्ये बदल केला असल्यास git pull conflict सह थांबते. त्यानंतर upgrade अर्धवट लागू होते. तुमचे बदल docker-compose.override.yml मध्ये ठेवा. Project याच कारणासाठी ती file देते. Secrets .env मध्ये ठेवा. दोन्ही files untracked आहेत. त्यामुळे git pull त्यांना बदलत नाही.

librechat.yaml मध्ये custom endpoint देऊन LibreChat ला तुमच्या model server कडे निर्देशित करा.

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"

model-host च्या जागी Ollama चालणाऱ्या box चा address द्या. Ollama त्याची value दुर्लक्षित करत असले तरी apiKey field असणे आवश्यक आहे. त्यामुळे placeholder वापरता येतो. LibreChat Docker मध्ये आणि Ollama त्याच machine वर चालत असल्यास container मधील localhost म्हणजे container स्वतः असतो. त्यामुळे त्याऐवजी host.docker.internal वापरा.

Hollama आणि OrionChat: काम ब्राउझर करतो

Hollama एका लहान कंटेनरमधून ब्राउझर अॅप्लिकेशन उपलब्ध करून देतो. चॅट्स सर्व्हरवर नाही, तर तुमच्या ब्राउझरच्या storage मध्ये साठवल्या जातात.

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

README मधील या command मध्ये --rm वापरले आहे. कंटेनर थांबल्यावर ते कंटेनर delete करते. त्यामुळे reboot नंतर interface पुन्हा उपलब्ध होत नाही. Reverse proxy मागे हे चालवताना -e VITE_ALLOWED_HOSTS='chat.example.com' जोडा, कारण image मध्ये फक्त host localhost मान्य आहे. इतर कोणत्याही hostname साठी आलेल्या request ला app देण्याऐवजी ती blocked-host error देते.

OrionChat यापेक्षा पुढे जाते आणि त्यात server component अजिबात नाही. Repository clone करा आणि आधीपासून चालू असलेल्या web server ने तो folder serve करा, किंवा disk वरील index.html उघडा. API keys ब्राउझरच्या localStorage मध्ये साठवल्या जातात. Chat history ब्राउझरमध्येच राहते. Chats ची संख्या 512 पेक्षा जास्त झाल्यावर app सर्वात जुन्या chats delete करते.

दोन्ही प्रकल्पांमध्ये login नाही, कारण login तपासणारा serverच नाही. Laptop वर ही रचना योग्य आहे. VPS वर page कधीही 0.0.0.0 वर प्रकाशित करू नका. आणखी एक महत्त्वाची गोष्ट सहज लक्षात येत नाही: model ला call server नाही, तर browser करतो.

या एकाच वस्तुस्थितीमुळे ही दोन्ही साधने कुठे वापरता येतील हे ठरते. तुमच्या browser ला Ollama पर्यंत थेट पोहोचता आले पाहिजे. त्यामुळे Ollama ने loopback व्यतिरिक्त इतर interface वर listen केले पाहिजे. तसेच Ollama मध्ये कोणत्याही प्रकारचे authentication नाही. यावरून browser चे दोन नियम लागू होतात. HTTPS वर serve केलेले page plain HTTP endpoint ला call करू शकत नाही. Console मध्ये 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. दिसते. तुम्ही तो origin परवानगीच्या यादीत जोडेपर्यंत इतर कोणत्याही origin कडे केलेला call has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource सह नाकारला जातो.

यापैकी कोणतीही setting बदलण्याची Ollama ने दस्तऐवजीकरण केलेली पद्धत 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

जिथे आधी 127.0.0.1:11434 दिसत होते, तिथे आता ss ने 0.0.0.0:11434 दाखवले पाहिजे. Firewall किंवा authentication करणारा proxy port पर्यंत कोण पोहोचू शकतो हे आधीपासून नियंत्रित करत असेल, तेव्हाच हा बदल करा. कारण खुले 11434 म्हणजे खुले model server. Mass scanners नवीन सार्वजनिक port पटकन शोधतात. खालील SSH tunnel हा संपूर्ण प्रश्न टाळतो. त्यानंतर page localhost origin वर चालते, ज्याला Ollama default ने परवानगी देतो. तसेच port त्या मशीनच्या बाहेर उघड होत नाही.

प्रत्येक अॅप remote Ollama किंवा vLLM endpoint वापरू शकतो का

Open WebUI हे करू शकते आणि connection server side वरून केली जाते. OLLAMA_BASE_URL=http://model-host:11434 वापरून ते Ollama कडे निर्देशित करा. vLLM किंवा इतर कोणत्याही OpenAI-compatible server साठी OPENAI_API_BASE_URL=http://model-host:8000/v1 मध्ये non-empty OPENAI_API_KEY सेट करा आणि /v1 suffix कायम ठेवा; तो आवश्यक आहे. OPENAI_API_BASE_URLS मध्ये semicolon ने विभक्त केलेले अनेक backends स्वीकारले जातात.

LibreChat हे वर दाखवलेल्या custom endpoint च्या baseURL द्वारे करू शकते. ती request देखील server सोडते, त्यामुळे browser rule लागू होत नाही. तोच base URL आणि तोच placeholder key chat window च्या बाहेरही काम करतात. त्यामुळे तुम्ही आधीच host केलेल्या model कडे coding agent निर्देशित करणे एवढेच आवश्यक असते.

Hollama आणि OrionChat त्यांच्या settings मध्ये तुम्ही टाइप केलेल्या कोणत्याही endpoint कडे निर्देशित करता येतात; परंतु request तुमच्या browser मधून बाहेर जाते. वरील section मधील सर्व नियम त्यांनाही लागू होतात आणि या यादीतील इतर कोणालाही लागू होत नाहीत.

Remote endpoint मुळे interface आणि model वेगळे ठेवता येणे हा सर्वात उपयुक्त लाभ आहे. Interface एखाद्या लहान box वर ठेवा आणि model पुरेशी memory असलेल्या ठिकाणी ठेवा. एकाच वेळी अनेक लोक model शी संवाद साधत असताना दोन्हींचे वर्तन खूप वेगळे असते. त्यामुळे requests कोणत्या server ने serve कराव्यात हे ठरवण्याची हीच योग्य वेळ आहे: Ollama किंवा vLLM निवडायचे का ते ठरवा. Model server अद्याप उपलब्ध नसेल, तर VPS वर Ollama चालवून सुरुवात करा. CPU-only box असल्यास runner निवडण्यापूर्वी Ollama ची llama.cpp सोबत तुलना कशी होते ते वाचा.

0.0.0.0 वर लॉगिन नसलेला chat UI कधीही प्रकाशित करू नका

Open WebUI च्या hardening पृष्ठावर हा प्रकल्प “databases, container registries आणि CI servers यांसारख्या इतर self-hosted infrastructure प्रमाणे private, trusted networks साठी तयार केला आहे” असे नमूद केले आहे. तसेच तो VPN मागे किंवा authentication असलेल्या reverse proxy मागे ठेवण्यास सांगतो. अजिबात login नसलेल्या प्रकल्पाला किमान तेवढीच सुरक्षा द्यावी.

कोणत्याही गोष्टीवर विश्वास ठेवण्यापूर्वी कोणते ports listening आहेत ते तपासा.

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

127.0.0.1:3000 असलेली ओळ अपेक्षित आहे. 0.0.0.0:3000 असलेली ओळ म्हणजे तुमचा chat interface public internet वर आहे. तुमच्या स्वतःच्या machine वर curl -sI http://YOUR.VPS.IP:3000 ने HTTP/1.1 200 OK ला उत्तर मिळणे हेच अधिक स्पष्टपणे दाखवते.

WEBUI_AUTH=False वापरून Open WebUI चे login बंद करणे ही अशा machine साठी single-user setting आहे, जिच्यापर्यंत इतर कोणालाही पोहोचता येत नाही. ज्या installation मध्ये आधीच accounts आहेत, त्यावर ही setting लागू करण्यास ते नकार देते आणि You can't turn off authentication because there are existing users. असा संदेश दाखवते.

पद्धत एक: loopback वर bind करा आणि SSH द्वारे प्रवेश करा. प्रत्येक port 127.0.0.1 वर publish करा. त्यानंतर आवश्यक port forward करा: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, आणि तुमच्या laptop वर http://localhost:3000 उघडा. काहीही publish होत नसल्यामुळे scanning करता येत नाही. Hollama किंवा OrionChat साठी त्याच command मध्ये -L 11434:127.0.0.1:11434 वापरून model port देखील forward करा आणि Ollama loopback वरच ठेवा. ही पद्धत तुमच्या SSH setup इतकीच सुरक्षित आहे. त्यामुळे key-only SSH आणि hardened sshd सोबत ती वापरा.

पद्धत दोन: app ला request दिसण्यापूर्वी authentication करणारा reverse proxy. App loopback वर ठेवा, proxy कडे port 443 ची जबाबदारी द्या आणि त्याच्या पुढे single sign-on ठेवा. Docker Compose labels द्वारे नियंत्रित Traefik आणि identity provider म्हणून Authentik वापरल्यास machine वरील प्रत्येक app साठी एक login आणि एक certificate मिळते. Open WebUI ला TLS (transport layer security) मागे ठेवताना WEBUI_SESSION_COOKIE_SECURE=true आणि WEBUI_SESSION_COOKIE_SAME_SITE=strict सेट करा. JWT_EXPIRES_IN ची मुदत त्याच्या default चार आठवड्यांपेक्षा कमी करा. Open WebUI च्या दस्तऐवजानुसार Redis नसल्यास sign-out केल्यावर token invalid होत नाही. तो आपोआप expire होईपर्यंत वापरता येतो.

पद्धत दोन browser-only projects चे संरक्षण करत नाही. Page च्या पुढे असलेला proxy model endpoint चे संरक्षण करत नाही. तसेच त्या page वरून वेगळ्या hostname कडे केलेल्या fetch request सोबत तुमचा session cookie पाठवला जात नाही. त्यामुळे Ollama च्या पुढे असलेला authenticating proxy login form कडे redirect देतो आणि chat अपयशी ठरतो. Model endpoint ला page प्रमाणेच hostname अंतर्गत route करा किंवा पद्धत एक वापरा.

कोणते निवडावे

तुमच्याशिवाय इतर कोणीही ते वापरणार असेल, तर Open WebUI चालवा. त्यामध्ये प्रत्यक्ष user accounts आहेत. नवीन users approval queue मध्ये जातात. त्याचे maintainers follow करता येतील असे hardening guidance प्रकाशित करतात. LDAP किंवा admin panel आवश्यक असल्यास LibreChat चालवा. त्यावर अवलंबून राहण्यापूर्वी त्याच्या सहा services आणि तुमचे model यासाठी पुरेशी resources उपलब्ध आहेत का, हे docker stats ने पडताळा. लहान box वर एकच व्यक्ती वापरणार असेल आणि model ने RAM चा बहुतांश भाग आधीच व्यापला असेल, तर Hollama किंवा OrionChat SSH tunnel द्वारे उपलब्ध करा आणि state browser कडे ठेवू द्या. VPS वर चुकीची रचना म्हणजे login शिवाय त्यांपैकी कोणतीही सेवा 0.0.0.0 वर सार्वजनिक करणे.

FAQ

Open WebUI थेट public IP वर उपलब्ध करून देणे सुरक्षित आहे का?

त्याच्या hardening पृष्ठावर Open WebUI चे वर्णन private, trusted networks साठीचे software असे केले आहे. ते database किंवा CI server सारख्याच श्रेणीत येते. त्यात प्रत्यक्ष user accounts असतात. पहिला account administrator बनतो, तर नंतरचे accounts मंजुरी मिळेपर्यंत pending राहतात. त्यामुळे login नसलेल्या UI पेक्षा ते अधिक सुरक्षित आहे. तरीही ते TLS असलेल्या reverse proxy मागे ठेवा. शक्य असल्यास single sign-on देखील वापरा. Container port 127.0.0.1:3000:8080 म्हणून publish करा, म्हणजे Docker चे स्वतःचे iptables rules तुमच्या नकळत ते इंटरनेटसाठी उघडू शकणार नाहीत.

VPS वर कोणता Open WebUI पर्याय सर्वात कमी RAM वापरतो?

Browser-based पर्याय, Hollama आणि OrionChat, सर्वात कमी RAM वापरतात. कारण application client वर चालते. Server फक्त static files पाठवतो. OrionChat ला application container चीही गरज नसते. Open WebUI एक Python process, database आणि default नुसार local embedding model memory मध्ये ठेवते. दस्तऐवजानुसार फक्त embedding model साठी प्रत्येक worker सुमारे 500 MB वापरतो. तुमच्या स्वतःच्या box वर docker stats --no-stream वापरून आकडे तपासा, कारण तुम्ही सुरू केलेल्या features नुसार ते बदलतात.

हे chat UIs दुसऱ्या host वरील Ollama server वापरू शकतात का?

Open WebUI आणि LibreChat हे करू शकतात. Connection त्यांचा server तयार करतो, त्यामुळे browser rule लागू होत नाही. Open WebUI साठी OLLAMA_BASE_URL सेट करा. LibreChat साठी custom endpoint मध्ये baseURL सेट करा. vLLM किंवा अन्य OpenAI-compatible server साठी /v1 suffix असलेले OPENAI_API_BASE_URL वापरा आणि रिकामी नसलेली API key द्या. Hollama आणि OrionChat देखील कोणत्याही ठिकाणी point करता येतात. मात्र request तुमच्या browser कडून येते. त्यामुळे endpoint तुमच्या browser मधूनही reachable असणे आवश्यक आहे.

माझे browser chat UI Ollama पर्यंत पोहोचत का नाही?

जवळजवळ प्रत्येक प्रकरणासाठी दोन कारणे लागू होतात. Ollama default नुसार 127.0.0.1:11434 वर bind होते. त्यामुळे OLLAMA_HOST बदलेपर्यंत दुसऱ्या machine वरील browser त्याच्यापर्यंत पोहोचू शकत नाही. तसेच Ollama localhost कडून येणाऱ्या cross-origin requests स्वीकारते. त्यामुळे तुमच्या स्वतःच्या domain वरून serve केलेले page No 'Access-Control-Allow-Origin' header is present on the requested resource सह नाकारले जाते, जोपर्यंत तो origin OLLAMA_ORIGINS मध्ये सूचीबद्ध केलेला नसतो. Page HTTPS वर आणि endpoint HTTP वर असल्यास, Ollama ला request मिळण्यापूर्वीच browser ती mixed content म्हणून block करतो. दोन्ही variables systemctl edit ollama.service override मध्ये सेट करा. किंवा SSH द्वारे port forward करा; त्यानंतर ही समस्या राहत नाही.