VPS के लिए सर्वश्रेष्ठ Open WebUI विकल्प: तुलना और गाइड

VPS पर कौन सा Open WebUI विकल्प उपयोग करना चाहिए

Open WebUI के विकल्पों की तुलना अक्सर लैपटॉप पर की जाती है, जहाँ RAM सस्ती होती है और कोई भी सेवा public address पर listen नहीं कर रही होती है। एक VPS इन दोनों तथ्यों को बदल देता है, और इससे रैंकिंग भी बदल जाती है। जैसे ही कोई दूसरा व्यक्ति login करता है, Open WebUI ही सही डिफ़ॉल्ट विकल्प बना रहता है, क्योंकि इसमें वास्तविक user accounts और एक admin panel की सुविधा मिलती है। हल्के प्रोजेक्ट्स तब बेहतर होते हैं जब interface को RAM के अंतिम gigabyte के लिए model के साथ प्रतिस्पर्धा करनी पड़ती है। उस जीत की कीमत authentication है: उनमें यह सुविधा नहीं होती है।

नीचे दी गई सभी जानकारी अगस्त 2026 में पढ़े गए प्रत्येक प्रोजेक्ट के स्वयं के documentation से ली गई है। ये चार मानक केवल तभी महत्वपूर्ण होते हैं जब सर्वर internet से पहुँच योग्य (reachable) हो।

Public IP पर केवल ये चार पहलू मायने रखते हैं

• Model के पास Memory। Model server सिस्टम पर सबसे अधिक संसाधन लेने वाली प्रक्रिया है। Interface द्वारा उपयोग की गई हर megabyte, model के लिए उपलब्ध memory को कम करती है।
• Authentication। कुछ projects में user accounts और roles होते हैं। अन्य यह मानकर चलते हैं कि वे आपके laptop पर अकेले चल रहे हैं, और उनमें कोई login system नहीं होता।
• Remote inference। जो UI केवल 127.0.0.1:11434 पर point करता है, वह model को interface के साथ ही स्थित होने की अपेक्षा रखता है। Model को कहीं और रखने के लिए एक tunnel की आवश्यकता होती है जो उस local port को model host तक forward करे।
• Upkeep। SQLite file वाला एक container, MongoDB और vector database के साथ चल रहे छह containers की तुलना में बहुत अलग काम है।

मॉडल इंटरफ़ेस के लिए कितनी RAM छोड़ता है

इंटरफ़ेस सर्वर पर सबसे बड़ी चीज़ नहीं है। मॉडल सबसे बड़ा है। प्रकाशित डाउनलोड आकार आपको न्यूनतम सीमा बताते हैं, क्योंकि मॉडल के उत्तर देते समय weights का मेमोरी में होना आवश्यक है और context cache आवंटित होने के बाद वास्तविक मेमोरी उपयोग डाउनलोड आकार से अधिक होता है।

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.4"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

ये वे आंकड़े हैं जो 17 October 2026 को Ollama लाइब्रेरी पेजों पर प्रकाशित किए गए थे। ये प्रकाशित आकार हैं, माप नहीं। 4 GB के VPS पर, qwen3:4b जिसका आकार 2.5 GB है, ऑपरेटिंग सिस्टम और अन्य कार्यों के लिए 1.5 GB से कम RAM छोड़ता है। जैसे-जैसे बातचीत बढ़ती है, context cache इसमें से और जगह लेता है, इसीलिए आपके द्वारा सेट किया गया num_ctx गुणवत्ता के साथ-साथ मेमोरी का भी एक निर्णय है। qwen3:8b जिसका आकार 5.2 GB है, वह इस सर्वर पर बिल्कुल भी फिट नहीं होता है। यह वह स्थिति है जिसे लैपटॉप राउंडअप कभी कवर नहीं करते हैं, और यहीं पर कुछ सौ मेगाबाइट लेने वाला चैट इंटरफ़ेस यह तय करता है कि मॉडल चलेगा या नहीं। यदि आप इन टैग्स से काफी ऊपर के किसी सर्वर का आकार निर्धारित कर रहे हैं, तो CPU-only VPS पर 27B मॉडल के लिए गणना दिखाती है कि कितनी जल्दी इंटरफ़ेस वह संख्या नहीं रह जाता जो सब कुछ तय करती है।

