لماذا تستضيف Directus ذاتيًا على خادم VPS
يتّصل Directus بقاعدة بياناتك الحالية (PostgreSQL أو MySQL أو SQLite أو MariaDB) دون فرض مخططه الخاص: فهو يفحص جداولك ويولّد واجهة برمجية وواجهة إدارة فوقها. باستضافته ذاتيًا على خادم VPS، تتجنّب التسعير لكل مقعد في العرض السحابي الرسمي، وتحتفظ بمحتواك ووسائطك وقاعدة بيانات SQL الخاصة بك على بنيتك التحتية. إنه خيار هيكلي للوكالات التي تسلّم عدة مواقع: يمكن لـ Directus واحد أن يعمل كمكتب خلفي لعدة واجهات أمامية (Nuxt وNext والجوال). ويتيح لك التحكم في قاعدة البيانات والإضافات وwebhooks دمج Directus في أي مسار بيانات دون الاعتماد على مزوّد خارجي، دون خدمة طرف ثالث تتوسّط بين واجهاتك الأمامية وبياناتك.
الفوائد الملموسة للاستضافة الذاتية لـ Directus
- واجهات REST وGraphQL برمجية مُولّدة تلقائيًا من مخطط SQL الخاص بك، دون كتابة كود.
- واجهة إدارة بدون كود لنمذجة المحتوى وإدارة الأدوار والصلاحيات الدقيقة.
- متوافق مع قاعدة بيانات SQL موجودة: يمكنك كشفها دون ترحيلها أو تشويهها.
- إدارة الوسائط، وتحويلات الصور الفورية، وتخزين محلي أو على S3 حسب اختيارك.
- Flows وwebhooks مدمجة لأتمتة المعالجات (الإشعارات والمزامنة).
- الاستخدام المشترك: يمكن لخادم VPS واحد يشغّل Directus أن يغذّي عدة مواقع وتطبيقات واجهة أمامية.
المتطلبات المادية والبرمجية
Directus هو تطبيق Node.js يعتمد على قاعدة بيانات خارجية. احسب حدًا أدنى من 2 غيغابايت من RAM لتشغيل Directus وPostgreSQL بأريحية على خادم VPS نفسه؛ ويُوصى بـ 4 غيغابايت في الإنتاج مع تحويلات الصور وعدة مسؤولين متزامنين. يكفي معالج افتراضي إلى معالجين للبدء. خطّط لذاكرة Redis مؤقتة (اختيارية لكن يُنصح بها للجلسات وتحديد المعدل) ووحدة تخزين من 30 إلى 60 غيغابايت SSD حسب مكتبة وسائطك. ستحتاج إلى Docker وDocker Compose، ونطاق يشير إلى خادم VPS، ومفتاح سري قوي لـ SECRET وتجزئة الرموز (tokens). ويبقى Postgres قاعدة البيانات الموصى بها للميزات المتقدمة.
نشر Directus خطوة بخطوة
تجهيز خادم VPS وDocker
بعد الاتصال عبر SSH، ثبّت Docker وDocker Compose. أنشئ سجل DNS من النوع A لـ
cms.mydomain.comيشير إلى عنوان IP الخاص بخادم VPS. افتح المنفذين 80 و443 فقط في جدار الحماية (ufw allow 80,443/tcp).تعريف الحزمة في docker-compose.yml
أعلن عن ثلاث خدمات:
database(صورةpostgres:16مع وحدة تخزين دائمة)، وcache(redis)، وdirectus(directus/directus). اربط Directus بـ Postgres عبر المتغيّراتDB_CLIENT=pgوDB_HOST=databaseوDB_DATABASEوDB_USERوDB_PASSWORD.تهيئة متغيّرات البيئة
املأ
KEYوSECRETبسلاسل عشوائية (openssl rand -hex 32)، وحدّدADMIN_EMAILوADMIN_PASSWORDللحساب الأول، وPUBLIC_URL=https://cms.mydomain.comلتكون الروابط والملفات المرفوعة صحيحة.بدء التشغيل وتهيئة قاعدة البيانات
نفّذ
docker compose up -d. عند أول تشغيل، يُنشئ Directus جداول النظام وحساب الإدارة تلقائيًا. تابع التهيئة بـdocker compose logs -f directus.توصيل الوكيل العكسي وTLS
ضع Caddy أو Traefik أمام Directus لإدارة Let's Encrypt. مع Traefik، أضف تسميات التوجيه على خدمة
directusوأداة حل الشهادات (certresolver) الخاصة بـ ACME. تأكد من أنPUBLIC_URLيطابق تمامًا نطاق HTTPS لتجنّب مشكلات CORS ورفع الملفات.التأمين والنسخ الاحتياطي
قيّد أصول CORS على نطاقات واجهاتك الأمامية، وعطّل التسجيل العام إن لم يكن ضروريًا، ثم جدوِل
pg_dumpيوميًا بالإضافة إلى نسخة من مجلدuploadsإلى تخزين بعيد.
لخدمة الصور بأداء عالٍ، فعّل تخزين الوسائط على حاوية متوافقة مع S3 بدلاً من القرص المحلي، واضبط ASSETS_CACHE_TTL: يحدد هذا المتغيّر مدة التخزين المؤقت في المتصفح (قيمة max-age في ترويسة Cache-Control، وهي 30 يومًا افتراضيًا)، ولا يخزّن التحويلات مؤقتًا على الخادم. ضع شبكة CDN أمام Directus لتخفيف طلبات الوسائط عن خادم VPS. ثم قيّد التحويلات الفورية: يحدّ ASSETS_TRANSFORM_MAX_OPERATIONS من عدد العمليات في الطلب الواحد (5 افتراضيًا، دون احتساب الإعدادات المسبقة المحفوظة)، ويحدّ ASSETS_TRANSFORM_IMAGE_MAX_DIMENSION من الأبعاد بالبكسل (6000 افتراضيًا)، ويحدّ ASSETS_TRANSFORM_MAX_CONCURRENT من عدد التحويلات المتزامنة (25 افتراضيًا).
تقديم الملفات من S3: ما الذي يتغيّر في الذاكرة
عندما يشير تخزين الوسائط إلى حاوية متوافقة مع S3، لا يعيد Directus توجيه الزائر إلى الحاوية: يمرّ الطلب /assets/FILE_ID عبر عملية Node التي تقرأ الكائن من المزوّد وتبثّه إلى العميل على شكل تدفّق. يُضبط المشغّل بمتغيرات: STORAGE_LOCATIONS=s3 ثم STORAGE_S3_DRIVER=s3 وSTORAGE_S3_KEY وSTORAGE_S3_SECRET وSTORAGE_S3_BUCKET وSTORAGE_S3_REGION، ومع تخزين متوافق مثل MinIO يُضاف STORAGE_S3_ENDPOINT مع STORAGE_S3_FORCE_PATH_STYLE=true. والنتيجة العملية أن ذاكرة الحاوية تتوقف على عدد التنزيلات المتزامنة وسرعة كل عميل، لا على حجم قاعدة البيانات وحده. وعلى هذا المسار يبلّغ مستخدمون عن استهلاك لا ينخفض، خصوصًا مع مقاطع الفيديو والملفات الكبيرة.
استكشاف الأخطاء: الذاكرة ترتفع حتى تتوقف الحاوية
يرد وصف هذا العَرَض في البلاغ 26206 من مستودع directus/directus، الذي فُتح في نوفمبر 2025 على نسخة Docker مستضافة ذاتيًا بالإصدار 11.13.2 مع PostgreSQL 16: ترتفع ذاكرة الحاوية باطّراد حتى الحد المضبوط، ثم تُقتل الحاوية وتُعاد. الميل أخفّ ليلًا وفي عطلة نهاية الأسبوع، ما يشير إلى حركة الملفات لا إلى تسرّب في وضع الخمول. وعند كتابة هذا المقال (أواخر أكتوبر 2026) ما زال البلاغ مفتوحًا بوسوم Bug وPerformance وAWS S3. لم يؤكد أي عضو في فريق Directus سببًا هناك: كل ما يلي فرضيات من المشاركين، لا تشخيصًا من الصيانة.
ما يذكره المشاركون في البلاغ
- ملفات ثقيلة — تُستنسخ المشكلة بسكربت حمل k6 على مقاطع فيديو من 36 إلى 86 ميغابايت، وعلى اثني عشر ملفًا بنحو 500 ميغابايت؛ ويمرّ الطلب عبر
/assets. - عدة وسائط تخزين — يُذكر AWS S3 وMinIO، وكذلك خدمة أخرى متوافقة مع S3 لدى مزوّد تطبيقات.
- نمو بطيء مع الصور — ينتقل أحد المشاركين من نحو 200 ميغابايت بعد إعادة النشر إلى 1 غيغابايت خلال أيام؛ ويرى آخر حاويات ترتفع من 1.3 غيغابايت إلى أكثر من 2 غيغابايت في قرابة أسبوعين.
- فرضية التدفقات غير المغلقة — يوجد إصلاح ينظّف التدفقات حين ينقطع اتصال العميل أثناء التنزيل؛ ويضعه أحد المساهمين في 11.17.2، ويلاحظ مشارك تحسنًا دون اختفاء النمو.
- فرضية مجموع التحقق — في أكتوبر 2026 يعزو أحد المشاركين المشكلة إلى التحقق من مجموع الاختبار لاستجابات SDK الخاص بـ AWS S3: فتدفّق التحقق (
ChecksumStreamمن الحزمة@smithy/util-stream) يتجاهل الضغط العكسي بحسب قوله. وقد جرّب ذلك بحد 1 غيغابايت (GiB) وكائن بحجم 150 ميغابايت؛ عميل بطيء واحد يرفع الذاكرة الخارجية من 8 إلى 160 ميغابايت، وثلاثة عملاء يتسببون في الإيقاف خلال 15 ثانية، أما الملفات المرفوعة على أجزاء (multipart) فلا تُحدث الحالة. ويوضح أن ذلك لا يفسّر النمو البطيء على مدى أيام دون تنزيلات كبيرة. - تقرير عن الإصدار 12 — يذكر مشارك آخر أن الترقية إلى الإصدار 12 حلّت المشكلة عنده، بينما يبقى البلاغ مفتوحًا.
التشخيص دون تخمين
تأكيد الإيقاف بسبب نفاد الذاكرة
ابحث عن أثر النواة بالأمر
dmesg -T | grep -i "out of memory"، أو تابعdocker events --filter event=oom، أو اقرأ الحقلOOMKilledفيdocker inspect. هذا النوع من الإيقاف لا يترك أي رسالة خطأ من Directus: تُعاد الحاوية ببساطة.ضبط حد صريح للذاكرة
في ملف Compose، امنح الخدمة
directusحدًا (mem_limitأوdeploy.resources.limits.memory) أقل من ذاكرة RAM الحرة في خادم VPS، معrestart: unless-stopped. وبلا حد، تختار نواة المضيف بنفسها أي عملية تقتلها، وأحيانًا PostgreSQL بدل Directus.قياس المنحنى
سجّل
docker stats --no-streamكل دقيقة في ملف، مع عدد طلبات/assetsالجارية. دوّن القيمة بعد إعادة التشغيل والهضبة، وهل يتبع المنحنى الحركة أم يرتفع في الخمول. حدّ كومة Node (--max-old-space-size) لا يقيّد الذاكرة خارج الكومة، أي المخازن المؤقتة، وهي المنطقة التي تستهدفها فرضية مجموع التحقق.الاستنساخ بعميل بطيء
في بيئة اختبار، وليس في الإنتاج أبدًا، نزّل ملفًا كبيرًا بالأمر
curl --limit-rate 200k -o /dev/null https://cms.mydomain.com/assets/FILE_IDمن عدة طرفيات وراقبdocker stats. وسكربت k6 يفعل الأمر نفسه بطريقة أكثر قابلية للتكرار.التقاط ملفَّي تعريف للكومة
أضف
NODE_OPTIONS=--heap-prof --heap-prof-dir=/directus/profilesإلى بيئة الخدمة، مع مجلد مركّب كوحدة تخزين. لا يكتب Node ملف التعريف إلا عند خروج العملية خروجًا سليمًا: أوقف الحاوية بالأمرdocker compose stop directusمرة أولى بعد الإقلاع مباشرة (مرجع)، ثم مرة ثانية حين تتضخم الذاكرة. الإيقاف بسبب نفاد الذاكرة يقتل العملية دون كتابة أي ملف تعريف.
حلول بديلة مبلَّغ عنها، لم يؤكد فريق Directus أيًّا منها
لم تنل أي من هذه المسارات تأكيدًا رسميًا في البلاغ. جرّبها في بيئة ما قبل الإنتاج، وقِس قبل التطبيق وبعده، ولا تقدّمها على أنها إصلاحات.
مسارات مبلَّغ عنها لمشكلة الذاكرة
مرّر الجدول أفقيًا
| المسار | مصدر التقرير | الحالة والتحفظات |
|---|---|---|
| `AWS_RESPONSE_CHECKSUM_VALIDATION=WHEN_REQUIRED` | مشارك، في أكتوبر 2026، مع بيئة اختبار | لم يؤكده الفريق. وبحسب وثائق AWS لا يُجرى التحقق من مجموع اختبار التنزيل إلا إذا فعّله المستدعي صراحةً: فتفقد هذا الفحص للسلامة. |
| الترقية إلى الإصدار 12 | مشارك يقول إنها حلّت المشكلة؛ وآخر يضع إصلاحًا ابتداءً من 12.3.1 | غير مؤكدة. ملاحظات الإصدار 12.3.1 تذكر فقط تحديث اعتماديات مشغّلات التخزين. تغيير إصدار رئيسي: اقرأ الملاحظات وانسخ احتياطيًا قبل ذلك. |
| الإصدار 11.17.2 أو أحدث | مساهم يوصي به لتنظيف تدفقات العملاء المنقطعين | الإصلاح مدموج ويغلق بلاغًا آخر (26991)؛ وفي البلاغ 26206 يصف مشارك تحسنًا مع استمرار النمو. |
| إعادة نشر مجدولة عبر cron | مشارك، كحل مؤقت | يخفي العَرَض دون إصلاح شيء، ويقطع التنزيلات الجارية. |
| حد للذاكرة وإعادة تشغيل تلقائية | توصية تشغيلية من هذا الدليل | يحصر الضرر: تُعاد الحاوية بسلاسة بدل جرّ المضيف معها. ولا يعالج السبب. |
ما الذي يجب جمعه لتقرير خلل مفيد
طلب الفريق ملفات تعريف للكومة: وبدونها لا يمكن للبلاغ أن يتقدم. قبل التعليق أو فتح بلاغ جديد، اجمع العناصر التالية.
الملف الذي يُرفق
- الإصدار الدقيق — وسم صورة Directus (وليس
latest) وتاريخ آخر إعادة تشغيل. - التخزين — المشغّل والمزوّد (AWS أو MinIO أو غيرهما) والمنطقة، دون المفتاح أو السر، مع قيمة
AWS_RESPONSE_CHECKSUM_VALIDATIONإن كانت معرّفة. - الحدود — ذاكرة الحاوية وذاكرة RAM للمضيف وسياسة إعادة التشغيل.
- الحمل — عدد الملفات المقدَّمة وأحجامها، والتنزيلات المتزامنة، ووجود CDN أو وكيل أمام Directus، والعملاء البطيئين أو المنقطعين.
- منحنى الذاكرة — الذاكرة الإجمالية للحاوية (لا للعملية وحدها) على مدى عدة أيام، مع حركة
/assetsبجانبها. - ملفا تعريف للكومة — مرجعي وآخر في حالة التضخم. ويوضح المساهم الذي يطلبهما أنهما لا يحتويان إلا على آثار المكدس وأحجام تخصيص مأخوذة بالعينات، لا محتوى الملفات ولا الأسرار.
- طريقة رفع الملفات — دفعة واحدة أم على أجزاء (multipart)، لأن مشاركًا يؤكد أن الأخيرة لا تُحدث الحالة.
قبل الترقية إلى الإصدار 12، اقرأ ملاحظات الإصدار 12.3.0: فهو يصلح اتصالات تخزين كانت تتسرّب عند إلغاء طلب أصل أو فشل تحويل، لكنه يغيّر أيضًا سلوك exists() الذي يرمي الآن خطأً بدل إرجاع القيمة خطأ. ومع S3 قد يعطي كائن غير موجود استجابة 403 بدل 404 إذا لم تسمح بيانات الاعتماد بسرد محتوى الحاوية: امنح الصلاحية s3:ListBucket. انسخ قاعدة البيانات والملفات احتياطيًا، ثم اختبر الترقية على نسخة قبل لمس الإنتاج.
نشر Directus بنقرة واحدة على ServOrbit
يتوفر Directus مباشرةً من سوق ServOrbit. اختر التطبيق عند طلب خادم VPS: يأتي Docker مُثبَّتاً مسبقاً، وتبدأ حاوية Directus تلقائياً، وتُعرض بيانات اعتمادك ([email protected] وكلمة مرور مُوّلدة) في لوحة ServOrbit. ادخل إلى واجهة الإدارة عبر نفق SSH أو بربط نطاق من لوحتك — دون تثبيت Docker أو تعديل ملف Compose يدوياً.
