بهترین جایگزین Open WebUI برای اجرا روی VPS

کدام جایگزین Open WebUI برای اجرا روی VPS مناسب است

جایگزین‌های Open WebUI تقریباً همیشه روی لپ‌تاپ مقایسه می‌شوند؛ جایی که رم ارزان است و هیچ سرویسی روی آدرس عمومی گوش نمی‌دهد. یک VPS هر دو واقعیت را تغییر می‌دهد و در نتیجه رتبه‌بندی نیز تغییر می‌کند. Open WebUI به محض اینکه نفر دومی وارد سیستم شود، گزینه پیش‌فرض مناسب باقی می‌ماند، زیرا دارای حساب‌های کاربری واقعی و پنل مدیریت است. پروژه‌های سبک‌تر زمانی برنده می‌شوند که رابط کاربری برای آخرین گیگابایت رم با مدل رقابت می‌کند. بهای این پیروزی، احراز هویت است: آن‌ها هیچ‌کدام احراز هویت ندارند.

تمام مطالب زیر از مستندات خود پروژه‌ها استخراج شده و در اوت 2026 مطالعه شده است. چهار محور مورد بحث، مواردی هستند که تنها زمانی اهمیت پیدا می‌کنند که سرور از طریق اینترنت در دسترس باشد.

چهار محور حیاتی برای سرویس‌های دارای IP عمومی

• حافظه در کنار مدل. سرور مدل، پرهزینه‌ترین پردازش روی سیستم است. هر مگابایتی که رابط کاربری اشغال کند، مگابایتی است که از دسترس مدل خارج می‌شود.
• احراز هویت. برخی از این پروژه‌ها دارای حساب کاربری و نقش هستند. برخی دیگر فرض را بر این می‌گذارند که تنها برنامه در حال اجرا روی لپ‌تاپ شما هستند و هیچ‌گونه سیستم ورود (login) ندارند.
• استنتاج از راه دور (Remote inference). رابط کاربری که فقط به 127.0.0.1:11434 دسترسی دارد، مدل را مجبور می‌کند روی همان سیستمی اجرا شود که رابط کاربری قرار دارد.
• نگهداری. یک کانتینر با یک فایل SQLite، وظیفه‌ای متفاوت از شش کانتینر با MongoDB و یک پایگاه داده برداری در پشت آن‌ها است.

مدل چه مقدار رم برای رابط کاربری باقی می‌گذارد

رابط کاربری بزرگ‌ترین بخش روی سرور نیست؛ مدل است. حجم‌های دانلودی که منتشر می‌شوند، حداقل مقدار مورد نیاز را نشان می‌دهند، زیرا وزن‌ها (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"
  }
]

این‌ها ارقامی هستند که صفحات کتابخانه Ollama در اوت 2026 منتشر کرده‌اند. این‌ها حجم‌های اعلام‌شده هستند، نه اندازه‌گیری‌های دقیق. روی یک VPS با 4 گیگابایت رم، مدل qwen3:4b با 2.5 گیگابایت، کمتر از 1.5 گیگابایت برای سیستم‌عامل و سایر موارد باقی می‌گذارد و با طولانی‌تر شدن گفتگو، context cache از همین مقدار باقی‌مانده نیز می‌کاهد؛ به همین دلیل است که مقدار num_ctx که تنظیم می‌کنید، بیش از آنکه یک تصمیم کیفی باشد، یک تصمیم مربوط به حافظه است. مدل qwen3:8b با 5.2 گیگابایت اصلاً روی آن سرور اجرا نمی‌شود. این وضعیتی است که بررسی‌های لپ‌تاپ‌ها هرگز به آن نمی‌پردازند و جایی است که یک رابط کاربری چت که چند صد مگابایت اشغال می‌کند، تعیین می‌کند که آیا مدل اجرا می‌شود یا خیر. اگر در حال انتخاب سروری برای مدل‌هایی بسیار بزرگ‌تر از این برچسب‌ها هستید، محاسبات مربوط به یک مدل 27B روی یک VPS بدون GPU نشان می‌دهد که چقدر سریع رابط کاربری دیگر عددی نیست که تعیین‌کننده باشد.