किसी राउंडअप में दी गई किसी भी संख्या पर भरोसा करने के बजाय स्वयं मापें, जिसमें यह भी शामिल है। वास्तविक उपयोग के एक घंटे बाद docker stats --no-stream चलाएं, न कि कंटेनर शुरू होने के एक मिनट बाद, क्योंकि जो मेमोरी मायने रखती है वह पहले उपयोग पर आवंटित होती है। Ollama पांच मिनट के idle समय के बाद weights को रिलीज़ भी कर देता है, इसलिए बातचीत के बीच में ली गई रीडिंग पीक मेमोरी उपयोग को कम करके दिखाती है, और अगला संदेश फिर से पूरा लोड लेता है, जब तक कि आप keep_alive के साथ मॉडल को मेमोरी में न रखें।

Open WebUI: एक से अधिक उपयोगकर्ताओं के लिए अब भी डिफ़ॉल्ट विकल्प

Open WebUI एक ही image से चलता है और अपना डेटा एक ही 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 में दिया गया कमांड -p 3000:8080 को पब्लिश करता है, जो हर interface पर listen करता है। 127.0.0.1: prefix इसे loopback पर ही सीमित रखता है। एक VPS पर, लाइन में मौजूद किसी भी अन्य चीज़ की तुलना में यह prefix अधिक महत्वपूर्ण है, क्योंकि Docker अपने स्वयं के iptables नियम लिखता है और एक पब्लिश किया गया port आपके ufw deny नियमों को अनदेखा कर देता है।

पेज तक पहुँचने के लिए tunnel या proxy का उपयोग करें (दोनों का वर्णन नीचे दिया गया है), और फिर पहला अकाउंट बनाएँ। वह अकाउंट एडमिनिस्ट्रेटर बन जाता है। बाद के साइनअप pending भूमिका के साथ बनाए जाते हैं, जो DEFAULT_USER_ROLE का दस्तावेजीकृत डिफ़ॉल्ट है, इसलिए पेज तक पहुँचने वाला कोई अनजान व्यक्ति तब तक आपके मॉडल का उपयोग नहीं कर सकता जब तक कि कोई एडमिन उसे मंजूरी न दे दे।

Open WebUI नीचे दिए गए प्रोजेक्ट्स की तुलना में अधिक मेमोरी लेता है क्योंकि यह अधिक कार्य करता है, और इसका अपना परफॉर्मेंस पेज उन हिस्सों के नाम बताता है जो मेमोरी की खपत करते हैं। डिफ़ॉल्ट एम्बेडिंग इंजन कंटेनर के अंदर एक sentence-transformers मॉडल लोड करता है, जो प्रति वर्कर प्रोसेस लगभग 500 MB या उससे अधिक का होता है। RAG_EMBEDDING_ENGINE=ollama सेट करने से वह कार्य उस मॉडल सर्वर को सौंप दिया जाता है जिसे आप पहले से चला रहे हैं। AUDIO_STT_ENGINE=webapi स्थानीय speech-to-text मॉडल को लोड होने से रोकता है। SQLite पर, यदि DATABASE_POOL_SIZE सेट नहीं है, तो पूल एक बड़े आंतरिक आकार पर वापस आ जाता है और प्रत्येक कनेक्शन अपना पेज कैश और मेमोरी मैप बढ़ाता है, इसलिए छोटे बॉक्स पर DATABASE_POOL_SIZE=8 और DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 सेट करें। Autocomplete, जो उपयोगकर्ता के टाइप करते समय मॉडल से पूर्णता (completion) के लिए पूछता है, अब बंद (switched off) आता है (ENABLE_AUTOCOMPLETE_GENERATION का डिफ़ॉल्ट False है), इसलिए छोटे बॉक्स पर इसे वैसा ही रहने दें।

LibreChat: मल्टी-यूज़र, एक स्टैक के साथ

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

इसका इंटरफ़ेस 3080 पोर्ट पर जवाब देता है। जब आपको केवल एक लॉगिन बॉक्स के बजाय एक आइडेंटिटी सिस्टम की आवश्यकता हो, तो LibreChat पर विचार करना चाहिए: यह LDAP और OAuth2 लॉगिन को डॉक्यूमेंट करता है, और इसकी डिफ़ॉल्ट compose फ़ाइल यूज़र्स, ग्रुप्स और रोल्स के लिए एक एडमिन पैनल शुरू करती है। वह पैनल अपनी खुद की सर्विस के रूप में चलता है, न कि LibreChat प्रोसेस के अंदर, और प्रोजेक्ट अभी भी इसे प्रीव्यू के रूप में चिह्नित करता है। यह क्षमता एक स्टैक के साथ आती है।

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

