أفضل بدائل Open WebUI على VPS

ما بديل Open WebUI المناسب على VPS

تُقارَن بدائل Open WebUI غالباً على جهاز محمول، حيث تكون RAM منخفضة التكلفة ولا تستمع أي خدمة على عنوان عام. يغيّر VPS هذين العاملين، ولذلك يتغيّر ترتيب الخيارات. يظل Open WebUI الخيار الافتراضي المناسب بمجرد تسجيل شخص ثانٍ، لأنّه يوفّر حسابات مستخدمين فعلية ولوحة إدارة. تتفوق المشاريع الأخف عندما تتنافس الواجهة مع النموذج على آخر gigabyte من RAM. وثمن هذا التفوق هو المصادقة: فهي غير متوفرة فيها.

يعتمد كل ما يلي على وثائق كل مشروع نفسه، بعد الاطلاع عليها في August 2026. والمحاور الأربعة هي العوامل التي لا تظهر إلا بعد إتاحة الخادم عبر الإنترنت.

أربعة محاور لا تهم إلا عند استخدام IP عام

• الذاكرة بجوار النموذج. خادم النموذج هو العملية الأكثر استهلاكاً للموارد على الخادم. كل ميغابايت تحتفظ به الواجهة هو ميغابايت لا يستطيع النموذج استخدامه.
• المصادقة. توفر بعض هذه المشاريع حسابات مستخدمين وأدواراً. بينما تفترض مشاريع أخرى أنها التطبيق الوحيد الذي يعمل على حاسوبك المحمول، ولا توفر تسجيل دخول على الإطلاق.
• الاستدلال عن بُعد. تفرض واجهة المستخدم التي لا تستطيع الوصول إلا إلى 127.0.0.1:11434 تشغيل النموذج على الخادم نفسه الذي يشغّل الواجهة.
• الصيانة. يختلف تشغيل حاوية واحدة تحتوي على ملف SQLite عن تشغيل ست حاويات تستخدم MongoDB وقاعدة بيانات متجهات خلفها.

كم مقدار RAM الذي يتركه النموذج للواجهة

ليست الواجهة أكبر مكوّن على الخادم. النموذج هو الأكبر. تعطي أحجام التنزيل المنشورة الحد الأدنى، لأن الأوزان يجب أن تكون مقيمة في الذاكرة أثناء إجابة النموذج، كما أن استخدام الذاكرة الفعلي أعلى من حجم التنزيل بعد تخصيص ذاكرة التخزين المؤقت للسياق.

