VPS کے لیے بہترین Open WebUI متبادل کون سا ہے؟

VPS پر کون سا Open WebUI متبادل موزوں ہے

Open WebUI کے متبادل کا موازنہ تقریباً ہمیشہ laptop پر کیا جاتا ہے، جہاں RAM سستی ہوتی ہے اور کوئی سروس public address پر listening نہیں کر رہی ہوتی۔ VPS میں دونوں حقائق بدل جاتے ہیں، اور اس سے درجہ بندی بھی بدل جاتی ہے۔ جیسے ہی دوسرا شخص login کرتا ہے، Open WebUI موزوں default رہتا ہے، کیونکہ اس میں حقیقی user accounts اور admin panel شامل ہوتے ہیں۔ ہلکے projects اس وقت بہتر ثابت ہوتے ہیں جب interface کو RAM کی آخری gigabyte کے لیے model کے ساتھ وسائل میں مقابلہ کرنا پڑے۔ اس فائدے کی قیمت authentication ہے: ان میں یہ سہولت موجود نہیں ہوتی۔

ذیل کی تمام معلومات ہر project کی اپنی documentation سے لی گئی ہیں، جسے August 2026 میں پڑھا گیا تھا۔ یہ چار پہلو وہی ہیں جو box کے internet سے reachable ہونے کے بعد اہمیت اختیار کرتے ہیں۔

عوامی IP پر صرف یہ 4 پہلو اہم ہوتے ہیں

• ماڈل کے ساتھ موجود memory۔ model server اس مشین پر سب سے زیادہ وسائل استعمال کرنے والا process ہوتا ہے۔ interface جتنی بھی megabyte memory استعمال کرے گا، اتنی ہی memory model کے لیے کم رہ جائے گی۔
• Authentication۔ بعض projects میں user accounts اور roles موجود ہوتے ہیں۔ دیگر یہ فرض کرتے ہیں کہ وہ آپ کے laptop پر چلنے والی واحد application ہیں، اس لیے ان میں login موجود نہیں ہوتا۔
• Remote inference۔ ایسا UI جو صرف 127.0.0.1:11434 تک رسائی حاصل کر سکے، model کو interface والی اسی مشین پر چلانے پر مجبور کرتا ہے۔
• Upkeep۔ SQLite file کے ساتھ ایک container چلانا، MongoDB اور اس کے پیچھے vector database کے ساتھ 6 containers چلانے سے بالکل مختلف انتظامی کام ہے۔

انٹرفیس کے لیے ماڈل کتنی RAM چھوڑتا ہے

سرور پر سب سے زیادہ وسائل انٹرفیس استعمال نہیں کرتا۔ ماڈل کرتا ہے۔ شائع کردہ download sizes کم از کم حد بتاتے ہیں، کیونکہ ماڈل کے جوابات کے دوران weights میموری میں موجود رہنے چاہییں۔ context cache مختص ہونے کے بعد حقیقی memory use 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 میں دکھائے تھے۔ یہ published sizes ہیں، measurements نہیں۔ 4 GB VPS پر qwen3:4b کا 2.5 GB ہونا operating system اور باقی تمام چیزوں کے لیے 1.5 GB سے کم RAM چھوڑتا ہے۔ گفتگو بڑھنے کے ساتھ context cache بھی اس RAM میں سے حصہ لیتا ہے۔ اسی لیے آپ کا مقرر کردہ num_ctx memory کا فیصلہ بھی ہے، صرف quality کا نہیں۔ qwen3:8b کا 5.2 GB ہونا اس سرور پر بالکل قابلِ عمل نہیں۔ یہی صورتِ حال laptop roundups کبھی بیان نہیں کرتے۔ چند سو megabytes رکھنے والا chat interface یہ طے کر سکتا ہے کہ ماڈل چلتا ہے یا نہیں۔ اگر آپ ان tags سے کافی بڑے ماڈل کے لیے سرور کے وسائل مقرر کر رہے ہیں تو CPU-only VPS پر 27B model کا حساب دکھاتا ہے کہ interface کتنی تیزی سے وہ عدد نہیں رہتا جو کسی چیز کا فیصلہ کرے۔