डिफ़ॉल्ट compose फ़ाइल 6 सर्विसेज़ शुरू करती है: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API। इनमें से कोई भी मॉडल नहीं है। MongoDB और pgvector दोनों को अपनी-अपनी मेमोरी चाहिए, और 4 GB वाले बॉक्स पर यह वह मेमोरी है जो मॉडल को चाहिए थी।

उनमें से दो सर्विसेज़ पोर्ट्स पब्लिश करती हैं, और कोई भी मैपिंग बाइंड एड्रेस नहीं बताती: API 3080 पर और एडमिन पैनल होस्ट पोर्ट 3000 पर, जो ADMIN_PANEL_PORT का डिफ़ॉल्ट है। इसलिए दोनों हर इंटरफ़ेस पर लिसन करते हैं। पोर्ट 3000 वही है जिसका उपयोग ऊपर Open WebUI करता है, इसलिए एक साझा बॉक्स पर दोनों टकराते हैं। स्टैक के इंटरनेट का सामना करने से पहले दोनों को 127.0.0.1 पर docker-compose.override.yml में रीबाइंड करें।

अपग्रेड एक git ऑपरेशन है, जो वह हिस्सा है जिसे लोग गलत तरीके से करते हैं।

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

यदि आपने ट्रैक की गई docker-compose.yml को एडिट किया है तो git pull एक कॉन्फ्लिक्ट के साथ रुक जाता है, और फिर अपग्रेड आधा ही लागू होता है। अपने बदलावों को docker-compose.override.yml में रखें, जिसे प्रोजेक्ट इसके लिए प्रदान करता है, और सीक्रेट्स को .env में रखें। दोनों फाइलें अनट्रैक्ड हैं, इसलिए git pull उन्हें नहीं छेड़ता।

LibreChat को 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"

model-host को Ollama चलाने वाले बॉक्स के एड्रेस से बदलें। apiKey फ़ील्ड का मौजूद होना ज़रूरी है, भले ही Ollama इसके मान को अनदेखा कर दे, इसलिए एक प्लेसहोल्डर ठीक है। यदि LibreChat Docker में चलता है और Ollama उसी मशीन पर चलता है, तो कंटेनर के अंदर localhost का मतलब कंटेनर स्वयं होता है, इसलिए वहाँ इसके बजाय host.docker.internal का उपयोग करें।

Hollama और OrionChat: ब्राउज़र ही सारा काम करता है

Hollama एक छोटे कंटेनर से ब्राउज़र एप्लिकेशन सर्व करता है। चैट आपके ब्राउज़र के स्टोरेज में रहती हैं, सर्वर पर नहीं।

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

इस कमांड का README वर्शन --rm का उपयोग करता है, जो रुकने पर कंटेनर को डिलीट कर देता है, इसलिए रीबूट के बाद इंटरफ़ेस वापस नहीं आता है। रिवर्स प्रॉक्सी के पीछे, -e VITE_ALLOWED_HOSTS='chat.example.com' जोड़ें, क्योंकि इमेज केवल होस्ट localhost की अनुमति देती है और किसी अन्य होस्टनेम के अनुरोध का उत्तर ऐप के बजाय blocked-host एरर के साथ देती है।

OrionChat और आगे जाता है और इसमें कोई सर्वर कंपोनेंट नहीं होता है। रिपॉजिटरी को क्लोन करें और उस फोल्डर को उस वेब सर्वर के साथ सर्व करें जिसे आप पहले से चला रहे हैं, या डिस्क से index.html खोलें। API कीज़ ब्राउज़र के localStorage में स्टोर होती हैं, चैट हिस्ट्री ब्राउज़र में रहती है, और संख्या 512 से अधिक होने पर ऐप सबसे पुरानी चैट को डिलीट कर देता है। इसका Ollama एड्रेस सोर्स में http://localhost:11434 पर फिक्स्ड है, और इसकी सेटिंग्स में इसे बदलने के लिए कोई फील्ड नहीं है।