[
  {
    "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 في August 2026. وهي أحجام منشورة وليست قياسات. على VPS بسعة 4 GB، يستهلك qwen3:4b بحجم 2.5 GB معظم الذاكرة، ولا يترك للنظام وكل شيء آخر سوى أقل من 1.5 GB. كما تستهلك ذاكرة التخزين المؤقت للسياق جزءاً إضافياً مع نمو المحادثة. لذلك فإن قيمة num_ctx التي تحددها قرار متعلق بالذاكرة بقدر ما هو قرار متعلق بالجودة. أما qwen3:8b بحجم 5.2 GB فلا يتسع له ذلك الخادم إطلاقاً. هذا هو الجانب الذي لا تغطيه عادةً مقارنات الحواسيب المحمولة. هنا تحدد واجهة محادثة تستهلك بضع مئات من الميغابايت ما إذا كان النموذج سيعمل. إذا كنت تجهّز خادماً لنموذج يتجاوز هذه العلامات بكثير، توضّح الحسابات الخاصة بنموذج 27B على VPS يعمل بالـCPU فقط مدى سرعة توقف الواجهة عن كونها العامل الحاسم.

قِس الاستخدام بدلاً من الوثوق بأي رقم في مقالة مقارنة، بما في ذلك هذه المقالة. شغّل 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، تكون هذه البادئة أهم من أي شيء آخر في السطر، لأن Docker يكتب قواعد iptables الخاصة به، والمنفذ المنشور يتجاهل قواعد المنع في ufw.

افتح الصفحة عبر tunnel أو proxy، كما هو موضح أدناه، ثم أنشئ الحساب الأول. يصبح هذا الحساب مسؤولاً. تُنشأ الحسابات اللاحقة بالدور pending، وهو الافتراضي الموثق في DEFAULT_USER_ROLE، لذلك لا يستطيع شخص غريب يصل إلى الصفحة استخدام نموذجك قبل أن يوافق عليه مسؤول.

يستهلك Open WebUI ذاكرة أكبر من المشاريع أدناه لأنه ينفذ وظائف أكثر، وتوضح صفحة الأداء الخاصة به المكونات التي تستهلك هذه الذاكرة. يحمّل محرك embedding الافتراضي نموذج sentence-transformers داخل الحاوية، وتوثّق الصفحة أن حجمه يقارب 500 MB لكل عملية worker. يؤدي ضبط RAG_EMBEDDING_ENGINE=ollama إلى إسناد هذه المهمة إلى model server الذي تشغّله مسبقاً. ويمنع AUDIO_STT_ENGINE=webapi تحميل نموذج محلي لتحويل speech إلى text. عند استخدام SQLite مع عدم ضبط DATABASE_POOL_SIZE، يعود pool إلى حجم داخلي كبير، وتُنشئ كل connection ذاكرة 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، ويضم لوحة إدارة للمستخدمين والأدوار. تأتي هذه الإمكانات مع حزمة خدمات.

[
  {
    "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

يتوقف git pull بسبب تعارض إذا عدّلت docker-compose.yml المتتبَّع، ثم تصبح الترقية مطبَّقة جزئياً. ضع تغييراتك في docker-compose.override.yml، الذي يوفّره المشروع لهذا الغرض، واحتفظ بالأسرار في .env. كلا الملفين غير متتبَّع، لذلك يتركهما 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 تطبيقاً للمتصفح من حاوية صغيرة واحدة. تُخزَّن المحادثات في مساحة تخزين المتصفح، لا على الخادم.

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

يستخدم إصدار README من هذا الأمر --rm، ما يحذف الحاوية عند توقفها. لذلك لا تعود الواجهة بعد إعادة التشغيل. عند استخدام Reverse Proxy، أضف -e VITE_ALLOWED_HOSTS='chat.example.com'، لأن الصورة تسمح باسم المضيف localhost فقط. وتعيد خطأ مضيف محظور عند ورود طلب باسم مضيف آخر، بدلاً من عرض التطبيق.

يذهب OrionChat إلى أبعد من ذلك، إذ لا يحتوي على مكوّن خادم إطلاقاً. استنسخ المستودع وقدّم المجلد باستخدام خادم الويب الذي تشغّله بالفعل، أو افتح index.html من القرص. تُخزَّن مفاتيح API في localStorage الخاص بالمتصفح، وتبقى محفوظات المحادثات في المتصفح، ويحذف التطبيق أقدم المحادثات عندما يتجاوز العدد 512.

لا يوفّر أي من المشروعين تسجيل دخول، لأن أياً منهما لا يملك خادماً يمكنه التحقق منه. هذا مناسب على جهاز محمول. أما على VPS، فيعني ذلك أنه يجب عدم نشر الصفحة مطلقاً على 0.0.0.0. ويعني أيضاً أمراً يسهل إغفاله: المتصفح هو الذي يستدعي النموذج، وليس الخادم.

تحدد هذه الحقيقة وحدها المواضع التي يمكن استخدام هذين المشروعين فيها. يجب أن يتمكن متصفحك من الوصول إلى Ollama مباشرة. لذلك يجب أن يستمع Ollama على أكثر من loopback، كما أنه لا يوفّر أي نوع من المصادقة. وينتج عن ذلك شرطان للمتصفح. لا يمكن لصفحة تُقدَّم عبر HTTPS استدعاء نقطة نهاية 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 إلى أن تسمح بذلك صراحةً.

الطريقة الموثقة في Ollama لتغيير أي من الإعدادين هي استخدام override في systemd.

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 الذي كان يطبعه سابقاً. لا تُجرِ هذا التغيير إلا عندما يكون جدار ناري أو Reverse Proxy يوفّر المصادقة قد تحكم بالفعل في الجهات التي يمكنها الوصول إلى المنفذ، لأن فتح 11434 يعني فتح خادم نماذج، وتصل أدوات الفحص الجماعي إلى المنفذ العام الجديد بسرعة. يتجنب نفق SSH أدناه هذه المسألة بالكامل: تعمل الصفحة حينها على origin من نوع localhost، وهو ما يسمح به 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 تقديم الطلبات، لأن سلوكهما يختلف كثيراً عندما يتحدث عدة أشخاص إلى النموذج في الوقت نفسه. إذا لم يكن خادم النموذج موجوداً بعد، فابدأ بـتشغيل Ollama على VPS، وعلى جهاز يعمل دون GPU اقرأ مقارنة Ollama مع llama.cpp قبل اختيار المشغّل.

لا تنشر واجهة محادثة دون تسجيل دخول على 0.0.0.0

توضح صفحة التحصين في Open WebUI أن المشروع «مصمم للشبكات الخاصة والموثوقة، مثل البنية التحتية الأخرى المستضافة ذاتياً، كقواعد البيانات وسجلات الحاويات وخوادم CI»، وتوصي بوضعه خلف VPN أو خلف reverse proxy مع مصادقة. ويستحق أي مشروع لا يتطلب تسجيل دخول على الإطلاق المعاملة نفسها على الأقل.

تحقق مما يستمع قبل أن تثق بأي جزء منه.

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 لديك، ولذلك اجمعه مع SSH يقتصر على المفاتيح وsshd محصّن.

النمط الثاني: reverse proxy يصادق على الطلب قبل أن يصل إلى التطبيق. أبقِ التطبيق على loopback، ودَع الـproxy يتولى المنفذ 443، وضع تسجيل الدخول الموحّد أمامه. يوفّر Traefik المُدار عبر تسميات Docker Compose مع Authentik بوصفه موفّر الهوية لكل تطبيق على الخادم تسجيل دخول واحداً وشهادة واحدة. عند وضع Open WebUI خلف TLS (أمان طبقة النقل)، اضبط WEBUI_SESSION_COOKIE_SECURE=true وWEBUI_SESSION_COOKIE_SAME_SITE=strict. وقلّل أيضاً JWT_EXPIRES_IN عن قيمته الافتراضية البالغة أربعة أسابيع، لأن وثائق Open WebUI توضّح أن تسجيل الخروج لا يلغي الرمز المميّز عند عدم استخدام Redis؛ إذ يظل قابلاً للاستخدام حتى تنتهي صلاحيته تلقائياً.

لا يحل النمط الثاني مشكلة المشاريع التي تعمل عبر المتصفح فقط. لا يحمي proxy الموضوع أمام الصفحة نقطة نهاية النموذج، كما أن طلب fetch من تلك الصفحة إلى اسم مضيف مختلف لا يرسل ملف تعريف الارتباط الخاص بجلسة العمل؛ لذلك يجيب proxy الذي يفرض المصادقة أمام Ollama بإعادة توجيه إلى نموذج تسجيل الدخول، وتفشل المحادثة. إما أن توجّه نقطة نهاية النموذج عبر اسم المضيف نفسه المستخدم للصفحة، أو استخدم النمط الأول.

اختر المناسب

إذا كان سيستخدمه أي شخص غيرك، فشغّل Open WebUI. فهو يدعم حسابات فعلية، ويضع المستخدمين الجدد في قائمة انتظار للموافقة، وينشر مشرفوه إرشادات لتقوية الأمان يمكنك اتباعها. إذا كنت تحتاج إلى LDAP أو لوحة إدارة، فشغّل LibreChat، وتحقق باستخدام docker stats من أن خدماته الست، إضافة إلى نموذجك، تناسب الموارد المتاحة فعلاً قبل الاعتماد عليه. إذا كان المستخدم شخصاً واحداً على جهاز صغير استحوذ النموذج فيه مسبقاً على معظم RAM، فوفّر Hollama أو OrionChat عبر نفق SSH، ودَع المتصفح يحتفظ بالحالة. الإجابة الخاطئة على VPS هي نشر أيٍّ منها على 0.0.0.0 من دون تسجيل دخول أمامها.

FAQ

هل من الآمن إتاحة Open WebUI مباشرةً على عنوان IP عام؟

تصفه صفحة التقوية الخاصة به بأنّه برنامج مخصّص للشبكات الخاصة والموثوقة، ضمن الفئة نفسها التي تشمل قاعدة البيانات أو خادم CI. وهو يدعم حسابات فعلية، ويصبح الحساب الأول مسؤولاً، بينما تبقى الحسابات اللاحقة بحالة pending إلى أن توافق عليها، لذلك فهو أكثر أماناً بكثير من واجهة لا تتطلب تسجيل الدخول. مع ذلك، ضعه خلف reverse proxy مع TLS، واستخدم تسجيل الدخول الأحادي حيثما أمكن. انشر منفذ الحاوية على 127.0.0.1:3000:8080 حتى لا تفتحه قواعد iptables الخاصة بـDocker على الإنترنت من دون علمك.

أي بديل لـOpen WebUI يستخدم أقل قدر من RAM على VPS؟

البدائل التي تعمل في المتصفح، وهما Hollama وOrionChat، لأن التطبيق يعمل على جهاز العميل. لا يرسل الخادم سوى الملفات الثابتة، ولا يحتاج OrionChat إلى حاوية تطبيق على الإطلاق. يحتفظ Open WebUI بعملية Python وقاعدة بيانات، وبنموذج embedding محلي في الذاكرة افتراضياً، وتوثّق الصفحة استخداماً يبلغ نحو 500 MB لكل worker لنموذج embedding وحده. تحقّق من الأرقام على خادمك باستخدام docker stats --no-stream، لأنّها تتغير وفق الميزات التي تفعّلها.

هل يمكن لواجهات الدردشة هذه استخدام خادم Ollama على مضيف آخر؟

يمكن لـOpen WebUI وLibreChat ذلك، ويتولى خادمهما إنشاء الاتصال، لذلك لا تنطبق قاعدة المتصفح. اضبط OLLAMA_BASE_URL لـOpen WebUI، أو baseURL في endpoint مخصص لـLibreChat. بالنسبة إلى vLLM أو أي خادم آخر متوافق مع OpenAI، استخدم OPENAI_API_BASE_URL مع اللاحقة /v1 ومفتاح API غير فارغ. يمكن لـ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 إلى أن يُدرج ذلك المصدر في OLLAMA_ORIGINS. إذا كانت الصفحة تستخدم HTTPS وكان endpoint يستخدم HTTP، يحظر المتصفح الطلب باعتباره mixed content قبل أن يصل إلى Ollama. اضبط المتغيرين في override من النوع systemctl edit ollama.service، أو مرّر المنفذ عبر SSH، وعندها تختفي المشكلة.