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 पर मायने रखते हैं

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

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

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

[
  {
    "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 इसमें से और मेमोरी ले लेता है। qwen3:8b जिसका आकार 5.2 GB है, वह उस सर्वर पर बिल्कुल भी फिट नहीं होता है। यह वह स्थिति है जिसे लैपटॉप राउंडअप कभी कवर नहीं करते हैं, और यहीं पर कुछ सौ मेगाबाइट लेने वाला चैट इंटरफ़ेस यह तय करता है कि मॉडल चलेगा या नहीं।

राउंडअप में दिए गए किसी भी नंबर पर भरोसा करने के बजाय उसे मापें, जिसमें यह भी शामिल है। वास्तविक उपयोग के एक घंटे बाद docker stats --no-stream चलाएं, न कि कंटेनर शुरू होने के एक मिनट बाद, क्योंकि जो मेमोरी मायने रखती है वह पहली बार उपयोग करने पर allocate होती है।

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

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

Open WebUI नीचे दिए गए प्रोजेक्ट्स की तुलना में अधिक memory लेता है क्योंकि यह अधिक कार्य करता है, और इसका अपना performance पेज उन हिस्सों के नाम बताता है जो इसकी लागत बढ़ाते हैं। डिफ़ॉल्ट embedding engine container के अंदर एक sentence-transformers model लोड करता है, जो प्रति worker process लगभग 500 MB का होता है। RAG_EMBEDDING_ENGINE=ollama सेट करने से वह कार्य उस model server को सौंप दिया जाता है जिसे आप पहले से चला रहे हैं। AUDIO_STT_ENGINE=webapi एक local speech-to-text model को लोड होने से रोकता है। SQLite पर, यदि DATABASE_POOL_SIZE unset है, तो pool एक बड़े internal size पर वापस चला जाता है और प्रत्येक connection अपना स्वयं का page cache और memory map बढ़ाता है, इसलिए एक छोटे box पर DATABASE_POOL_SIZE=8 और DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 सेट करें। ENABLE_AUTOCOMPLETE_GENERATION=False इंटरफ़ेस को तब model से completion मांगने से रोकता है जब उपयोगकर्ता अभी भी टाइप कर रहा हो।

LibreChat: multi-user, एक stack के साथ

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 को document करता है, और इसमें 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"
  }
]

डिफ़ॉल्ट compose file 6 services को start करती है: 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 को edit किया है, तो git pull एक conflict के साथ रुक जाता है, और फिर upgrade आधा ही लागू हो पाता है। अपने बदलावों को docker-compose.override.yml में रखें, जिसे project ने इसी उद्देश्य के लिए प्रदान किया है, और secrets को .env में रखें। ये दोनों files untracked होती हैं, इसलिए git pull उन्हें नहीं छेड़ता है।

LibreChat को librechat.yaml में custom endpoint के साथ अपने स्वयं के model server पर point करें।

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 से बदलें। apiKey field का मौजूद होना आवश्यक है, भले ही Ollama इसके value को ignore कर दे, इसलिए एक placeholder भी काम करेगा। यदि LibreChat Docker में चलता है और Ollama उसी machine पर चल रहा है, तो container के अंदर localhost का अर्थ container स्वयं होता है, इसलिए वहाँ इसके बजाय 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 को डिलीट कर देता है, इसलिए रीबूट के बाद इंटरफ़ेस वापस नहीं आता है। Reverse proxy के पीछे, -e VITE_ALLOWED_HOSTS='chat.example.com' जोड़ें, क्योंकि image केवल host localhost की अनुमति देती है और किसी अन्य hostname के अनुरोध का उत्तर ऐप के बजाय blocked-host एरर के साथ देती है।

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

FAQ

क्या हर कोई रिमोट Ollama या vLLM endpoint का उपयोग कर सकता है?

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

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

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

इंटरफ़ेस को मॉडल से अलग करना वह सबसे उपयोगी लाभ है जो एक रिमोट endpoint आपको देता है। इंटरफ़ेस को एक छोटे बॉक्स पर रखें और मॉडल को वहाँ रखें जहाँ मेमोरी उपलब्ध है। यह तय करने का भी सही समय है कि 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 पर bind करें और इसे 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 वास्तव में उस पर निर्भर होने से पहले फिट बैठते हैं या नहीं। यदि यह एक छोटे सर्वर पर एक व्यक्ति के लिए है जहाँ model ने पहले ही अधिकांश RAM ले ली है, तो SSH tunnel के माध्यम से Hollama या OrionChat serve करें और browser को state संभालने दें। VPS पर गलत विकल्प यह है कि इनमें से किसी को भी बिना login के 0.0.0.0 पर प्रकाशित कर दिया जाए।

FAQ

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

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

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

Browser-आधारित विकल्प, जैसे Hollama और OrionChat, क्योंकि application client पर चलती है। सर्वर केवल static files भेजता है, और OrionChat को किसी application container की आवश्यकता ही नहीं होती। Open WebUI एक Python process, एक database और डिफ़ॉल्ट रूप से एक local embedding model को memory में रखता है, जो केवल embedding model के लिए प्रति worker लगभग 500 MB RAM लेता है। अपने सर्वर पर docker stats --no-stream के साथ इन आंकड़ों की पुष्टि करें, क्योंकि आपके द्वारा चालू की गई सुविधाओं के अनुसार ये बदलते रहते हैं।

क्या ये chat UI किसी अन्य host पर स्थित Ollama server का उपयोग कर सकते हैं?

Open WebUI और LibreChat ऐसा कर सकते हैं, और इनका सर्वर ही connection बनाता है, इसलिए browser का कोई नियम लागू नहीं होता। Open WebUI के लिए OLLAMA_BASE_URL सेट करें, या LibreChat के लिए custom endpoint में baseURL का उपयोग करें। vLLM या किसी अन्य OpenAI-compatible सर्वर के लिए, /v1 suffix के साथ OPENAI_API_BASE_URL का उपयोग करें और एक non-empty API key प्रदान करें। Hollama और OrionChat भी कहीं भी point कर सकते हैं, लेकिन अनुरोध आपके browser से आता है, इसलिए endpoint का आपके browser से पहुंच योग्य होना आवश्यक है।

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

लगभग सभी मामलों में इसके दो कारण होते हैं। Ollama डिफ़ॉल्ट रूप से 127.0.0.1:11434 पर bind होता है, इसलिए किसी अन्य मशीन का browser तब तक उस तक नहीं पहुँच सकता जब तक OLLAMA_HOST को बदला न जाए। साथ ही, 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 है, तो browser इसे mixed content मानकर block कर देता है, इससे पहले कि Ollama उसे देख सके। दोनों variables को एक systemctl edit ollama.service override में सेट करें, या SSH के माध्यम से port forward करें, जिससे यह समस्या समाप्त हो जाएगी।