Roundup میں دیے گئے کسی بھی عدد پر، اس عدد سمیت، اعتماد کرنے کے بجائے پیمائش کریں۔ حقیقی استعمال شروع ہونے کے ایک گھنٹے بعد docker stats --no-stream چلائیں، container شروع ہونے کے ایک منٹ بعد نہیں، کیونکہ اہم memory پہلے استعمال کے وقت مختص ہوتی ہے۔ Ollama پانچ منٹ تک idle رہنے کے بعد weights بھی release کرتا ہے۔ اس لیے گفتگو کے درمیان لی گئی reading peak کو کم ظاہر کرتی ہے۔ اگلا message دوبارہ پورا load برداشت کرتا ہے، جب تک کہ آپ keep_alive کے ذریعے model کو resident نہ رکھیں۔

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

project README میں دیا گیا command -p 3000:8080 کو publish کرتا ہے، جو ہر interface پر listen کرتا ہے۔ 127.0.0.1: prefix اسے loopback تک محدود رکھتا ہے۔ VPS پر یہ prefix line کی کسی بھی دوسری چیز سے زیادہ اہم ہے، کیونکہ 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 استعمال نہیں کر سکتا۔

Open WebUI نیچے دیے گئے projects سے زیادہ memory استعمال کرتا ہے، کیونکہ یہ زیادہ کام کرتا ہے۔ اس کے اپنے performance page میں ان memory costs کے اجزا درج ہیں۔ default embedding engine container کے اندر sentence-transformers model load کرتا ہے۔ documentation کے مطابق ہر worker process تقریباً 500 MB استعمال کرتا ہے۔ RAG_EMBEDDING_ENGINE=ollama set کرنے سے یہ کام اس 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 بڑھاتا ہے۔ اس لیے چھوٹے system پر DATABASE_POOL_SIZE=8 اور DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 set کریں۔ ENABLE_AUTOCOMPLETE_GENERATION=False اس وقت interface کو model سے completion مانگنے سے روکتا ہے جب صارف ابھی typing کر رہا ہو۔

LibreChat: متعدد صارفین کے لیے، اس کے پیچھے stack کے ساتھ

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

انٹرفیس 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 machine پر یہی 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 اسی مقصد کے لیے فراہم کرتا ہے، اور 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 کو اس machine کے address سے تبدیل کریں جہاں Ollama چل رہا ہے۔ apiKey field موجود ہونا ضروری ہے، اگرچہ Ollama اس کی value نظرانداز کرتا ہے؛ اس لیے placeholder بھی کافی ہے۔ اگر LibreChat Docker میں چل رہا ہو اور Ollama اسی machine پر چل رہا ہو تو container کے اندر localhost سے مراد خود container ہوتا ہے، اس لیے وہاں host.docker.internal استعمال کریں۔

Hollama اور OrionChat: کام browser کرتا ہے

Hollama ایک چھوٹے container سے browser application فراہم کرتا ہے۔ Chats سرور پر نہیں بلکہ آپ کے browser کے storage میں محفوظ رہتی ہیں۔

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

README میں موجود اس command میں --rm استعمال ہوتا ہے۔ یہ container کے رکنے پر اسے 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 فراہم کریں، یا disk سے index.html کھولیں۔ API keys browser کے localStorage میں محفوظ ہوتی ہیں، chat history browser میں رہتی ہے، اور chats کی تعداد 512 سے بڑھنے پر app قدیم ترین chats delete کر دیتی ہے۔

دونوں projects میں login نہیں ہے، کیونکہ کسی کے پاس ایسا server نہیں جو login کی تصدیق کر سکے۔ Laptop پر یہ مناسب ہے۔ VPS پر اس کا مطلب ہے کہ page کو کبھی بھی 0.0.0.0 پر publish نہیں کرنا چاہیے۔ اس کا ایک اور اہم نتیجہ ہے جسے نظرانداز کرنا آسان ہے: model کو server نہیں بلکہ browser call کرتا ہے۔

یہی حقیقت طے کرتی ہے کہ یہ دونوں کہاں قابل استعمال ہیں۔ آپ کے browser کو Ollama تک براہ راست پہنچنا ہوگا، اس لیے Ollama کو loopback کے علاوہ کسی address پر بھی listen کرنا ہوگا، اور Ollama میں کسی قسم کی authentication نہیں ہے۔ اس سے browser کے دو اصول سامنے آتے ہیں۔ HTTPS پر فراہم کیا گیا 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 کی call has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource کے ساتھ مسترد ہو جاتی ہے، جب تک آپ اس origin کی اجازت نہ دیں۔

