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 ہے: ان میں authentication موجود نہیں۔

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

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

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

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

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

کسی roundup میں موجود کسی بھی عدد پر، بشمول اس کے، بھروسا کرنے کے بجائے خود پیمائش کریں۔ docker stats --no-stream کو حقیقی استعمال شروع ہونے کے ایک گھنٹے بعد چلائیں، container start ہونے کے ایک منٹ بعد نہیں، کیونکہ اہم memory پہلی بار استعمال کے وقت allocate ہوتی ہے۔

Open WebUI: ایک سے زیادہ صارفین کے لیے اب بھی پہلے سے طے شدہ ترتیب

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 پر listening کرتا ہے۔ 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 استعمال نہیں کر سکتا۔

Open WebUI نیچے دیے گئے projects کے مقابلے میں زیادہ memory استعمال کرتا ہے، کیونکہ یہ زیادہ کام کرتا ہے، اور اس کے اپنے performance page میں ان اجزا کے نام درج ہیں جو memory استعمال کرتے ہیں۔ 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 پر واپس چلا جاتا ہے، اور ہر connection اپنا page cache اور memory map بناتا ہے۔ اس لیے چھوٹی machine پر 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

interface پورٹ 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 مشین پر یہ وہ memory ہے جو model کو درکار تھی۔

Upgrades ایک git operation ہیں، اور یہی وہ حصہ ہے جس میں لوگ عموماً غلطی کرتے ہیں۔

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

git pull تنازع کے ساتھ رک جاتا ہے اگر آپ نے tracked docker-compose.yml میں ترمیم کی ہو، اور پھر upgrade جزوی طور پر apply ہوتا ہے۔ اپنی تبدیلیاں 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 کو اس 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 server پر نہیں بلکہ آپ کے 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 کریں اور اس folder کو اپنے پہلے سے چلنے والے web server سے serve کریں، یا 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 پر 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 کو call کرنے پر has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource کے ساتھ request مسترد کر دی جاتی ہے، جب تک آپ اس 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 سرور سے باہر نہیں جاتا۔

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

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

0.0.0.0 پر login کے بغیر chat UI ہرگز شائع نہ کریں

Open WebUI کے hardening صفحے کے مطابق یہ project "نجی، قابل اعتماد networks کے لیے بنایا گیا ہے، جیسے databases، container registries اور CI servers جیسا دیگر self-hosted infrastructure"، اور اس میں کہا گیا ہے کہ اسے VPN کے پیچھے یا authentication والے reverse proxy کے پیچھے رکھیں۔ جس project میں login بالکل نہ ہو، اسے کم از کم یہی تحفظ دینا چاہیے۔

کسی بھی چیز پر اعتماد کرنے سے پہلے دیکھیں کہ کیا 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. پیغام دکھائی دیتا ہے۔

طریقہ 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 نہیں ہوتا، اس لیے کوئی چیز scan نہیں کی جا سکتی۔ Hollama یا OrionChat کے لیے اسی command میں -L 11434:127.0.0.1:11434 کے ذریعے model port بھی forward کریں اور Ollama کو loopback پر رہنے دیں۔ یہ طریقہ آپ کے SSH setup جتنا ہی مضبوط ہے، اس لیے اسے صرف key والا SSH اور hardened sshd کے ساتھ استعمال کریں۔

طریقہ 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 set کریں۔ JWT_EXPIRES_IN کو اس کی default مدت، یعنی چار ہفتوں، سے بھی کم کریں، کیونکہ Open WebUI کی documentation کے مطابق Redis کے بغیر sign-out token کو invalidate نہیں کرتا: token اپنی مدت ختم ہونے تک قابل استعمال رہتا ہے۔

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

کسے منتخب کریں

اگر اسے آپ کے علاوہ کوئی اور بھی استعمال کرے گا تو Open WebUI چلائیں۔ اس میں حقیقی user accounts موجود ہیں، نئے users approval queue میں جاتے ہیں، اور اس کے maintainers ایسی hardening guidance شائع کرتے ہیں جس پر آپ عمل کر سکتے ہیں۔ اگر آپ کو LDAP یا admin panel درکار ہے تو LibreChat چلائیں، اور docker stats سے تصدیق کریں کہ اس کی چھ 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 ہی کے زمرے میں۔ اس میں حقیقی 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 اور، by 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 کے لیے OPENAI_API_BASE_URL کو /v1 suffix کے ساتھ استعمال کریں اور API key خالی نہ رکھیں۔ Hollama اور OrionChat بھی کسی بھی host کی طرف point کر سکتے ہیں، لیکن request آپ کے browser سے بھیجی جاتی ہے۔ اس لیے endpoint آپ کے browser سے بھی reachable ہونا چاہیے۔

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

تقریباً ہر case کی وجہ دو مسائل میں سے ایک ہوتی ہے۔ Ollama by 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 کے ساتھ refuse ہو جاتا ہے، جب تک اس origin کو OLLAMA_ORIGINS میں درج نہ کیا جائے۔ اگر page HTTPS پر ہو اور endpoint HTTP پر، تو browser Ollama تک request پہنچنے سے پہلے اسے mixed content کے طور پر block کر دیتا ہے۔ دونوں variables کو systemctl edit ollama.service override میں set کریں، یا port کو SSH کے ذریعے forward کریں؛ اس سے مسئلہ ختم ہو جاتا ہے۔