نشر Dify على VPS: دليل شامل من التثبيت إلى الإضافات

يعني استخدام النسخة السحابية من Dify تسليم موجّهاتك وبيانات عملك ومفاتيح API إلى خادم تابع لطرف ثالث، مع قيود على عدد التطبيقات والنماذج المتاحة. باستضافة Dify ذاتيًا على VPS، تزيل هذه القيود: لا اشتراك شهري مرتبط بالاستخدام، ولا بيانات حسّاسة تُرسَل إلى الخارج، وحرية ربط أي مزوّد نماذج (OpenAI وAnthropic وOllama محليًا وغيرها). إنه الحل الأمثل للفِرَق التي ترغب في بناء خطوط أنابيب ذكاء اصطناعي متينة في بيئة تحت سيطرتها الكاملة.

يشغّل Dify مجموعة من خدمات Docker بالتوازي: خادم API، ومعالج Celery للتضمينات والمهام غير المتزامنة، والواجهة الأمامية، وPostgreSQL (الخدمة db_postgres)، وRedis، وWeaviate كقاعدة متجهية افتراضية (VECTOR_STORE=weaviate)، وبيئة sandbox لتنفيذ الأكواد، وplugin_daemon، وبروكسيات SSRF (Squid)، وnginx. ومنذ الإصدار 1.16.0 تنضمّ إليها agent_backend وlocal_sandbox اللتان تشغّلان تطبيقات Agent.

الحدّ الأدنى الرسمي: نواتان من المعالج و4 GiB من الذاكرة، مع Docker Compose بالإصدار 2.24.0 أو أحدث (توثيق Dify). خطّط لـ 2 vCPU · 4 GB · 40 GB SSD لاختبار الوظائف الأساسية.

الموصى به للاستخدام الفعلي: 4 vCPU · 8 GB RAM · 80 GB. بمجرد فهرسة وثائق ضخمة أو استعلام عدة مستخدمين في آنٍ واحد أو تفعيل تطبيقات Agent، تستنزف التضمينات وقاعدة البيانات المتجهية وخدمات الوكيل الـ 4 GB بالكامل. يناسب عرض VPS Power من ServOrbit (4 vCPU، 8 GB) استخدام فريق دون نموذج محلي.

مع نموذج محلي (Ollama): أضف متطلبات النموذج. يحتاج Llama 3 8B المضغوط (Q4) إلى ~6 GB من ذاكرة VRAM أو RAM مخصّصة؛ خطّط لـ 16 GB RAM على الأقل لتشغيل Dify وOllama معًا دون swap.

نظام التشغيل الموصى به: Ubuntu 22.04 LTS.