किसी भी प्रोजेक्ट में लॉगिन नहीं है, क्योंकि किसी में भी ऐसा सर्वर नहीं है जो इसे चेक कर सके। लैपटॉप पर यह ठीक है। VPS पर इसका मतलब है कि पेज को कभी भी 0.0.0.0 पर पब्लिश नहीं किया जाना चाहिए, और इसका मतलब एक ऐसी बात है जिसे नज़रअंदाज़ करना आसान है: ब्राउज़र मॉडल को कॉल करता है, सर्वर नहीं।

यह एक तथ्य तय करता है कि ये दोनों कहाँ उपयोग करने योग्य हैं। आपके ब्राउज़र को सीधे Ollama तक पहुँचना होगा। OrionChat के लिए इसका हमेशा मतलब ब्राउज़र चलाने वाली मशीन पर localhost:11434 होता है, इसलिए VPS पर नीचे दिया गया SSH टनल मॉडल तक इसका एकमात्र रास्ता है। Hollama कोई भी एड्रेस लेता है, इसलिए जब तक आप SSH पर पोर्ट फॉरवर्ड नहीं करते, Ollama को लूपबैक से अधिक पर लिसन करना होगा, और Ollama में किसी भी प्रकार का ऑथेंटिकेशन नहीं है। इससे ब्राउज़र के दो नियम निकलते हैं। HTTPS पर सर्व किया गया पेज प्लेन HTTP एंडपॉइंट को कॉल नहीं कर सकता, और कंसोल 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. प्रिंट करता है। किसी अन्य ऑरिजिन के कॉल को has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource के साथ तब तक अस्वीकार कर दिया जाता है जब तक आप उस ऑरिजिन को अनुमति नहीं देते।

Ollama का दोनों सेटिंग्स बदलने का डॉक्यूमेंटेड तरीका एक systemd ओवरराइड है।

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 को अब 0.0.0.0:11434 प्रिंट करना चाहिए जहाँ यह पहले 127.0.0.1:11434 प्रिंट करता था। यह बदलाव केवल तब करें जब कोई फायरवॉल या ऑथेंटिकेटिंग प्रॉक्सी पहले से नियंत्रित कर रही हो कि पोर्ट तक कौन पहुँच सकता है, क्योंकि एक खुला 11434 एक खुला मॉडल सर्वर है और मास स्कैनर्स नए पब्लिक पोर्ट तक जल्दी पहुँच जाते हैं। नीचे दिया गया SSH टनल पूरे सवाल से बचाता है: पेज तब localhost ऑरिजिन पर चलता है, जिसे Ollama डिफ़ॉल्ट रूप से अनुमति देता है, और पोर्ट कभी भी बॉक्स से बाहर नहीं जाता है।

क्या प्रत्येक टूल रिमोट Ollama या vLLM एंडपॉइंट का उपयोग कर सकता है

Open WebUI ऐसा कर सकता है, और कनेक्शन सर्वर-साइड पर बनता है। OLLAMA_BASE_URL=http://model-host:11434 इसे Ollama की ओर निर्देशित करता है। vLLM के लिए, OPENAI_API_BASE_URL=http://model-host:8000/v1 सेट करें, और उस /v1 को बनाए रखें जिसके तहत vLLM अपना API सर्व करता है। OPENAI_API_KEY केवल तभी सेट करें यदि सर्वर को एक की (key) के साथ शुरू किया गया था, क्योंकि Open WebUI की vLLM गाइड अन्यथा किसी ऑथेंटिकेशन का उपयोग नहीं करती है। अन्य OpenAI-संगत सर्वर अपने स्वयं के दस्तावेज़ों द्वारा दिए गए किसी भी बेस पाथ को स्वीकार करते हैं, जो हमेशा /v1 नहीं होता है। OPENAI_API_BASE_URLS अर्धविराम (semicolons) द्वारा अलग किए गए कई बैकएंड को स्वीकार करता है।

LibreChat ऊपर दिखाए गए कस्टम एंडपॉइंट के baseURL के माध्यम से ऐसा कर सकता है। वह अनुरोध भी सर्वर से बाहर जाता है, इसलिए कोई ब्राउज़र नियम लागू नहीं होता है। वही बेस URL और वही प्लेसहोल्डर की (key) चैट विंडो के बाहर भी काम करते हैं, और आपके द्वारा पहले से होस्ट किए गए मॉडल पर कोडिंग एजेंट को पॉइंट करने के लिए बस इतना ही काफी है।