Ollama میں دونوں settings تبدیل کرنے کا documented طریقہ 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 یا authentication کرنے والا proxy پہلے ہی یہ طے کر رہا ہو کہ port تک کون پہنچ سکتا ہے، کیونکہ کھلا ہوا 11434 ایک کھلا ہوا model server ہوتا ہے اور mass scanners نئے public port تک جلد پہنچ جاتے ہیں۔ ذیل میں دیا گیا SSH tunnel اس پورے مسئلے سے بچاتا ہے: اس صورت میں page localhost origin پر چلتا ہے، جس کی Ollama default طور پر اجازت دیتی ہے، اور port server سے باہر نہیں جاتا۔

کیا ہر ایک 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 کو غیر خالی OPENAI_API_KEY کے ساتھ set کریں، اور /v1 suffix برقرار رکھیں، کیونکہ یہ ضروری ہے۔ OPENAI_API_BASE_URLS میں semicolons سے جدا کیے گئے متعدد backends قبول کیے جاتے ہیں۔

LibreChat یہ کام اوپر دکھائے گئے custom endpoint کے baseURL کے ذریعے کر سکتا ہے۔ یہ request بھی server سے باہر جاتی ہے، اس لیے browser کا کوئی rule لاگو نہیں ہوتا۔ یہی base URL اور یہی placeholder key chat window کے باہر بھی کام کرتے ہیں۔ کسی coding agent کو اس model کی طرف بھیجنے کے لیے یہی کافی ہے جسے آپ پہلے ہی host کر رہے ہیں: اپنے موجودہ host کردہ model کی طرف coding agent بھیجیں۔

Hollama اور OrionChat اپنی settings میں درج کیے گئے کسی بھی endpoint کی طرف بھیجے جا سکتے ہیں، لیکن request آپ کے browser سے باہر جاتی ہے۔ اوپر والے section میں بیان کردہ ہر بات ان پر لاگو ہوتی ہے، اور یہاں کسی اور چیز پر نہیں۔

Interface کو model سے الگ کرنا remote endpoint کا سب سے مفید فائدہ ہے۔ Interface ایک چھوٹے box پر رکھیں اور model وہاں رکھیں جہاں memory موجود ہو۔ اسی مرحلے پر یہ فیصلہ بھی کریں کہ requests کے لیے Ollama استعمال کرنا ہے یا vLLM، کیونکہ ایک وقت میں متعدد افراد model سے بات کریں تو دونوں کا رویہ بہت مختلف ہوتا ہے۔ اگر model server ابھی موجود نہیں ہے تو پہلے VPS پر Ollama چلائیں، اور CPU-only box پر runner منتخب کرنے سے پہلے دیکھیں کہ Ollama کا llama.cpp سے کیا موازنہ ہے۔

0.0.0.0 پر login کے بغیر chat UI کبھی publish نہ کریں

Open WebUI کا hardening صفحہ بتاتا ہے کہ یہ project "built for private, trusted networks, similar to other self-hosted infrastructure like databases, container registries, and CI servers" ہے، اور اسے VPN کے پیچھے یا authentication والے reverse proxy کے پیچھے رکھنے کی ہدایت کرتا ہے۔ جس project میں بالکل login نہ ہو، اسے کم از کم اسی طرح محفوظ کرنا چاہیے۔

کسی بھی چیز پر اعتماد کرنے سے پہلے دیکھیں کہ کیا listening پر ہے۔

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

127.0.0.1:3000 پڑھنے والی line مطلوبہ حالت ہے۔ 0.0.0.0:3000 پڑھنے والی line کا مطلب ہے کہ آپ کا 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. پیغام دکھاتی ہے۔

Pattern one: 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 میں model port کو -L 11434:127.0.0.1:11434 کے ساتھ forward کریں اور Ollama کو loopback پر رہنے دیں۔ یہ pattern آپ کے SSH setup جتنا ہی مضبوط ہے، اس لیے اسے key-only SSH اور hardened sshd کے ساتھ استعمال کریں۔

Pattern two: ایسا reverse proxy جو app تک request پہنچنے سے پہلے authentication کرے۔ 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 نہیں کرتا: token اپنی مدت ختم ہونے تک قابل استعمال رہتا ہے۔

