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 सिस्टम नहीं होता।
• Remote inference। एक UI जो केवल 127.0.0.1:11434 तक पहुँच सकता है, वह model को interface वाले ही box पर चलाने के लिए मजबूर करता है।
• 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.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

ये वे आंकड़े हैं जो अगस्त 2026 में Ollama लाइब्रेरी पेजों पर प्रकाशित किए गए थे। ये प्रकाशित साइज़ हैं, माप नहीं। 4 GB के VPS पर, qwen3:4b जिसका साइज़ 2.5 GB है, ऑपरेटिंग सिस्टम और अन्य सभी चीज़ों के लिए 1.5 GB से कम जगह छोड़ता है। जैसे-जैसे बातचीत बढ़ती है, 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 एक ही इमेज से चलता है और अपना डेटा एक ही वॉल्यूम में रखता है।

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 को पब्लिश करता है, जो हर इंटरफ़ेस पर लिसन करता है। 127.0.0.1: प्रीफ़िक्स इसे लूपबैक पर ही रखता है। एक VPS पर वह प्रीफ़िक्स लाइन पर मौजूद किसी भी अन्य चीज़ से अधिक मायने रखता है, क्योंकि Docker अपने स्वयं के iptables नियम लिखता है और एक पब्लिश किया गया पोर्ट आपके ufw deny नियमों को अनदेखा कर देता है।

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

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

LibreChat: मल्टी-यूज़र, और इसके पीछे का स्टैक

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

इसका इंटरफ़ेस port 3080 पर प्रतिक्रिया देता है। जब आपको केवल एक लॉगिन बॉक्स के बजाय एक पहचान प्रणाली (identity system) की आवश्यकता हो, तो LibreChat पर विचार करें: यह LDAP और OAuth2 लॉगिन को डॉक्यूमेंट करता है, और इसमें उपयोगकर्ताओं और भूमिकाओं (roles) के लिए एक एडमिन पैनल शामिल है। यह क्षमता एक स्टैक के साथ आती है।

[
  {
    "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 वाले बॉक्स पर यह वही मेमोरी है जिसकी मॉडल को आवश्यकता थी।

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

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

यदि आपने ट्रैक की गई docker-compose.yml फ़ाइल को एडिट किया है, तो git pull संघर्ष (conflict) के साथ रुक जाता है, और फिर अपग्रेड आधा-अधूरा लागू होता है। अपने बदलावों को docker-compose.override.yml में रखें, जिसे प्रोजेक्ट ने इसी उद्देश्य के लिए प्रदान किया है, और secrets को .env में रखें। ये दोनों फ़ाइलें untracked होती हैं, इसलिए 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 एक छोटे container से ब्राउज़र एप्लिकेशन सर्व करता है। चैट आपके ब्राउज़र के स्टोरेज में रहती हैं, सर्वर पर नहीं।

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

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

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

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

यह एक तथ्य तय करता है कि ये दोनों कहाँ उपयोग करने योग्य हैं। आपके ब्राउज़र को सीधे Ollama तक पहुँचना होगा, इसलिए Ollama को loopback से अधिक पर listen करना होगा, और Ollama में किसी भी प्रकार का प्रमाणीकरण (authentication) नहीं है। इसके परिणामस्वरूप दो ब्राउज़र नियम लागू होते हैं। HTTPS पर सर्व किया गया पेज plain HTTP endpoint को कॉल नहीं कर सकता है, और कंसोल 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 के कॉल को has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource के साथ तब तक अस्वीकार कर दिया जाता है जब तक आप उस origin को अनुमति नहीं देते।

इन सेटिंग्स को बदलने का 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

ss को अब 0.0.0.0:11434 प्रिंट करना चाहिए जहाँ यह पहले 127.0.0.1:11434 प्रिंट करता था। यह बदलाव केवल तब करें जब कोई firewall या authenticating proxy पहले से नियंत्रित कर रहा हो कि पोर्ट तक कौन पहुँच सकता है, क्योंकि एक खुला 11434 एक खुला मॉडल सर्वर है और मास स्कैनर्स जल्दी ही एक नए पब्लिक पोर्ट तक पहुँच जाते हैं। नीचे दी गई SSH टनल पूरे प्रश्न से बचाती है: पेज तब localhost origin पर चलता है, जिसकी Ollama डिफ़ॉल्ट रूप से अनुमति देता है, और पोर्ट कभी भी बॉक्स से बाहर नहीं जाता है।

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

Open WebUI ऐसा कर सकता है, और कनेक्शन सर्वर साइड पर बनता है। OLLAMA_BASE_URL=http://model-host:11434 इसे Ollama की ओर निर्देशित करता है। vLLM या किसी अन्य OpenAI-संगत सर्वर के लिए, OPENAI_API_BASE_URL=http://model-host:8000/v1 को एक नॉन-एम्प्टी OPENAI_API_KEY के साथ सेट करें, और /v1 सफिक्स को बनाए रखें, जो कि आवश्यक है। OPENAI_API_BASE_URLS सेमीकोलन द्वारा अलग किए गए कई बैकएंड को स्वीकार करता है।

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

Hollama और OrionChat किसी भी ऐसे एंडपॉइंट पर पॉइंट कर सकते हैं जिसे आप उनकी सेटिंग्स में टाइप करते हैं, लेकिन अनुरोध आपके ब्राउज़र से बाहर निकल जाता है। ऊपर दिए गए सेक्शन की हर बात उन पर लागू होती है और यहाँ किसी और चीज़ पर नहीं।

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

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

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

किसी भी चीज़ पर भरोसा करने से पहले यह जाँच लें कि कौन सा पोर्ट listening मोड में है।

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

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

Open WebUI के लॉगिन को WEBUI_AUTH=False के साथ बंद करना केवल उन सिंगल-यूजर मशीनों के लिए है जहाँ कोई और नहीं पहुँच सकता। यदि इंस्टॉलेशन में पहले से ही अकाउंट्स मौजूद हैं, तो यह सेटिंग लागू नहीं होगी और You can't turn off authentication because there are existing users. संदेश दिखाई देगा।

पहला तरीका: 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 को loopback पर ही रहने दें। यह तरीका केवल आपके SSH सेटअप जितना ही मजबूत है, इसलिए इसे key-only SSH और एक सुरक्षित sshd के साथ उपयोग करें।

दूसरा तरीका: एक रिवर्स प्रॉक्सी जो ऐप तक रिक्वेस्ट पहुँचने से पहले ऑथेंटिकेशन करे। ऐप को loopback पर रखें, प्रॉक्सी को पोर्ट 443 संभालने दें, और सामने सिंगल साइन-ऑन लगाएँ। Docker Compose labels द्वारा संचालित 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 को सीधे public 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 प्रति वर्कर के रूप में दर्ज है। अपने सर्वर पर docker stats --no-stream के साथ इन आंकड़ों की पुष्टि करें, क्योंकि आपके द्वारा चालू किए गए फीचर्स के साथ ये बदलते रहते हैं।

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

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

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

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