Hollama को उसकी सेटिंग्स में आपके द्वारा टाइप किए गए किसी भी एंडपॉइंट पर पॉइंट किया जा सकता है। Ollama कनेक्शन के अलावा, यह एक संपादन योग्य बेस URL के साथ OpenAI-संगत कनेक्शन प्रदान करता है, जो डिफ़ॉल्ट रूप से http://localhost:8080/v1 है, और यही vLLM का मार्ग है। अनुरोध आपके ब्राउज़र से बाहर जाता है, इसलिए ऊपर दिए गए अनुभाग की सभी बातें इस पर लागू होती हैं। OrionChat को कहीं भी पॉइंट नहीं किया जा सकता है। इसके एंडपॉइंट हार्डकोडेड हैं, जिसमें Ollama http://localhost:11434/v1/chat/completions पर फिक्स्ड है, और इसका README कहता है कि अनुरोध सीधे प्रत्येक प्रदाता के आधिकारिक API पर जाते हैं। एक रिमोट Ollama केवल एक SSH टनल के माध्यम से ही पहुंच योग्य है जो इसे उस लोकल पोर्ट पर उत्तर देने के लिए मजबूर करता है, और vLLM सर्वर के लिए कोई सेटिंग मौजूद नहीं है।

इंटरफ़ेस को मॉडल से अलग करना वह सबसे उपयोगी लाभ है जो एक रिमोट एंडपॉइंट आपको देता है। इंटरफ़ेस को एक छोटे बॉक्स पर रखें और मॉडल को वहां रखें जहाँ मेमोरी उपलब्ध है। यह यह तय करने का भी बिंदु है कि Ollama या vLLM में से किसे अनुरोध सर्व करने चाहिए, क्योंकि जब कई लोग एक साथ मॉडल से बात करते हैं तो दोनों का व्यवहार बहुत अलग होता है। यदि मॉडल सर्वर अभी तक मौजूद नहीं है, तो VPS पर Ollama चलाकर शुरुआत करें, और केवल CPU वाले बॉक्स पर, रनर चुनने से पहले Ollama की llama.cpp के साथ तुलना कैसे करें पढ़ें।

बिना लॉगिन वाले चैट UI को कभी भी 0.0.0.0 पर पब्लिश न करें

Open WebUI का हार्डनिंग पेज कहता है कि यह प्रोजेक्ट "निजी और भरोसेमंद नेटवर्क के लिए बनाया गया है, ठीक वैसे ही जैसे डेटाबेस, कंटेनर रजिस्ट्री और CI सर्वर जैसे अन्य self-hosted इंफ्रास्ट्रक्चर होते हैं"। यह आपको इसे VPN के पीछे या ऑथेंटिकेशन वाले रिवर्स प्रॉक्सी के पीछे रखने की सलाह देता है। बिना लॉगिन वाला कोई भी प्रोजेक्ट कम से कम इसी तरह के सुरक्षा उपायों का हकदार है।

किसी भी सेवा पर भरोसा करने से पहले जाँचें कि वह कहाँ listen कर रही है।

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

यदि लाइन 127.0.0.1:3000 दिखाई दे, तो इसका मतलब है कि आप सुरक्षित हैं। यदि लाइन 0.0.0.0:3000 दिखाई दे, तो इसका मतलब है कि सेवा सभी एड्रेस पर listen कर रही है, और Docker डिफ़ॉल्ट रूप से हर बाहरी सोर्स IP को पब्लिश किए गए पोर्ट तक पहुँचने की अनुमति देता है। जब तक Docker की DOCKER-USER चेन या आपके प्रोवाइडर का फायरवॉल इसे ब्लॉक न करे, तब तक आपका चैट इंटरफेस सार्वजनिक इंटरनेट पर खुला है। अपनी मशीन से, curl -sI http://YOUR.VPS.IP:3000 को HTTP/1.1 200 OK के साथ चलाने पर स्थिति स्पष्ट हो जाएगी।

Open WebUI के लॉगिन को WEBUI_AUTH=False के साथ बंद करना केवल उन मशीनों के लिए है जहाँ कोई और नहीं पहुँच सकता। इसके डॉक्यूमेंटेशन में यह भी कहा गया है कि यह केवल उन इंस्टॉलेशन पर काम करता है जहाँ कोई रजिस्टर्ड यूजर नहीं है, इसलिए आप इसे उन इंस्टॉलेशन पर लागू नहीं कर सकते जहाँ पहले से अकाउंट मौजूद हैं।

