لماذا تستضيف Dify على VPS؟
يعني استخدام النسخة السحابية من Dify تسليم موجّهاتك وبيانات عملك ومفاتيح API إلى خادم تابع لطرف ثالث، مع قيود على عدد التطبيقات والنماذج المتاحة. باستضافة Dify ذاتيًا على VPS، تزيل هذه القيود: لا اشتراك شهري مرتبط بالاستخدام، ولا بيانات حسّاسة تُرسَل إلى الخارج، وحرية ربط أي مزوّد نماذج (OpenAI وAnthropic وOllama محليًا وغيرها). إنه الحل الأمثل للفِرَق التي ترغب في بناء خطوط أنابيب ذكاء اصطناعي متينة في بيئة تحت سيطرتها الكاملة.
ما الذي يمكنك فعله باستخدام Dify
- إنشاء روبوتات دردشة ووكلاء ذكاء اصطناعي مخصّصين متّصلين بمصادر بياناتك الخاصة (RAG)
- تنظيم سير عمل متعدّد الخطوات يجمع بين عدة نماذج لغوية وأدوات خارجية
- ربط Dify بـ OpenAI أو Anthropic Claude أو Mistral أو نموذج محلي عبر Ollama
- إتاحة تطبيقات الذكاء الاصطناعي الخاصة بك عبر REST API أو أداة قابلة للتضمين في موقعك
- إدارة وصول فريقك عبر نظام أدوار ومساحات عمل
- متابعة سجلّات الاستخدام والتكاليف لكل نموذج وأداء خطوط الأنابيب الخاصة بك
المتطلبات الأساسية: كيف تختار VPS بالمواصفات الصحيحة
يشغّل Dify مجموعة من خدمات Docker بالتوازي: خادم API، ومعالج Celery للتضمينات والمهام غير المتزامنة، والواجهة الأمامية، وPostgreSQL، وRedis، وWeaviate (قاعدة بيانات متجهية للـ RAG)، وبيئة تنفيذ الأكواد، وبروكسي داخلي.
الحدّ الأدنى المطلق: معالجَان ظاهريان (2 vCPU) · 4 GB RAM · 40 GB SSD. بهذه المواصفات يبدأ Dify ويتيح اختبار الوظائف الأساسية.
الموصى به للاستخدام الفعلي: 4 vCPU · 8 GB RAM · 80 GB. بمجرد فهرسة وثائق ضخمة أو استعلام عدة مستخدمين في آنٍ واحد، تستنزف عملية التضمين وقاعدة البيانات المتجهية الـ 4 GB بالكامل.
مع نموذج محلي (Ollama): أضف متطلبات النموذج. يحتاج Llama 3 8B المضغوط (Q4) إلى ~6 GB من ذاكرة VRAM أو RAM مخصّصة. خطّط لـ 16 GB RAM على الأقل لتشغيل Dify وOllama معًا دون swap.
نظام التشغيل الموصى به: Ubuntu 22.04 LTS مع Docker 24+ وDocker Compose v2.
ثبّت Dify على VPS من ServOrbit
اطلب VPS Cloud من ServOrbit
توجّه إلى صفحة /vps-cloud واختر عرضًا يناسب استخدامك (الحدّ الأدنى 2 vCPU / 4 GB، الموصى به 4 vCPU / 8 GB). اختر Ubuntu 22.04 LTS كنظام تشغيل وأكمل الطلب. يُجهَّز VPS الخاص بك في أقل من دقيقة.
استنسخ المستودع وانسخ ملف الإعداد
اتصل بـ VPS عبر SSH ثم نفّذ:
git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .envيتمركز ملف
.envبجميع متغيرات الإعداد (المفاتيح السرية، وعناوين URL، وأعلام السلوك). افتحه وعدّل على الأقلSECRET_KEYوPOSTGRES_PASSWORDقبل تشغيل الحاويات.شغّل مجموعة Docker Compose
من مجلد
dify/docker، نفّذ:docker compose up -dتقوم Docker بتنزيل الصور وتشغيل الحاويات:
dify-apiوdify-workerوdify-webوdb(PostgreSQL) وredisوweaviateوsandboxوssrf_proxyوnginx. تحقّق من أن الكل في حالةUpباستخدامdocker compose ps. تستغرق العملية عادةً 3 إلى 5 دقائق.إنشاء حساب المسؤول
افتح
http://[YOUR-VPS-IP]في متصفّحك. يُعيد Dify توجيهك تلقائيًا إلى/installعند أول وصول.⚠️ افعل ذلك فورًا: ما دام حساب المسؤول غير موجود، تبقى صفحة
/installمفتوحة لأي شخص — ويصبح أول من يصل إليها مالك نسختك.أدخل عنوان بريدك الإلكتروني وكلمة مرور قوية. هذا الحساب هو مالك مساحة العمل الافتراضية.
اربط اسم نطاق وفعّل HTTPS
للاستخدام في بيئة الإنتاج، أسند اسم نطاق لعنوان IP الخاص بـ VPS وانشر شهادة TLS. يتضمّن
docker-compose.yamlالخاص بـ Dify nginx داخليًا يستمع على المنفذ 80. أيسر طريقة هي تثبيت Certbot على الخادم وإنشاء vhost خارجي لـ nginx يُوجّه الطلبات إلىlocalhost:80:sudo apt install nginx certbot python3-certbot-nginx -y sudo certbot --nginx -d your-domain.comثم عدّل
CONSOLE_API_URLوCONSOLE_WEB_URLوSERVICE_API_URLوAPP_WEB_URLفي ملف.envبقيمةhttps://your-domain.com، وأعد تشغيل الحاويات بـdocker compose up -d.
الإعداد بعد التثبيت: النماذج وواجهة API ومساحة العمل
بمجرد تسجيل الدخول، تتمثّل الخطوة الأولى في تسجيل مزوّد نماذج. في الإعدادات (الأيقونة في أعلى اليمين) ← مزوّدو النماذج، أضف مفتاح API الخاص بـ OpenAI أو Anthropic أو Mistral أو أي مزوّد آخر مدعوم. للنموذج المحلي، أدخل عنوان URL لنسخة Ollama الخاصة بك (http://[host-IP]:11434).
يكشف Dify أيضًا REST API خاصة به لدمج تطبيقاتك في خطوط أنابيب خارجية. ستجد مفاتيح API في الإعدادات ← مفاتيح API. تتيح هذه المفاتيح استعلام تطبيقاتك في Dify من n8n أو Zapier أو أي سكربت Python دون الحاجة إلى واجهة المستخدم الرسومية.
مساحة العمل الافتراضية هي تلك التي أُنشئت عند تسجيل الدخول الأول. ادعُ أعضاء عبر الإعدادات ← الأعضاء وامنحهم أدوار Admin أو Normal أو Dataset operator.
الإضافات دون اتصال: تجاوز خطأ 500/404 في نسخ self-hosted
منذ نوفمبر 2025 (issue #27720 على GitHub)، يُلاحظ كثير من مستخدمي النسخ الذاتية أن تثبيت الإضافات من marketplace لـ Dify يُرجع خطأ HTTP 500 أو 404 على النقطة النهائية /api/v1/plugins/download/. تُثبَّت الإضافات نفسها بدون مشكلة على Dify Cloud، لكن النسخ المستضافة ذاتيًا لا تستطيع الوصول إلى خلفية التوزيع.
الحلّ البديل 1 — ملف .difypkg محلي. الأسلوب الأكثر موثوقية هو تنزيل ملف .difypkg للإضافة يدويًا من marketplace لـ Dify، ثم تثبيته عبر خيار «التثبيت من ملف محلي» في واجهة Dify. يعمل هذا الأسلوب بغضّ النظر عن الاتصال بنقطة التنزيل.
الحلّ البديل 2 — تعطيل التحقّق من التوقيع. إن أردت تثبيت إضافات غير موقّعة أو تطوير إضافاتك الخاصة، أضف المتغير التالي في ملف .env:
FORCE_VERIFYING_SIGNATURE=falseثم أعد تشغيل خدمة plugin_daemon:
docker compose restart plugin_daemon⚠️ تحذير: يُلغي تعطيل التحقّق من التوقيع أحد ضمانات الأمان. احتفظ بهذا الإعداد لبيئات التطوير أو الإضافات التي تتحكّم في مصدرها. للاستخدام الإنتاجي مع مستخدمين خارجيين، يُفضَّل التثبيت عبر ملف .difypkg موثوق.
الربط مع Ollama وn8n
يصبح Dify أكثر قوةً حين يقترن بأدوات self-hosted أخرى.
Ollama يتيح تشغيل نموذج لغوي مباشرةً على VPS أو خادم ضمن الشبكة نفسها، دون الاعتماد على API خارجية. بعد نشر Ollama، سجّله في Dify كمزوّد نماذج بعنوان URL: http://[Ollama-IP]:11434. تبقى كل عمليات التوليد حينئذٍ ضمن بنيتك التحتية — دون أي تسرّب للموجّهات إلى الخارج.
n8n هو منسّق سير عمل يمكنه التحكّم في Dify عبر REST API. أنشئ عقدة HTTP Request في n8n تشير إلى https://your-domain.com/v1/chat-messages مع مفتاح API لـ Dify في ترويسة Authorization. يمكنك بذلك تشغيل محادثة Dify انطلاقًا من نموذج ويب أو بريد إلكتروني وارد أو Slack webhook، وإرسال استجابة الذكاء الاصطناعي إلى أي وجهة.
تشخيص الأخطاء: أكثر المشكلات شيوعًا
حاوية worker تعيد التشغيل باستمرار. يعتمد معالج Celery على Redis وPostgreSQL. تحقّق من حالتهما بـ docker compose ps db redis وراجع السجلّات: docker compose logs worker --tail=50. إذا لم يكن Redis جاهزًا عند بدء التشغيل، يكفي docker compose restart worker.
plugin_daemon: خطأ في الاتصال بـ PostgreSQL. بعد تحديث Dify، قد يفشل plugin_daemon بخطأ failed to connect to host=db. تحقّق من أن حاوية db في الحالة healthy (docker compose ps db). إن استمر الخطأ، انتظر 30 ثانية بعد اكتمال التشغيل قبل إعادة التشغيل: docker compose restart plugin_daemon.
Weaviate لا يبدأ (vm.max_map_count). تتطلّب Weaviate معاملًا عاليًا لنواة Linux. إن خرجت الحاوية فورًا، طبّق: sudo sysctl -w vm.max_map_count=262144. لجعله دائمًا، أضف vm.max_map_count=262144 إلى /etc/sysctl.conf.
إضافات marketplace: خطأ 500/404. راجع قسم «الإضافات دون اتصال» أعلاه. إن كانت المشكلة تتعلق بحجب شبكي بين حاويات Docker وmarketplace.dify.ai، تحقّق من أن المنفذ 443 الصادر غير محجوب: docker compose exec api curl -I https://marketplace.dify.ai.
انقطاع WebSocket خلف البروكسي العكسي. إن انقطع البثّ المتدفّق لردود الذكاء الاصطناعي، فإن nginx الخارجي لا يُمرّر ترويسات WebSocket. أضف إلى كتلة location /: proxy_set_header Upgrade $http_upgrade; وproxy_set_header Connection "upgrade";.
فعّل النسخ الاحتياطية التلقائية من ServOrbit لحماية حجم PostgreSQL الخاص بـ Dify (تطبيقاتك وموجّهاتك وسجلّات المحادثات). تغطّي لقطة يومية للقرص جميع أحجام Docker، بما في ذلك dify_db وdify_weaviate. في حال فشل تحديث ما، يستغرق العودة إلى نسخة سابقة دقائق قليلة من مساحة العميل.
التوثيق الرسمي
للإعداد المتقدّم وقائمة متغيرات البيئة الكاملة وملاحظات الإصدار، راجع التوثيق الرسمي لـ Dify. يبقى docker-compose.yaml في المستودع الرسمي المرجع الأساسي لإصدارات الصور والتبعيات بين الخدمات.