Pattern two صرف browser-only projects کو محفوظ نہیں کرتا۔ صفحے کے سامنے موجود proxy model endpoint کو محفوظ نہیں بناتا، اور اس صفحے سے کسی مختلف hostname کو بھیجی گئی fetch request میں آپ کی session cookie شامل نہیں ہوتی۔ اس لیے Ollama کے سامنے موجود authenticating proxy login form کی طرف redirect بھیجتا ہے اور chat ناکام ہو جاتی ہے۔ یا تو model endpoint کو صفحے والے ہی hostname کے تحت route کریں، یا pattern one استعمال کریں۔

کون سا منتخب کریں

اگر اسے آپ کے علاوہ کوئی اور بھی استعمال کرے گا تو Open WebUI چلائیں۔ اس میں حقیقی user accounts موجود ہیں، نئے users منظوری کی queue میں جاتے ہیں، اور اس کے maintainers ایسی hardening guidance شائع کرتے ہیں جس پر آپ عمل کر سکتے ہیں۔ اگر آپ کو LDAP یا admin panel درکار ہے تو LibreChat چلائیں، اور اس پر انحصار کرنے سے پہلے docker stats سے تصدیق کریں کہ اس کی 6 services اور آپ کا model واقعی موزوں ہیں۔ اگر یہ ایک چھوٹے box پر صرف ایک شخص کے لیے ہے، جہاں model پہلے ہی RAM کا بیشتر حصہ استعمال کر رہا ہے، تو Hollama یا OrionChat کو SSH tunnel کے ذریعے serve کریں اور state browser کے پاس رہنے دیں۔ VPS پر غلط انتخاب یہ ہے کہ ان میں سے کسی کو بھی 0.0.0.0 پر login کے بغیر public کر دیا جائے۔

FAQ

کیا Open WebUI کو براہ راست public IP پر expose کرنا محفوظ ہے؟

اس کا hardening صفحہ اسے private، trusted networks کے لیے software قرار دیتا ہے، یعنی database یا CI server ہی کے زمرے میں۔ اس میں حقیقی user accounts موجود ہیں۔ پہلا account administrator بن جاتا ہے، جبکہ بعد کے accounts منظوری تک pending رہتے ہیں۔ اس لیے یہ ایسی UI سے کہیں زیادہ محفوظ ہے جس میں login موجود نہ ہو۔ پھر بھی اسے TLS والے reverse proxy کے پیچھے رکھیں اور جہاں ممکن ہو single sign-on استعمال کریں۔ Container port کو 127.0.0.1:3000:8080 کے طور پر publish کریں تاکہ Docker کے اپنے iptables rules آپ کی اجازت کے بغیر اسے internet پر expose نہ کر سکیں۔

VPS پر Open WebUI کا کون سا متبادل کم سے کم RAM استعمال کرتا ہے؟

Browser-based ایپس، یعنی Hollama اور OrionChat، کیونکہ application client پر چلتی ہے۔ Server صرف static files بھیجتا ہے، اور OrionChat کو application container کی بھی ضرورت نہیں ہوتی۔ Open WebUI ایک Python process، ایک database اور، default طور پر، ایک local embedding model کو memory میں رکھتا ہے۔ دستاویزات کے مطابق صرف embedding model کے لیے ہر worker تقریباً 500 MB استعمال کرتا ہے۔ اپنے server پر 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 بھی کسی بھی endpoint کی طرف point کر سکتے ہیں، لیکن request آپ کے browser سے آتی ہے۔ اس لیے endpoint آپ کے browser سے بھی reachable ہونا چاہیے۔

میرا browser chat UI Ollama تک کیوں نہیں پہنچ سکتا؟

تقریباً ہر case کی دو وجوہات ہوتی ہیں۔ Ollama default طور پر 127.0.0.1:11434 پر bind ہوتا ہے، اس لیے دوسرے machine پر موجود 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 Ollama تک request پہنچنے سے پہلے اسے mixed content کے طور پر block کر دیتا ہے۔ دونوں variables کو systemctl edit ollama.service override میں مقرر کریں، یا port کو SSH کے ذریعے forward کریں؛ اس سے مسئلہ ختم ہو جاتا ہے۔