पहला पैटर्न: लूपबैक (loopback) से बाइंड करें और SSH के जरिए एक्सेस करें। हर पोर्ट को 127.0.0.1 पर पब्लिश करें, फिर अपनी जरूरत के अनुसार फॉरवर्ड करें: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, और अपने लैपटॉप पर http://localhost:3000 खोलें। कुछ भी सार्वजनिक रूप से पब्लिश नहीं होता, इसलिए किसी के द्वारा स्कैन नहीं किया जा सकता। Hollama या OrionChat के लिए, उसी कमांड में -L 11434:127.0.0.1:11434 के साथ मॉडल पोर्ट को फॉरवर्ड करें और Ollama को लूपबैक पर ही रहने दें। यह पैटर्न केवल आपके SSH सेटअप जितना ही मजबूत है, इसलिए इसे key-only SSH और एक सुरक्षित sshd के साथ इस्तेमाल करें।

दूसरा पैटर्न: एक रिवर्स प्रॉक्सी जो ऐप तक रिक्वेस्ट पहुँचने से पहले ऑथेंटिकेशन करे। ऐप को लूपबैक पर रखें, प्रॉक्सी को पोर्ट 443 संभालने दें, और सामने सिंगल साइन-ऑन (SSO) लगाएँ। Docker Compose लेबल्स द्वारा संचालित Traefik और आइडेंटिटी प्रोवाइडर के रूप में Authentik का उपयोग करने से सर्वर पर मौजूद हर ऐप के लिए एक लॉगिन और एक सर्टिफिकेट मिल जाता है। Open WebUI को TLS (transport layer security) के पीछे रखने पर, WEBUI_SESSION_COOKIE_SECURE=true और WEBUI_SESSION_COOKIE_SAME_SITE=strict सेट करें। JWT_EXPIRES_IN को भी उसके चार-सप्ताह के डिफ़ॉल्ट समय से कम करें, क्योंकि Open WebUI के डॉक्यूमेंटेशन के अनुसार Redis के बिना साइन-आउट करने पर टोकन इनवैलिड नहीं होता: यह अपने आप एक्सपायर होने तक उपयोग में बना रहता है।

दूसरा पैटर्न केवल ब्राउज़र-आधारित प्रोजेक्ट्स को नहीं बचाता है। पेज के सामने लगा प्रॉक्सी मॉडल एंडपॉइंट को सुरक्षित नहीं करता है, और उस पेज से किसी अलग होस्टनेम पर किया गया फेच (fetch) आपका सेशन कुकी नहीं ले जाता है। इसलिए Ollama के सामने लगा ऑथेंटिकेटिंग प्रॉक्सी लॉगिन फॉर्म पर रीडायरेक्ट कर देता है और चैट फेल हो जाती है। या तो मॉडल एंडपॉइंट को पेज वाले होस्टनेम के तहत ही रूट करें, या पहले पैटर्न का उपयोग करें।

किसे चुनें

यदि आपके अलावा कोई और इसका उपयोग करेगा, तो Open WebUI चलाएं। इसमें वास्तविक accounts होते हैं, नए users एक approval queue में आते हैं, और इसके maintainers hardening guidance प्रकाशित करते हैं जिसका आप पालन कर सकते हैं। यदि आपको LDAP या admin panel की आवश्यकता है, तो LibreChat चलाएं, और यह सुनिश्चित करें कि docker stats के साथ इसकी छह services और आपका model वास्तव में आपके hardware पर फिट बैठते हैं, इससे पहले कि आप उस पर निर्भर हों। यदि यह एक छोटे सर्वर पर केवल एक व्यक्ति के लिए है जहाँ model ने पहले ही अधिकांश RAM ले ली है, तो SSH tunnel के माध्यम से Hollama या OrionChat serve करें और browser को state संभालने दें। VPS पर गलत विकल्प यह है कि इनमें से किसी को भी बिना login के 0.0.0.0 पर public कर दिया जाए।

FAQ

क्या Open WebUI को सीधे पब्लिक IP पर expose करना सुरक्षित है?

