n8n مثبَّت عند إنشاء خادمك
إذا اخترت n8n عند طلب خادمك من ServOrbit، فلا شيء عليك تثبيته. عند إنشاء الخادم، تثبّت ServOrbit أداة Docker إن لم تكن موجودة، ثم تشغّل n8n مع قاعدة بياناته PostgreSQL 16 عبر Docker Compose. تستمع الواجهة على 127.0.0.1:5678، أي على واجهة الاسترجاع المحلية للخادم: لا يُنشر شيء على عنوان IP الخاص به، ولا يرتبط به أي نطاق بعد. تكفي الخطوات الأربع التالية لفتحه. أما التثبيت اليدوي، لخادم آخر أو لإعادة بناء كل شيء بنفسك، فموصوف في آخر المقال.
فتح n8n الذي ثبّتته ServOrbit
العثور على العنوان وبيانات الوصول
تُبيّن رسالة البريد «n8n مثبَّتة» وصفحة خادمك في مساحة العميل، ضمن قسم «التطبيقات المثبّتة»، كيف تفتح التطبيق: عنوانه إن كان هناك نطاق مُعَدّ، وإلا فأمر نفق SSH والمنفذ. وتجد هناك أيضًا رابط هذا الدليل وزر «الدعم».
فتح n8n دون نطاق
من حاسوبك، نفّذ
ssh -L 5678:127.0.0.1:5678 root@<vps-ip>واترك الجلسة مفتوحة، ثم افتحhttp://localhost:5678. قد يُعاد تخصيص المنفذ أثناء التثبيت: استخدم المنفذ المعروض في مساحة العميل، إذ ليس 5678 سوى القيمة الافتراضية في الكتالوج.تسجيل الدخول لأول مرة
افعل ذلك دون تأخير: تُنشئ الشاشة الأولى حساب المالك (البريد الإلكتروني والاسم وكلمة مرور من 8 أحرف على الأقل تتضمّن حرفًا كبيرًا ورقمًا)، وأول زائر يصبح مالك النسخة. أنشئ بعد ذلك أول سير عمل: مُشغِّلًا (Webhook أو Cron أو بريد إلكتروني…) ثم التطبيقات التي تريد ربطها.
النشر عبر HTTPS على نطاق
عندما يُثبَّت n8n من مساحة العميل مع عنوان تختاره — نطاقك الخاص أو نطاق فرعي مجاني من ServOrbit — تتولّى المنصة إعداد المضيف الافتراضي في nginx وشهادة Let's Encrypt. أما التثبيت الذي جرى عند إنشاء الخادم، أو دون عنوان، فيُنشر من صفحة الخادم: زر «ربط نطاق» في خانة التطبيق (نطاق من حسابك، أو النطاق الفرعي المجاني، أو اسم توجّهه إلى الخادم). وبعد إعداد النطاق، أضف
N8N_HOST=<domain>وN8N_PROTOCOL=httpsوN8N_WEBHOOK_URL=https://<domain>/(WEBHOOK_URLقبل الإصدار 2.35.0 من n8n) إلى كتلةenvironmentالخاصة بالخدمةn8n، في ملف Compose الخاص بالتطبيق (يعرضdocker compose lsمجلّده)، ثم نفّذdocker compose up -d. ومن دون هذه المتغيّرات، تبقى عناوين الـ webhook التي يولّدها n8n مشيرة إلىlocalhostفلا يمكن الوصول إليها.
لماذا تستضيف n8n على VPS الخاص بك
تفرض النسخة السحابية من n8n رسومًا على كل عملية تنفيذ تتجاوز الخطة وتحدّ من عدد مسارات العمل النشطة. على VPS الخاص بك، التكلفة الوحيدة هي تكلفة الخادم، بصرف النظر عن عدد الأتمتات أو استدعاءات API. كما تحتفظ بالتحكم الكامل في بيانات الاعتماد وحمولات webhooks وتاريخ التنفيذ — لا تنتقل أي بيانات عبر بنية تحتية خارجية.
الفوائد الملموسة لـ n8n مُستضاف ذاتيًا
- عمليات تنفيذ غير محدودة: دون سقف شهري ودون تكلفة على الحجم.
- بيانات الاعتماد وحمولات webhooks محصورة في خادمك دون عبور خارجي.
- الوصول إلى العقد المجتمعية وتنفيذ الكود المخصص دون قيود.
- Webhooks على نطاقك الخاص، قابلة للإعداد لكل تكامل وارد.
- تكلفة قابلة للتنبؤ: سعر VPS ثابت مستقل عن حجم الأتمتات.
- استمرارية مُدارة لمسارات العمل والسجل في وحدات تخزين تأخذ منها نسخًا احتياطية.
- توافق مع Ollama وFlowise وأي خدمة Docker أخرى على نفس الشبكة الداخلية.
تأمين التنفيذات المُخزَّنة (تنبيه GHSA-vrv8-j27g-g7cr)
في أغسطس 2026، كشف التنبيه GHSA-vrv8-j27g-g7cr أن ثلاث عقد تكتب بيانات الاعتماد المفكوكة التشفير في بيانات التنفيذ المُخزَّنة عند حدوث خطأ: عقدة Strapi (رموز OAuth مكتوبة بنص صريح في execution_data)، وعقدة SeaTable (مفاتيح API مدوّنة في سجلات تنفيذ الخطأ)، وعقدة Mailcheck (بيانات اعتماد SMTP مُخزَّنة في execution_data). تبقى هذه الأسرار قابلة للقراءة من قِبَل أي مستخدم يمتلك صلاحية الاطلاع على سجلات التنفيذ في واجهة n8n. على نسخة بلا تنظيف، تتراكم هذه البيانات إلى أجل غير مسمى.
أربع خطوات للإصلاح والوقاية
التحديث إلى الإصدار المُصلَح للتنبيه
التحديث هو الإصلاح الوحيد الكامل للعقد الثلاث. تحقّق من إصدارك الحالي:
docker exec n8n n8n --version. اسحب الصورة الأخيرة وأعد التشغيل:docker compose pull && docker compose up -d. في الفرع المستقر، يتوفر الإصلاح ابتداءً من الإصدار 2.35.4؛ في الفرع v1، ابتداءً من الإصدار 1.123.73.تفعيل تنظيف التنفيذات
أضف متغيّرين في قسم
environmentلخدمة n8n:EXECUTIONS_DATA_PRUNE=trueوEXECUTIONS_DATA_MAX_AGE=168(7 أيام، بالساعات). أعد تشغيل الحاوية:docker compose restart n8n. يحذف التنظيف بيانات التنفيذ التي تتجاوز العمر المحدد — لكنه لا يُغني عن التحديث.تقييد الوصول إلى سجلات التنفيذ
في وضع متعدد المستخدمين، تحقّق في الإعدادات → المستخدمون من أن المسؤولين وحدهم يستطيعون الاطلاع على سجلات التنفيذ. يحدّ هذا الإجراء من انتشار البيانات الحساسة إذا خُزِّنت قبل التحديث.
إجراء احترازي قبل التحديث
على نسخة لم تُحدَّث بعد: عطّل أو احذف مسارات العمل التي تستخدم عقد Strapi أو SeaTable أو Mailcheck. لا تُطلق الثغرة إلا عند خطأ في التنفيذ على هذه العقد، لكن الخطأ قد يحدث عند انقطاع الشبكة أو انتهاء صلاحية الرمز.
عطل V8 الحرج مع أكثر من 30 مسار عمل نشط
العَرَض. تتوقف نسخة n8n فجأة مع الخطأ FATAL ERROR: invalid-mark-compact are transition في سجلات Docker. تُعيد الحاوية تشغيلها إذا كان restart: unless-stopped مُفعَّلًا، لكن العطل يتكرر فور تجاوز الحمل نفس العتبة.
السبب. هذا الخطأ نتيجة هلع محرك V8 خلال دورة جمع النفايات. يحدث حين تمتلئ كومة V8 — عادةً عند 30 مسار عمل تعمل في آنٍ واحد على VPS بأقل من 2 GB من الذاكرة.
الإصلاح الفوري. أضف NODE_OPTIONS=--max-old-space-size=2048 في البيئة. أعد تشغيل الحاوية: docker compose restart n8n.
الإصلاح البنيوي. خصّص على الأقل 2 GB من RAM للـ VM عند تجاوز 30 مسارًا نشطًا. لأكثر من 50 مسارًا، يُفضَّل وضع queue مع Redis. المصدر: community.n8n.io thread #308425.
خطأ 502 Bad Gateway المستمر خلف nginx
العَرَض. تنجح الطلبات القصيرة لكن مسارات عمل معينة تُرجع 502 Bad Gateway بعد 60 ثانية بالضبط من بدء التنفيذ.
السبب. ينتظر nginx افتراضيًا 60 ثانية ردًا من الخادم الخلفي (proxy_read_timeout = 60 ث). إذا استغرق التنفيذ أكثر، قطع nginx الاتصال.
الإصلاح. أضف في كتلة location لإعداد nginx:
proxy_read_timeout 300;proxy_send_timeout 300;
أعد تحميل nginx: nginx -t && systemctl reload nginx. المصدر: community.n8n.io thread #274581.
التغييرات الكاسرة التي يجب معرفتها (v1.27–v1.31)
ثلاثة تغييرات في الإصدارات الأخيرة قد تُعطِّل نسخة قائمة بصمت.
إعادة تسمية معلمة OAuth 2.0 في HTTP Request. قد تتوقف الطلبات المصادَق عليها عبر OAuth 2.0 دون رسالة خطأ صريحة.
صيغة URL الـ webhook. أعد التحقق من روابط webhook المثبّتة في خدمات الأطراف الثالثة.
إهمال $item(). البديل $input.item أو $('اسم العقدة').item.
القائمة الكاملة في التوثيق الرسمي لـ n8n.
استكشاف الأخطاء الشائعة وإصلاحها
المنفذ 5678 غير متاح. تحقّق من تشغيل الحاوية وإعداد الربط على 127.0.0.1:5678.
تعرض Webhooks localhost. المتغيّر N8N_WEBHOOK_URL غائب — أضفه مع الشرطة المائلة الأخيرة وأعد تشغيل الحاوية.
خطأ في أذونات الحجم. chown -R 1000:1000 /opt/n8n/data ثم إعادة تشغيل الحاوية.
ترفض قاعدة PostgreSQL الاتصال. تحقّق من الشبكة والمتغيّرات.
عطل V8 الحرج. أضف NODE_OPTIONS=--max-old-space-size=2048. انظر القسم المخصص.
502 Bad Gateway المستمر. ارفع proxy_read_timeout إلى 300 ث. انظر القسم المخصص.
بيانات الاعتماد مرئية في السجلات. حدّث n8n وفعّل تنظيف التنفيذات. انظر القسم المخصص.
SQLite rollback صامت تحت الحمل. الأعراض: تنفيذات مفقودة أو نتائج غير متسقة دون خطأ مرئي تحت التزامن العالي. السبب: SQLite لا يدعم الكتابة المتزامنة (issue GitHub n8n #32284). الحل الوحيد: الانتقال إلى PostgreSQL.
SQLite أم PostgreSQL: الاختيار الذي يغيّر كل شيء في الإنتاج
SQLite محرك اختبار، لا محرك إنتاج. يصلح تمامًا لاكتشاف n8n على جهاز محلي أو التحقق من مسار عمل قبل النشر. بمجرد أن تستقبل نسختك حركة مرور حقيقية — مسارات عمل متعددة تُشغَّل بالتوازي، webhooks واردة، عمليات تنفيذ مجدولة متزامنة — يصبح SQLite خطرًا. توثّق issue GitHub n8n #32284 rollbacks صامتة تحت الحمل المتزامن: تختفي التنفيذات من السجل دون رسائل خطأ، وتُكتب النتائج المرحلية بشكل جزئي.
الانتقال إلى PostgreSQL. الإجراء في ثلاث خطوات:
1. صدّر مسارات العمل من النسخة الحالية: n8n export:workflow --all --output=/opt/n8n/workflows-backup.json
2. عدّل ملف .env لتغيير المحرك: DB_TYPE=postgresdb مع المتغيّرات المناسبة.
3. أعد تشغيل الكل (docker compose up -d) ثم استورد: n8n import:workflow --input=/opt/n8n/workflows-backup.json.
التخزين المستمر المستقل. يجب أن يُركَّب حجم PostgreSQL (pg_data) على تخزين مستمر مستقل عن المضيف — حجم Docker مسمى أو bind mount على مجلد يُحتفظ بنسخ احتياطية منه.
التحجيم. يستهلك PostgreSQL ما بين 50 و100 MB إضافية من الذاكرة العشوائية مقارنةً بـ SQLite تحت حمل خفيف. خطّط لـ 2 GB من RAM كحد أدنى، و4 GB إذا كنت تشغّل مسارات ذكاء اصطناعي أو استيرادات ضخمة بانتظام.
أربع إعدادات حرجة لإنتاج مستقر
هذه النقاط الأربع تركّز جوهر الحوادث المُبلَّغ عنها على community.n8n.io وDEV Community عام 2026. كل واحدة مستقلة ويمكن تطبيقها على نسخة قائمة دون إعادة نشر كاملة.
1. N8N_WEBHOOK_URL إلزامي في ملف .env. بدون هذا المتغيّر، يُعيد n8n بناء URL الـ webhook بالجمع بين اسم المضيف الداخلي للحاوية والمنفذ 5678. النتيجة تبدو كـ http://n8n_container:5678/webhook/… — عنوان غير صالح من أي خدمة خارجية. ضع N8N_WEBHOOK_URL=https://n8n.your-domain.com/ (مع الشرطة المائلة الأخيرة) في ملف .env ولا تحذفه أبدًا.
2. الحد الأدنى من الذاكرة 2 GB، ويُوصى بـ 4 إلى 8 GB. VPS بـ 1 GB من الذاكرة غير كافٍ بمجرد أن ينفّذ n8n عدة مسارات متزامنة. يقتل OOM killer لينوكس عملية Node.js دون سجل واضح في n8n — تختفي الحاوية ويعيد restart: unless-stopped تشغيلها، مما يخلق دورة أعطال يصعب تشخيصها.
3. رؤوس WebSocket في nginx إلزامية للمحرر. تتواصل واجهة n8n مع الخلفية عبر WebSocket للتنفيذ الفوري وتحديثات الحالة. بدون هذين الرأسين في كتلة location في nginx، يُرفض اتصال WebSocket ويصبح المحرر غير متاح أو يتجمد:
proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";
يعالجهما Caddy تلقائيًا عبر reverse_proxy؛ مع nginx يجب إضافتهما صراحةً.
4. التنظيف التلقائي لسجل التنفيذ. بدون تنظيف، تنمو جدول التنفيذات إلى ما لا نهاية. على نسخة نشطة لأشهر عدة، يمكن أن تبلغ عدة غيغابايت وتُدهور الأداء بشكل ملحوظ. فعّل التنظيف التلقائي بمتغيّرين:
EXECUTIONS_DATA_PRUNE=trueEXECUTIONS_DATA_MAX_AGE=168
القيمة 168 تعادل 7 أيام بالساعات. عدّلها حسب احتياجك — 720 لـ 30 يومًا، 336 لـ 14 يومًا.
الصيانة والتوسع
للتحديثات: Watchtower أو مهمة cron يدوية (docker pull n8nio/n8n:latest && docker compose up -d). احتفظ بتصديرات مسارات العمل في مستودع git.
لتنبيهات الأمان، تابع صفحة GitHub Security Advisories لمستودع n8n.
التثبيت اليدوي (حل بديل)
تصف الأقسام التالية تثبيت n8n يدويًا عبر Docker Compose: لخادم لم تثبّت عليه ServOrbit تطبيق n8n، أو لإعادة بناء كل شيء بنفسك. أما على خادم ثبّتته عليه ServOrbit، فلا حاجة إليها.
المتطلبات بالأرقام
قبل البدء، تأكّد من أن VPS الخاص بك يستوفي المتطلبات التالية. للاستخدام المعتدل، 1 vCPU و1 GB من RAM كافيان؛ خطّط لـ 2 vCPU و2 GB حين تنفّذ مسارات عمل ثقيلة أو متزامنة، و4 GB إذا ربطت قاعدة بيانات PostgreSQL مخصّصة أو دمجت نموذج ذكاء اصطناعي محلي. خصّص 10 GB من القرص كحدٍّ أدنى لـ Docker والأحجام والسجلات. يجب ألا يكون المنفذ 5678 مكشوفًا مباشرةً — لا يستمع n8n إلا على 127.0.0.1:5678. يُلزَم وجود نطاق فرعي (مثل n8n.your-domain.com) يشير إلى IP الـ VPS لـ HTTPS وwebhooks الواردة.
التثبيت خطوة بخطوة
تحديث VPS وتثبيت Docker
اتصل عبر SSH وحدّث الحزم:
apt update && apt upgrade -y. ثم ثبّت Docker عبر السكريبت الرسمي:curl -fsSL https://get.docker.com | sh. تحقّق من التثبيت:docker --version && docker compose version. أنشئ مجلد العمل:mkdir -p /opt/n8n && cd /opt/n8n.إنشاء ملف docker-compose.yaml
أنشئ
docker-compose.yamlمع خدمة n8n، وحجم مسمّى للاستمرارية والمتغيّرات البيئية الأساسية. أعلنimage: n8nio/n8n:latest،restart: unless-stopped، وارفقn8n_data:/home/node/.n8n. اكشف فقط على127.0.0.1:5678:5678لتجنّب أي كشف عام مباشر للمنفذ.ضبط المتغيّرات البيئية الحرجة
في قسم
environmentللخدمة، أعلن على الأقل:N8N_HOST=n8n.your-domain.com،N8N_WEBHOOK_URL=https://n8n.your-domain.com/وN8N_PROXY_HOPS=1. لا يُضبط الوصول بمتغيّر: فقد أُزيلت المصادقة الأساسية من n8n 1.0، وإدارة المستخدمين المدمجة هي التي تحمي النسخة — عند أول تشغيل، تُنشئ حساب المالك. للإنتاج، خزّن هذه القيم في ملف.envمجاور واستدعه عبرenv_file: .env.تشغيل الحاوية
نفّذ:
docker compose up -d. تحقّق من تشغيل الحاوية:docker compose ps. راجع السجلات:docker compose logs -f n8n. يكون n8n جاهزًا حين تظهر السطرEditor is now accessible via: http://localhost:5678/في السجلات.إعداد الوكيل العكسي مع Caddy (موصى به)
Caddy هو أبسط وكيل عكسي لـ n8n: يتولّى شهادة Let's Encrypt والتجديد دون إعداد إضافي. ثبّت Caddy (
apt install caddy) ثم حرّر/etc/caddy/Caddyfileلإضافة:n8n.your-domain.com { reverse_proxy localhost:5678 }. أعد التحميل:systemctl reload caddy. مع nginx، أضف في كتلةlocation:proxy_set_header X-Forwarded-Host $host;وproxy_set_header X-Forwarded-Proto $scheme;وproxy_set_header X-Real-IP $remote_addr;.التحقق من الـ webhooks الواردة
في محرّر n8n، أنشئ سير عمل اختباريًا بعقدة Webhook. يجب أن يكون العنوان المعروض في وضع الإنتاج تمامًا
https://n8n.your-domain.com/webhook/<مسارك>. شغّل الاستدعاء من جهازك المحلي:curl -X POST https://n8n.your-domain.com/webhook/test -d '{}'. إذا احتوى العنوان علىlocalhostأو المنفذ5678، فإن المتغيّرN8N_WEBHOOK_URLلم يُؤخذ بعين الاعتبار.ربط PostgreSQL للإنتاج
يناسب SQLite الاختبار؛ في الإنتاج، يُفضَّل PostgreSQL. أضف خدمة
postgres:15إلى نفسdocker-compose.yamlمع حجم مخصصpg_data. في خدمة n8n، أضف:DB_TYPE=postgresdb،DB_POSTGRESDB_HOST=postgres،DB_POSTGRESDB_DATABASE=n8n،DB_POSTGRESDB_USER=n8n،DB_POSTGRESDB_PASSWORD=<كلمة-المرور>. أعد تشغيل الكل:docker compose up -d.
التصليب ووضع queue
ثلاثة ردود فعل إنتاجية: (1) لا تكشف المنفذ 5678 أبدًا على الواجهة العامة — احتفظ بالربط 127.0.0.1:5678. (2) أنشئ حساب المالك عند أول تشغيل: أُزيلت المصادقة الأساسية من n8n 1.0، وإدارة المستخدمين المدمجة هي التي تحمي النسخة، وأول زائر يصبح مالكها. (3) لمسارات العمل الذكاء الاصطناعي أو طويلة الأمد، انتقل إلى وضع queue مع نسخة worker مستقلة وطابور Redis.