به جای اعتماد به هر عددی در بررسی‌ها، از جمله این مورد، خودتان اندازه‌گیری کنید. دستور docker stats --no-stream را یک ساعت پس از استفاده واقعی اجرا کنید، نه یک دقیقه بعد از شروع کانتینر، زیرا حافظه‌ای که اهمیت دارد در اولین استفاده تخصیص می‌یابد. Ollama همچنین وزن‌ها را پس از پنج دقیقه بیکاری آزاد می‌کند، بنابراین خواندن وضعیت بین دو گفتگو، مقدار اوج مصرف را کمتر از واقعیت نشان می‌دهد و پیام بعدی دوباره تمام بار را تحمیل می‌کند، مگر اینکه با استفاده از 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 را منتشر می‌کند که روی تمام اینترفیس‌ها گوش می‌دهد. پیشوند 127.0.0.1: آن را روی loopback محدود نگه می‌دارد. در یک VPS، این پیشوند از هر چیز دیگری در آن خط اهمیت بیشتری دارد، زیرا داکر قوانین iptables خودش را می‌نویسد و پورت منتشرشده، قوانین deny در ufw شما را نادیده می‌گیرد.

از طریق یک تونل یا پروکسی (که هر دو در ادامه توضیح داده شده‌اند) به صفحه دسترسی پیدا کنید و سپس اولین حساب کاربری را بسازید. آن حساب به مدیر (administrator) تبدیل می‌شود. ثبت‌نام‌های بعدی با نقش pending ایجاد می‌شوند که مقدار پیش‌فرض مستندشده DEFAULT_USER_ROLE است؛ بنابراین یک غریبه که به صفحه دسترسی پیدا کند، تا زمانی که یک مدیر او را تایید نکند، نمی‌تواند از مدل شما استفاده کند.

Open WebUI نسبت به پروژه‌های زیر حافظه بیشتری مصرف می‌کند، زیرا کارهای بیشتری انجام می‌دهد و صفحه عملکرد (performance) خودِ برنامه، بخش‌هایی که باعث این مصرف می‌شوند را نام می‌برد. موتور embedding پیش‌فرض، یک مدل sentence-transformers را درون container بارگذاری می‌کند که طبق مستندات، حدود 500 مگابایت به ازای هر پردازش worker است. تنظیم RAG_EMBEDDING_ENGINE=ollama این وظیفه را به سرور مدلی که از قبل اجرا کرده‌اید می‌سپارد. AUDIO_STT_ENGINE=webapi از بارگذاری یک مدل محلی تبدیل گفتار به متن (speech-to-text) جلوگیری می‌کند. در SQLite، اگر DATABASE_POOL_SIZE تنظیم نشده باشد، pool به یک اندازه داخلی بزرگ بازمی‌گردد و هر اتصال، page cache و memory map اختصاصی خود را رشد می‌دهد؛ بنابراین در یک سرور کوچک، DATABASE_POOL_SIZE=8 و DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 را تنظیم کنید. ENABLE_AUTOCOMPLETE_GENERATION=False از اینکه رابط کاربری در حین تایپ کاربر از مدل درخواست تکمیل متن (completion) کند، جلوگیری می‌کند.

LibreChat: چندکاربره، به همراه یک پشته نرم‌افزاری

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