بمجرد تسجيل الدخول، تتمثّل الخطوة الأولى في تسجيل مزوّد نماذج. في الإعدادات (الأيقونة في أعلى اليمين) ← مزوّدو النماذج، أضف مفتاح API الخاص بـ OpenAI أو Anthropic أو Mistral أو أي مزوّد آخر مدعوم. للنموذج المحلي، أدخل عنوان URL لنسخة Ollama الخاصة بك (http://[host-IP]:11434).

يكشف Dify أيضًا REST API خاصة به لدمج تطبيقاتك في خطوط أنابيب خارجية. ستجد مفاتيح API في الإعدادات ← مفاتيح API. تتيح هذه المفاتيح استعلام تطبيقاتك في Dify من n8n أو Zapier أو أي سكربت Python دون الحاجة إلى واجهة المستخدم الرسومية.

مساحة العمل الافتراضية هي تلك التي أُنشئت عند تسجيل الدخول الأول. ادعُ أعضاء عبر الإعدادات ← الأعضاء وامنحهم أدوار Admin أو Normal أو Dataset operator.

منذ نوفمبر 2025 (issue #27720 على GitHub، فُتحت على Dify 1.9.2)، يلاحظ مستخدمو النسخ الذاتية فشل تثبيت الإضافات من marketplace: خطأ HTTP 500 مع langgenius/perplexity، وHTTP 404 مع langgenius/anthropic، ثم Reached maximum retries (3) مع langgenius/azure_openai. تُثبَّت الإضافات نفسها على Dify Cloud. أُغلقت المسألة بوصف «not planned» في 18 ديسمبر 2025 بالوسم cant-reproduce ودون إصلاح: الحلول أدناه مصدرها بوت في النقاش ولم يؤكدها المشرفون.

الحلّ البديل 1: ملف ‎.difypkg محلي. نزّل ملف ‎.difypkg للإضافة على جهاز متصل، ثم ثبّته عبر «التثبيت من ملف محلي». للخادم دون وصول صادر، تضمّ أداة dify-plugin-repackaging الاعتماديات داخل الحزمة. وإن رُفض الملف بسبب حجمه، ارفع PLUGIN_MAX_PACKAGE_SIZE (القيمة الافتراضية 52428800 بايت) وNGINX_CLIENT_MAX_BODY_SIZE (الافتراضية 100M).

الحلّ البديل 2: تعطيل التحقّق من التوقيع. لتثبيت إضافات غير موقّعة أو تطوير إضافاتك، عيّن FORCE_VERIFYING_SIGNATURE=false (الافتراضية: true) في ‎.env، ثم نفّذ docker compose restart plugin_daemon.

تحذير: يُلغي تعطيل التوقيع أحد ضمانات الأمان. احتفظ بهذا الإعداد لبيئات التطوير أو لإضافات تتحكّم في مصدرها؛ وفي الإنتاج مع مستخدمين خارجيين يُفضَّل ملف ‎.difypkg موثوق.

عقدة Agent في Chatflow وWorkflow على الإصدار 1.15.0. في تثبيت Docker القياسي للإصدار 1.15.0، تفشل عقدة «Agent» قبل أي استدعاء للنموذج بالخطأ ValueError: base_url is required when creating a real Agent backend client. فهي تتطلّب خدمة «Agent backend» يحدّدها AGENT_BACKEND_BASE_URL، ولم يكن ‎docker-compose.yaml الرسمي لذلك الإصدار يتضمّنها. لم تُنتج المسألتان #38283 (أُغلقت بوصف «not planned» في 17 أغسطس 2026) و#39161 (أُغلقت بوصفها مكرّرة في 23 أكتوبر 2026) في langgenius/dify أي إصلاح؛ وما زال تحسين رسالة الخطأ قيد المراجعة (PR #39878). يتداول الناس حلّين ولا يصلح أيٌّ منهما: يوصل AGENT_BACKEND_USE_FAKE=true عميلًا وهميًا يعيد إجابة ثابتة دون أن يستدعي النموذج اللغوي ولا أدوات MCP، ونشر خدمة dify-agent يدويًا غير موثّق وغير مدعوم.

منذ الإصدار 1.16. يضمّ ملف compose الرسمي الآن agent_backend وlocal_sandbox، مع AGENT_BACKEND_BASE_URL=http://agent_backend:5050 في ‎.env.example، وعليك تعيين DIFY_AGENT_API_TOKEN (الذي يجب أن يساوي AGENT_BACKEND_API_TOKEN منذ 1.16.1) وDIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN. غير أن Agent V2 أُخفي من Chatflow منذ 1.16.1 لغياب سياق المحادثات متعددة الأدوار؛ وطلب استعادته (#41269، فُتح في 26 أغسطس 2026) بلا إصدار مستهدف. في Chatflow لا تتوفّر إلا عقدة Agent القديمة. ونوع تطبيق Agent المستقل هو البديل الذي يقول صاحب #39161 إنه اشتغل على 1.15.0.

تفيد المسألة #44742 (فُتحت في 25 أكتوبر 2026) بأنه بعد حذف أداة MCP ثم إضافتها من جديد في عقدة Agent على 1.18.0، يتوقف Chatflow عن العمل: TypeError: object of type 'NoneType' has no len() في الدالة build_parameters. يُظهر ملف YAML المُصدَّر أن allowed_tools وcontext وfiles حُفظت بالشكل type: variable مع value: null. أما أداة MCP أخرى سليمة في التدفّق نفسه فتواصل العمل. العودة إلى 1.17.x لا تُصلح تدفّقًا تضرّر أصلًا، واستيراد النسخة المصدَّرة التالفة في نسخة أخرى يفشل أيضًا.

حلول أُبلغ عنها. تعديل YAML لجعل هذه الحقول الثلاثة type: constant مع value: [] ثم استيراده كما هو (إعادة تغليفه كملف ‎.difypkg تفشل في فحص السلامة)، أو إعادة بناء التدفّق.

حالة النقاش. أُغلقت المسألة في 26 أكتوبر 2026 عبر PR #44748 المدموج في main: لم تعد تكتب الحقول الاختيارية المفرَّغة في الرسم المحفوظ. تعالج #44579 (AgentVariableNotFoundError) لكنها تنصّ على أن المعاملات اليدوية المتداخلة والتسلسل الكامل لحذف أداة MCP وإضافتها خارج نطاقها. لم يظهر أي إصدار بعد 1.18.0 في صفحة الإصدارات في 28 أكتوبر 2026. إلى ذلك الحين، صدِّر ملف YAML قبل كل تعديل على Chatflow يستخدم أداة MCP.

يصبح 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، وإرسال استجابة الذكاء الاصطناعي إلى أي وجهة.

تمسّ ترقية Dify مخطط PostgreSQL (تُنفَّذ الترحيلات عند إقلاع API ما دام MIGRATION_ENABLED=true) والبيانات المتجهية وصور مجموعة الوكيل. تبدأ ملاحظات الإصدار 1.18.0 بعبارة «Back up first»: قاعدة البيانات وبيانات المخزن المتجهي والملفات المرفوعة وتخزين Agent والأسرار وملفات البيئة.

في Docker Compose يقع كل شيء تقريبًا في docker/volumes/ (db/data لـ PostgreSQL وweaviate وredis/data)، على هيئة مجلدات مرتبطة لا أحجام مسمّاة. للحصول على نسخة متّسقة: docker compose stop ثم ‎tar czf ../dify-backup.tar.gz volumes .env docker-compose.yaml ثم انسخ الأرشيف خارج VPS. وبدون إيقاف كامل يبقى التصدير المنطقي ممكنًا: ‎docker compose exec -T db_postgres pg_dump -U postgres dify > dify-dump.sql.

احتفظ أيضًا، خارج المستودع، بـ SECRET_KEY وبـ PASSWORD_PEPPER إن عيّنته: فقدان الأول يجعل بيانات الاعتماد المشفّرة غير قابلة للقراءة، وتغيير الثاني يُبطل تجزئات كلمات المرور الحالية (ملاحظات 1.18.0). وأخيرًا خطّط للمراحل: إن كانت مجموعتك ما زالت تضمّ Weaviate 1.27، فإن ملاحظات 1.17.1 تفرض ترقية على مراحل نحو 1.39 دون تخطي إصدارات فرعية.

حاوية worker تعيد التشغيل باستمرار. يعتمد معالج Celery على Redis وPostgreSQL. تحقّق من حالتهما بـ docker compose ps db_postgres redis واقرأ docker compose logs worker --tail=50. إذا لم يكن Redis جاهزًا عند الإقلاع، يكفي docker compose restart worker.

plugin_daemon يدور في حلقة بسبب الاتصال بـ PostgreSQL. يُظهر البلاغ dify-plugin-daemon #729 (Dify 1.14.0) الرسالة ‎failed to connect to host=db_postgres … lookup db_postgres on 127.0.0.11:53: no such host ثم panic: failed to init dify plugin db. يجب أن يطابق اسم المضيف خدمة قيد التشغيل: تحقّق من أن db_postgres في حالة healthy وأن DB_HOST في ‎.env يحمل هذا الاسم وأن COMPOSE_PROFILES يتضمّن postgresql، ثم نفّذ docker compose down وdocker compose up -d. أُغلقت تلك المسألة دون سبب مؤكَّد.

خدمة لا تبدأ بسبب ‎vm.max_map_count. يخص هذا الإعداد في النواة Elasticsearch (ملف التعريف elasticsearch) لا Weaviate. إن اخترته، يطلب توثيق Elastic القيمة 1048576 حين تكون القيمة الافتراضية أدنى: ‎sudo sysctl -w vm.max_map_count=1048576، ثم السطر نفسه في ‎/etc/sysctl.conf مع sudo sysctl --system لجعله دائمًا.

إضافات marketplace: خطأ 500/404. راجع قسم «الإضافات دون اتصال». إن كان السبب حجبًا شبكيًا، اختبر المنفذ 443 الصادر من داخل حاوية: ‎docker compose exec api curl -I https://marketplace.dify.ai.

انقطاع WebSocket خلف البروكسي العكسي. إن انقطع بثّ الردود، فإن nginx الخارجي لا يُمرّر ترويسات الترقية. أضف إلى location /: proxy_set_header Upgrade $http_upgrade; وproxy_set_header Connection "upgrade";.

base_url is required when creating a real Agent backend client. راجع «الحدود المعروفة لتثبيت Docker: عقدة Agent». على إصدار حديث، تحقّق من أن agent_backend يعمل وأن AGENT_BACKEND_BASE_URL يشير إلى http://agent_backend:5050.

agent_backend أو local_sandbox لا يبدآن. قيمة DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN فارغة: يذكر التوثيق أن Agent backend وصندوق الرمل التابع له لا يبدآن بدونها. ولّدها بالأمر openssl rand -base64 32 وضعها في docker/.env ثم أعد التشغيل.

TypeError: object of type 'NoneType' has no len(). تضرّر Chatflow بعد تعديل أداة MCP على 1.18.0 (#44742): راجع القسم المخصّص وأصلح YAML قبل الاستيراد.

AgentVariableNotFoundError: Variable '' does not exist. حقل اختياري فُرِّغ في عقدة Agent يترك محدِّدًا فارغًا في الرسم المحفوظ (#44579، لوحظ على 1.17.1). أعد قيمة إلى الحقل أو انتظر إصدارًا يتضمّن PR #44748.

ضياع IP الحقيقي خلف Cloudflare أو موازن حمل. منذ 1.18.0 يستبدل nginx المضمَّن الترويسة X-Forwarded-For: اضبط التعامل الموثوق مع IP الحقيقي.

تعذّر الدخول بعد تحديث. إضافة PASSWORD_PEPPER أو تغييره أو حذفه يُبطل كلمات المرور الحالية: أعد القيمة الأصلية.