इसका अपना hardening पेज इसे निजी, भरोसेमंद नेटवर्क के लिए बना सॉफ्टवेयर बताता है, जिसे डेटाबेस या CI सर्वर जैसी श्रेणी में रखा गया है। इसमें वास्तविक अकाउंट्स होते हैं, और पहला अकाउंट एडमिनिस्ट्रेटर बन जाता है जबकि बाद वाले अकाउंट्स तब तक pending रहते हैं जब तक उन्हें मंजूरी न मिल जाए, इसलिए यह बिना लॉगिन वाले UI की तुलना में काफी सुरक्षित है। फिर भी इसे TLS के साथ एक reverse proxy के पीछे रखें और जहाँ संभव हो, single sign-on का उपयोग करें। कंटेनर पोर्ट को 127.0.0.1:3000:8080 के रूप में पब्लिश करें ताकि Docker के अपने iptables नियम आपकी जानकारी के बिना इसे इंटरनेट के लिए न खोल सकें।

VPS पर कौन सा Open WebUI विकल्प सबसे कम RAM का उपयोग करता है?

ब्राउज़र-आधारित विकल्प, Hollama और OrionChat, क्योंकि एप्लिकेशन क्लाइंट पर चलती है। सर्वर केवल स्टेटिक फाइलें भेजता है, और OrionChat को किसी एप्लिकेशन कंटेनर की आवश्यकता ही नहीं होती। Open WebUI एक Python प्रोसेस, एक डेटाबेस और डिफ़ॉल्ट रूप से एक लोकल एम्बेडिंग मॉडल को मेमोरी में रखता है, जो केवल एम्बेडिंग मॉडल के लिए प्रति वर्कर लगभग 500 MB या उससे अधिक RAM लेता है। अपने सर्वर पर docker stats --no-stream के साथ इन आंकड़ों की पुष्टि करें, क्योंकि आपके द्वारा चालू किए गए फीचर्स के साथ ये बदलते रहते हैं।

क्या ये चैट UI किसी दूसरे होस्ट पर मौजूद Ollama सर्वर का उपयोग कर सकते हैं?

Open WebUI और LibreChat ऐसा कर सकते हैं, और इनका सर्वर कनेक्शन बनाता है, इसलिए ब्राउज़र का कोई नियम लागू नहीं होता। Open WebUI के लिए OLLAMA_BASE_URL सेट करें, या LibreChat के लिए कस्टम एंडपॉइंट में baseURL सेट करें। vLLM या किसी अन्य OpenAI-संगत सर्वर के लिए, OPENAI_API_BASE_URL का उपयोग उस बेस पाथ के साथ करें जो सर्वर के डॉक्यूमेंटेशन में दिया गया है, जो vLLM के लिए /v1 है, और API की केवल तभी जोड़ें यदि सर्वर को इसकी आवश्यकता हो। Hollama भी कहीं भी पॉइंट कर सकता है, लेकिन अनुरोध आपके ब्राउज़र से आता है, इसलिए एंडपॉइंट आपके ब्राउज़र से भी एक्सेस योग्य होना चाहिए। OrionChat ऐसा नहीं कर सकता: इसका Ollama एड्रेस http://localhost:11434 पर हार्डकोडेड है, इसलिए रिमोट Ollama केवल एक SSH टनल के माध्यम से काम करता है जो उस पोर्ट को फॉरवर्ड करता है।

मेरा ब्राउज़र चैट UI, Ollama तक क्यों नहीं पहुँच पा रहा है?

लगभग हर मामले में इसके दो कारण होते हैं। Ollama डिफ़ॉल्ट रूप से 127.0.0.1:11434 पर बाइंड होता है, इसलिए किसी अन्य मशीन पर मौजूद ब्राउज़र तब तक सीधे उस तक नहीं पहुँच सकता जब तक OLLAMA_HOST न बदला जाए या SSH टनल पोर्ट को फॉरवर्ड न करे। साथ ही, Ollama केवल localhost से क्रॉस-ऑरिजिन अनुरोधों को स्वीकार करता है, इसलिए आपके अपने डोमेन से सर्व किए गए पेज को No 'Access-Control-Allow-Origin' header is present on the requested resource के साथ तब तक अस्वीकार कर दिया जाता है जब तक कि वह ऑरिजिन OLLAMA_ORIGINS में सूचीबद्ध न हो। यदि पेज HTTPS है और एंडपॉइंट HTTP है, तो ब्राउज़र Ollama द्वारा देखे जाने से पहले ही इसे mixed content के रूप में ब्लॉक कर देता है। दोनों वेरिएबल्स को systemctl edit ollama.service ओवरराइड में सेट करें, या SSH के माध्यम से पोर्ट फॉरवर्ड करें और समस्या हल हो जाएगी।