رابط کاربری روی پورت 3080 پاسخ می‌دهد. زمانی که به یک سیستم احراز هویت نیاز دارید و نه فقط یک کادر ورود ساده، LibreChat گزینه مناسبی است: این برنامه مستنداتی برای ورود از طریق LDAP و OAuth2 ارائه می‌دهد و شامل یک پنل مدیریت برای کاربران و نقش‌ها است. این قابلیت به همراه یک پشته (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 پیش‌فرض، 6 سرویس را اجرا می‌کند: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. هیچ‌کدام از آن‌ها مدل هوش مصنوعی نیستند. MongoDB و pgvector هر کدام حافظه اختصاصی خود را می‌طلبند و در یک سرور 4 گیگابایتی، این همان حافظه‌ای است که مدل به آن نیاز دارد.

ارتقاها یک عملیات git هستند، بخشی که معمولاً افراد در آن دچار اشتباه می‌شوند.

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

دستور git pull در صورت ویرایش فایل‌های ردیابی‌شده docker-compose.yml با تداخل مواجه می‌شود و ارتقا به‌صورت ناقص اعمال می‌گردد. تغییرات خود را در docker-compose.override.yml اعمال کنید که پروژه برای همین منظور در نظر گرفته است و اسرار (secrets) را در .env نگه دارید. هر دو فایل untracked هستند، بنابراین git pull آن‌ها را تغییر نمی‌دهد.

LibreChat را با استفاده از یک endpoint سفارشی در 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 مقدار آن را نادیده می‌گیرد، بنابراین استفاده از یک مقدار جایگزین (placeholder) کافی است. اگر 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 استفاده می‌کند که کانتینر را پس از توقف حذف می‌کند، بنابراین رابط کاربری پس از reboot باز نمی‌گردد. پشت یک reverse proxy، باید -e VITE_ALLOWED_HOSTS='chat.example.com' را اضافه کنید، زیرا این ایمیج فقط اجازه استفاده از host localhost را می‌دهد و به درخواست برای هر hostname دیگری، به جای اپلیکیشن، خطای blocked-host پاسخ می‌دهد.

OrionChat فراتر می‌رود و اصلاً هیچ جزء سمت سروری ندارد. مخزن را clone کنید و پوشه را با وب‌سروری که از قبل اجرا می‌کنید ارائه دهید، یا index.html را از روی دیسک باز کنید. کلیدهای API در localStorage مرورگر ذخیره می‌شوند، تاریخچه چت در مرورگر باقی می‌ماند و اپلیکیشن پس از عبور تعداد چت‌ها از 512، قدیمی‌ترین آن‌ها را حذف می‌کند.

هیچ‌کدام از این دو پروژه سیستم ورود (login) ندارند، زیرا هیچ‌کدام سروری ندارند که بتواند آن را بررسی کند. روی لپ‌تاپ این موضوع مشکلی ندارد. روی یک VPS، این یعنی صفحه نباید هرگز روی 0.0.0.0 منتشر شود، و نکته‌ای را در بر دارد که نادیده گرفتن آن آسان‌تر است: مرورگر است که مدل را فراخوانی می‌کند، نه سرور.

همین یک واقعیت تعیین می‌کند که این دو کجا قابل استفاده هستند. مرورگر شما باید مستقیماً به Ollama دسترسی داشته باشد، بنابراین Ollama باید روی چیزی فراتر از loopback گوش دهد و Ollama هیچ نوع احراز هویتی ندارد. دو قانون مرورگر از این موضوع ناشی می‌شود. صفحه‌ای که از طریق HTTPS ارائه می‌شود نمی‌تواند یک endpoint ساده 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. را چاپ می‌کند. فراخوانی به هر 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 زیر کل این مسئله را حل می‌کند: صفحه در این حالت روی یک origin localhost اجرا می‌شود که Ollama به‌صورت پیش‌فرض آن را مجاز می‌داند و پورت هرگز از سرور خارج نمی‌شود.

آیا هر کدام می‌توانند از یک endpoint راه دور 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 چندین backend را که با نقطه-ویرگول از هم جدا شده‌اند، می‌پذیرد.

LibreChat می‌تواند از طریق baseURL مربوط به endpoint سفارشی که در بالا نشان داده شد، این کار را انجام دهد. آن درخواست نیز از سرور خارج می‌شود، بنابراین هیچ قانون مرورگری در مورد آن صدق نمی‌کند. همان base URL و همان کلید جایگزین (placeholder key) خارج از پنجرهٔ چت نیز کار می‌کنند، که این تمام چیزی است که برای هدایت یک coding agent به مدلی که از قبل میزبانی کرده‌اید نیاز دارید.

Hollama و OrionChat می‌توانند به هر endpoint که در تنظیماتشان وارد کنید اشاره کنند، اما درخواست از مرورگر شما خارج می‌شود. تمام موارد ذکر شده در بخش قبل، فقط برای آن‌ها صدق می‌کند و نه برای هیچ مورد دیگری در اینجا.

جدا کردن رابط کاربری از مدل، مفیدترین مزیت استفاده از یک endpoint راه دور است. رابط کاربری را روی یک دستگاه کوچک و مدل را در جایی که حافظه کافی وجود دارد قرار دهید. این همچنین زمانی است که باید تصمیم بگیرید آیا Ollama یا vLLM باید به درخواست‌ها پاسخ دهند، زیرا وقتی چندین نفر همزمان با مدل صحبت می‌کنند، رفتار این دو بسیار متفاوت است. اگر سرور مدل هنوز وجود ندارد، با اجرای Ollama روی یک VPS شروع کنید و اگر از دستگاهی استفاده می‌کنید که فقط CPU دارد، پیش از انتخاب runner، مقایسه Ollama با llama.cpp را مطالعه کنید.

هرگز یک رابط کاربری چت بدون ورود به سیستم را روی 0.0.0.0 منتشر نکنید

صفحه hardening پروژه Open WebUI بیان می‌کند که این پروژه «برای شبکه‌های خصوصی و قابل‌اعتماد ساخته شده است، مشابه سایر زیرساخت‌های self-hosted مانند دیتابیس‌ها، container registryها و سرورهای CI» و به شما توصیه می‌کند آن را پشت یک VPN یا یک reverse proxy دارای احراز هویت قرار دهید. پروژه‌ای که اصلاً صفحه ورود ندارد، حداقل به همین سطح از مراقبت نیاز دارد.

پیش از آنکه به هر چیزی اعتماد کنید، بررسی کنید چه چیزی در حال گوش دادن (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. را نمایش می‌دهد.

الگوی اول: bind کردن روی loopback و دسترسی از طریق SSH. تمام پورت‌ها را روی 127.0.0.1 منتشر کنید، سپس آنچه نیاز دارید را forward کنید: 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 forward کنید و Ollama را روی loopback باقی بگذارید. قدرت این الگو تنها به اندازه قدرت تنظیمات SSH شماست، بنابراین آن را با SSH فقط با کلید و sshd مقاوم‌سازی‌شده همراه کنید.

الگوی دوم: یک reverse proxy که پیش از رسیدن درخواست به برنامه، احراز هویت انجام می‌دهد. برنامه را روی loopback نگه دارید، اجازه دهید proxy مالک پورت 443 باشد و یک سیستم single sign-on در مقابل آن قرار دهید. استفاده از Traefik که توسط Docker Compose labels هدایت می‌شود به همراه Authentik به عنوان ارائه‌دهنده هویت، برای هر برنامه روی سرور یک ورود و یک گواهی فراهم می‌کند. با قرار دادن Open WebUI پشت TLS (امنیت لایه انتقال)، WEBUI_SESSION_COOKIE_SECURE=true و WEBUI_SESSION_COOKIE_SAME_SITE=strict را تنظیم کنید. همچنین JWT_EXPIRES_IN را از مقدار پیش‌فرض چهار هفته‌ای آن کوتاه‌تر کنید، زیرا Open WebUI مستند کرده است که بدون Redis، خروج از سیستم (sign-out) توکن را باطل نمی‌کند: توکن تا زمانی که به صورت خودکار منقضی شود، قابل استفاده باقی می‌ماند.

الگوی دوم پروژه‌هایی که فقط در مرورگر اجرا می‌شوند را نجات نمی‌دهد. یک proxy در مقابل صفحه، از endpoint مدل محافظت نمی‌کند و یک fetch از آن صفحه به یک hostname متفاوت، session cookie شما را منتقل نمی‌کند؛ بنابراین proxy احراز هویت‌کننده در مقابل Ollama با یک redirect به فرم ورود پاسخ می‌دهد و چت با شکست مواجه می‌شود. یا endpoint مدل را تحت همان hostname صفحه مسیریابی کنید، یا از الگوی اول استفاده کنید.

کدام گزینه را انتخاب کنیم

اگر فردی غیر از شما از آن استفاده خواهد کرد، Open WebUI را اجرا کنید. این برنامه دارای سیستم حساب‌های کاربری واقعی است، کاربران جدید در صف تأیید قرار می‌گیرند و توسعه‌دهندگان آن راهنماهای امن‌سازی (hardening) منتشر می‌کنند که می‌توانید از آن‌ها پیروی کنید. اگر به LDAP یا پنل مدیریت نیاز دارید، LibreChat را اجرا کنید و با استفاده از docker stats اطمینان حاصل کنید که شش سرویس آن به همراه مدل شما، پیش از آنکه به آن وابسته شوید، واقعاً در منابع سرور جای می‌گیرند. اگر تنها یک کاربر روی یک سرور کوچک هستید که مدل بخش عمده‌ای از RAM را اشغال کرده است، Hollama یا OrionChat را از طریق یک SSH tunnel ارائه دهید و اجازه دهید مرورگر وضعیت (state) را حفظ کند. پاسخ اشتباه روی یک VPS، انتشار هر یک از این موارد روی 0.0.0.0 بدون قرار دادن یک لایه ورود به سیستم در مقابل آن است.

FAQ

آیا قرار دادن Open WebUI مستقیماً روی یک IP عمومی امن است؟

صفحهٔ hardening خودِ این نرم‌افزار، آن را ابزاری برای شبکه‌های خصوصی و قابل‌اعتماد می‌داند؛ مشابه یک پایگاه‌داده یا سرور CI. این برنامه دارای سیستم حساب کاربری واقعی است و اولین حساب کاربری به مدیر تبدیل می‌شود، در حالی که حساب‌های بعدی تا زمان تأیید، pending باقی می‌مانند؛ بنابراین از رابط کاربری بدون ورود، بسیار امن‌تر است. با این حال، آن را پشت یک reverse proxy با TLS قرار دهید و در صورت امکان، از single sign-on استفاده کنید. پورت کانتینر را به صورت 127.0.0.1:3000:8080 منتشر کنید تا قوانین iptables خودِ Docker نتوانند آن را بدون اطلاع شما در معرض اینترنت قرار دهند.

کدام جایگزین Open WebUI کمترین میزان RAM را روی یک VPS مصرف می‌کند؟

گزینه‌های مبتنی بر مرورگر، یعنی Hollama و OrionChat، زیرا برنامه روی کلاینت اجرا می‌شود. سرور فقط فایل‌های استاتیک را ارسال می‌کند و OrionChat اصلاً به کانتینر برنامه نیاز ندارد. Open WebUI یک پردازش Python، یک پایگاه‌داده و به‌صورت پیش‌فرض یک مدل embedding محلی را در حافظه نگه می‌دارد که طبق مستندات، فقط برای مدل embedding حدود 500 MB به ازای هر worker مصرف می‌شود. این اعداد را روی سرور خود با docker stats --no-stream بررسی کنید، زیرا با فعال‌کردن قابلیت‌های مختلف، تغییر می‌کنند.

آیا این رابط‌های کاربری چت می‌توانند از سرور Ollama روی میزبان دیگری استفاده کنند؟

Open WebUI و LibreChat می‌توانند؛ سرور آن‌ها اتصال را برقرار می‌کند، بنابراین هیچ قانون مرورگری اعمال نمی‌شود. برای Open WebUI مقدار OLLAMA_BASE_URL را تنظیم کنید یا در LibreChat از baseURL در یک endpoint سفارشی استفاده کنید. برای vLLM یا هر سرور سازگار با OpenAI، از OPENAI_API_BASE_URL با پسوند /v1 و یک API key غیرخالی استفاده کنید. Hollama و OrionChat نیز می‌توانند به هر جایی اشاره کنند، اما چون درخواست از مرورگر شما ارسال می‌شود، آن endpoint باید از طریق مرورگر شما نیز در دسترس باشد.

چرا رابط کاربری چت در مرورگر من نمی‌تواند به Ollama متصل شود؟

دو دلیل تقریباً تمام موارد را پوشش می‌دهد. Ollama به‌صورت پیش‌فرض روی 127.0.0.1:11434 گوش می‌دهد، بنابراین مرورگر روی دستگاه دیگر تا زمانی که OLLAMA_HOST تغییر نکند، به آن دسترسی نخواهد داشت. همچنین Ollama درخواست‌های cross-origin را فقط از localhost می‌پذیرد، بنابراین صفحه‌ای که از دامنهٔ شما سرو می‌شود با خطای No 'Access-Control-Allow-Origin' header is present on the requested resource رد می‌شود تا زمانی که آن origin در OLLAMA_ORIGINS لیست شود. اگر صفحه HTTPS باشد و endpoint از نوع HTTP باشد، مرورگر پیش از آنکه Ollama درخواست را ببیند، آن را به عنوان mixed content مسدود می‌کند. هر دو متغیر را در یک override از نوع systemctl edit ollama.service تنظیم کنید یا پورت را از طریق SSH فوروارد کنید تا مشکل برطرف شود.