تثبيت Dify على VPS باستخدام Docker Compose
تحتاج Dify إلى 6 حاويات ونحو 4 غيغابايت من RAM. بدّل كل الأسرار في ملف .env قبل التشغيل، ثم أنشئ حساب المسؤول من /install قبل أي زائر آخر.
ما هي Dify، وما الذي ستشغّله
Dify منصة يمكنك استضافتها بنفسك لبناء تطبيقات تعتمد على نماذج اللغة الكبيرة. تحصل على واجهة ويب لتصميم تطبيقات الدردشة والوكلاء وخطوط أنابيب الاسترجاع، وواجهة API لاستدعائها من شيفرتك، ومكان واحد لإدارة المطالبات ومجموعات البيانات ومفاتيح النماذج. هذه أداة يمكن لفريق صغير تشغيلها كي يبني الجميع على قاعدة خاصة مشتركة، بدلاً من توزيع مفاتيح API بين البرامج النصية. إذا كانت مصطلحات مثل agent وtool call وretrieval pipeline لا تزال غير واضحة، فإن استيعاب هذه المفاهيم من الصفر أولاً سيجعل شاشات بناء Dify تبدو كعناصر تحكم مألوفة، لا كمجموعة كبيرة من المفاتيح غير المسمّاة.
تشغيله بنفسك يعني تشغيل عدة مكوّنات مترابطة. يأتي Dify على شكل مجموعة من حاويات Docker: خادم API، وعامل مهام في الخلفية، وواجهة ويب أمامية، وقاعدة بيانات Postgres، وذاكرة Redis مؤقتة، وقاعدة بيانات متجهات، وكلها موصولة معاً باستخدام Docker Compose. هذا أكثر من ملف تنفيذي واحد، لكن Compose يتولى ربط المكوّنات، كما يشغّله VPS يتوفر فيه بضعة غيغابايتات من RAM بسهولة. إذا كان VPS نفسه سيشغّل خدمة أخرى أيضاً، فحدّد حجمه استناداً إلى أرقام مقاسة لا إلى الأرقام المعلنة، لأن الحد الفعلي لاستهلاك RAM في PhotoPrism وImmich أعلى بكثير من الحد الأدنى المنشور لكل منهما، وسيستنزف خادم الصور قاعدة بيانات Dify ومخزن المتجهات أولاً. ويحدث الأمر نفسه مع تنافس المعالج: مكتبة Jellyfin بواجهة مستوحاة من متجر فيديوهات من حقبة 90s لا تستهلك تقريباً أي موارد أثناء تصفح الصور، لكن بمجرد أن يبدأ أحدهم تحويل ترميز، تنتظر قوائم مهام عامل Dify خلفه. والنقطة الإيجابية أن عدد حاويات Dify ثابت مهما بلغ عدد التطبيقات التي تنشئها عليه، وهذا يجعل التكلفة أكثر استقراراً من OpenBot، حيث يحصل كل زميل عمل من الذكاء الاصطناعي على حاويته ومتصفحه الخاصين، ويؤدي كل موظف جديد إلى رفع الحد الأدنى لاستهلاك الذاكرة مرة أخرى.
لأن Dify تخزّن مفاتيح API الخاصة بنماذجك، وغالباً مستندات خاصة حمّلتها للاستخدام في الاسترجاع، فعامل الخادم الذي يشغّلها على أنه حساس منذ الدقيقة الأولى. يثبّت هذا الدليل Dify، ثم يعزّز أمانها بالطريقة التي تعزّز بها أمان أي خدمة تحتفظ بأسرار.
المتطلبات المسبقة
تحتاج إلى VPS يعمل بنظام Ubuntu 24.04، مع تثبيت Docker وإضافة Docker Compose، وإلى مستخدم يملك sudo أو ينتمي إلى المجموعة docker. إذا كنت جديداً على Docker، يشرح أساسيات Docker Compose على VPS خطوات التثبيت والأوامر الأساسية التي يفترضها هذا الدليل. من الأفضل أن يكون لديك اسم نطاق موجّه إلى الخادم، لأنك ستحتاج إلى وضع TLS أمام Dify بدلاً من استخدام عنوان IP مجرد.
الخطوة 1: الحصول على Dify وملفات Compose
يحتفظ Dify بإعداد Docker في المستودع الرئيسي. استنسخه وانتقل إلى دليل docker:
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .envيمثل ملف .env الإعداد الكامل. اقرأه قبل تشغيل أي شيء. ابدأ بالقيم التي تحدد كلمات المرور والأسرار: SECRET_KEY، وكلمة مرور Postgres، وكلمة مرور Redis. يحتوي ملف المثال على قيم نائبة، وتركها كما هي الطريقة الأكثر شيوعاً لانتهاك خادم Dify مستضاف ذاتياً. أنشئ مفتاحاً سرياً حقيقياً:
openssl rand -base64 42الصق المفتاح في SECRET_KEY، وحدد قيمة قوية وفريدة لكل حقل كلمة مرور في الملف.
الخطوة 2: تشغيله
شغّل المكدس:
docker compose up -dفي التشغيل الأول، يسحب النظام عدة صور ويهيّئ قاعدة البيانات، لذلك انتظر دقيقة. تحقّق من أن الحاويات تعمل بحالة سليمة:
docker compose psيجب أن تقرأ كل خدمة running. يقدّم Dify واجهة الويب عبر حاوية nginx مضمّنة، وتستخدم المنفذ 80 افتراضياً. عند زيارتك الأولى لـhttp://YOUR_SERVER/install، أنشئ حساب المسؤول. نفّذ ذلك فوراً، قبل أن يتمكن أي طرف آخر من الوصول إلى المنفذ، لأن أي شخص يحمّل الصفحة قبل إنشاء ذلك الحساب يستطيع حجزه والسيطرة على مثيلك.
الخطوة 3: لا تعرّضه مباشرة. ضع TLS وجداراً نارياً أمامه
هنا تتوقف معظم عمليات التثبيت السريعة، وتبدأ معظم الحوادث. يستمع nginx الخاص بـDify على المنفذ 80 دون تشفير، وعلى جميع الواجهات. لا تريد نقل تسجيل دخول المسؤول ومفاتيح النماذج عبر HTTP غير المشفّر، ولا تريد أن تكون الخدمات الداخلية قابلة للوصول من الخارج.
أمِّن الخادم باستخدام جدار ناري بمنع افتراضي، ولا تسمح إلا بحركة SSH والويب:
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enableتذكّر أن الجدار الناري الذي يغطي IPv4 فقط قد يترك المنافذ نفسها مفتوحة على IPv6. هذه هي فجوة جدار IPv6 الناري التي تتسبب في مشكلات كثيرة لمشغّلي الخدمات ذاتية الاستضافة. تأكد من تصفية كلا المكدسين.
بالنسبة إلى TLS، المسار الأبسط هو ربط منفذ الويب في Dify بواجهة loopback وتشغيل Reverse Proxy أمامه باستخدام شهادة من Let's Encrypt، بحيث يكون الـproxy هو العنصر الوحيد المتاح على الإنترنت العام ويتحدث عبر HTTPS. يتيح لك .env تغيير المنفذ المكشوف؛ اضبطه ليرتبط بـ127.0.0.1 ووجّه الـproxy إليه. تنطبق هنا أيضاً أفكار تحصين الوكيل الواردة في تشغيل وكيل AI بأمان على VPS: أبقِ المكونات المتغيرة على loopback، ولا تكشف إلا ما يجب أن يكون عاماً، واجعل بوابة أمامية واحدة محصّنة تتولى TLS. إذا كانت واجهة أداة ما مخصصة لك وحدك ولا تحتاج إلى شهادة TLS إطلاقاً، فتجاوز الـproxy واتصل بها عبر SSH tunnel، كما يحافظ استضافة open-kritt security scanner ذاتياً على ربط لوحة التحكم بـloopback وتمريرها إلى حاسوبك المحمول بدلاً من نشرها. إذا احتاج فريق كامل إلى Dify، لكن من دون إتاحته على الإنترنت العام، فشبكة overlay توسّع هذه الفكرة لتتجاوز حاسوباً محمولاً واحداً: يتيح إعلان الشبكة الفرعية الخاصة بالخادم إلى tailnet الخاص بك لكل جهاز معتمد الوصول إلى أداة البناء عبر عنوان خاص، بينما يظل جدار الحماية مغلقاً أمام كل شيء باستثناء SSH. إذا كنت تدير هذا الخادم عبر coding agent بدلاً من إدارته يدوياً، فحدّد مقدار ما يمكنه تنفيذه دون إشراف قبل أن تمنحه المفاتيح، لأن وضع الأذونات الذي تترك Claude Code يعمل به يحدد ما إذا كان سيتوقف لطلب التأكيد قبل إعادة كتابة .env أو إعادة تشغيل المكدس. إذا انتهى بك الأمر إلى جلسة تراقب سجلات الحاويات باستمرار بينما تعدّل جلسة أخرى إعدادات الـproxy، فيمكن لهاتين الجلستين تمرير النص بينهما على الخادم نفسه، وهذا أفضل من نسخ المخرجات بين الطرفيات في كل مرة تعيد فيها تشغيل المكدس.
الخطوة 4: حافظ على تثبيت التحديثات
يتطور Dify بسرعة، وتتضمن التحديثات إصلاحات أمنية. يتطلب تحديثه سحب التغييرات وإعادة التشغيل من الدليل docker:
git pull
docker compose pull
docker compose up -dاقرأ ملاحظات الإصدار قبل الانتقال إلى إصدار رئيسي أحدث، لأن Dify يغيّر أحياناً مخطط .env بين الإصدارات، وقد يؤدي متغير جديد لم تضبطه إلى منع حاوية من بدء التشغيل.
الخطوة 5: انسخ احتياطياً ما لا يمكنك إعادة إنشائه
هناك شيئان لا يمكن تعويضهما على خادم Dify: قاعدة بيانات Postgres التي تحتوي على تطبيقاتك ومستخدميك وإعداداتك، ووحدة التخزين التي تحفظ المستندات التي رفعتها وفهرس المتجهات. يوجد كلاهما ضمن وحدات Docker في الدليل docker. أنشئ لقطات لهما وفق جدول زمني، وانسخ هذه اللقطات خارج الخادم. تحتوي هذه اللقطات على كل مفاتيح النماذج والمستندات التي رفعتها في ملف واحد، لذلك شفّرها قبل إخراجها من الخادم، للسبب نفسه الذي يجعل نسخة Vaultwarden الاحتياطية نقطة الضعف في خادم كلمات مرور متين بوجه عام. يمكن إصدار مفتاح API للنموذج من جديد، لكن لا يمكن إعادة إنشاء التطبيق الذي قضيت أسبوعاً في بنائه. وينطبق المنطق نفسه على أي وكيل يجب أن تبقى حالته بعد انتهاء عمر الجهاز الذي يعمل عليه: إبقاء KiroCrew قيد التشغيل في حاوية تعمل دائماً يتطلب إنشاء لقطات للذاكرة والجداول الزمنية التي كانت ستختفي عند إعادة التشغيل التالية.
عندما تريد أن تصل الوكلاء الذين تبنيهم هنا إلى ما يتجاوز مجموعات بياناتك وتبحث في الويب المباشر، فإن توجيههم إلى نسخة SearXNG مستضافة ذاتياً يُبقي تدفق الاستعلامات على أجهزة تتحكم بها، لكن من المفيد أن تقرأ عن سطح هجمات prompt injection الذي ينفتح قبل تفعيله. للحصول على وكيل أكثر استقلالية يشغّل التعليمات البرمجية، راجع استضافة Agent Zero ذاتياً، بينما يشرح بناء وكيل AI خاص بك على VPS الأسس المشتركة بينها جميعاً.
FAQ
ما متطلبات النظام لاستضافة Dify ذاتياً؟
يعمل Dify كمجموعة Docker Compose تضم نحو ست حاويات، لذلك خطط لاستخدام VPS يتوفر فيه ما لا يقل عن 2 GB من الذاكرة RAM، ويفضل 4 GB، إضافة إلى نواتي CPU تقريباً ومساحة قرص كافية للمستندات التي ترفعها وفهرس المتجهات. يأتي ضغط الذاكرة من قاعدة البيانات ومخزن المتجهات، وليس من Dify نفسه.
هل من الآمن تعريض Dify مباشرة على المنفذ 80؟
لا. يستمع خادم الويب المضمّن في Dify عبر HTTP العادي، ويعرض صفحة تسجيل دخول المسؤول ومفاتيح API الخاصة بالنماذج. ضع reverse proxy مع شهادة Let's Encrypt أمامه، واربط منفذ Dify نفسه بـ loopback، ودع proxy الذي يستخدم HTTPS وحده يواجه الإنترنت. واجعل ذلك مقترناً بجدار ناري يعتمد المنع الافتراضي ويغطي IPv4 وIPv6 معاً.
كيف أحدّث Dify المستضاف ذاتياً؟
من الدليل docker، شغّل git pull، ثم docker compose pull وdocker compose up -d لجلب الصور الجديدة وإعادة التشغيل. اقرأ ملاحظات الإصدار أولاً، لأن Dify يضيف أحياناً متغيرات .env جديدة بين الإصدارات، وقد يؤدي غياب أحدها إلى منع حاوية من بدء التشغيل.
ما أول إجراء يجب اتخاذه بعد تثبيت Dify؟
انتقل إلى /install وأنشئ حساب المسؤول فوراً. إلى أن يوجد هذا الحساب، يمكن لأي شخص يصل إلى الصفحة الاستيلاء عليها. أعدّده بمجرد أن تصبح الحاويات في حالة سليمة، وقبل أن تفتح الجدار الناري أمام الإنترنت.