لماذا تستضيف n8n على VPS الخاص بك
تفرض النسخة السحابية من n8n رسومًا على كل عملية تنفيذ تتجاوز الخطة وتحدّ من عدد مسارات العمل النشطة. على VPS الخاص بك، التكلفة الوحيدة هي تكلفة الخادم، بصرف النظر عن عدد الأتمتات أو استدعاءات API. كما تحتفظ بالتحكم الكامل في بيانات الاعتماد وحمولات webhooks وتاريخ التنفيذ — لا تنتقل أي بيانات عبر بنية تحتية خارجية.
الفوائد الملموسة لـ n8n مُستضاف ذاتيًا
- عمليات تنفيذ غير محدودة: دون سقف شهري ودون تكلفة على الحجم.
- بيانات الاعتماد وحمولات webhooks محصورة في خادمك دون عبور خارجي.
- الوصول إلى العقد المجتمعية وتنفيذ الكود المخصص دون قيود.
- Webhooks على نطاقك الخاص، قابلة للإعداد لكل تكامل وارد.
- تكلفة قابلة للتنبؤ: سعر VPS ثابت مستقل عن حجم الأتمتات.
- استمرارية مُدارة لمسارات العمل والسجل في وحدات تخزين تأخذ منها نسخًا احتياطية.
- توافق مع Ollama وFlowise وأي خدمة Docker أخرى على نفس الشبكة الداخلية.
المتطلبات بالأرقام
قبل البدء، تأكّد من أن 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_BASIC_AUTH_ACTIVE=true،N8N_BASIC_AUTH_USER=<login>وN8N_BASIC_AUTH_PASSWORD=<كلمة-مرور-قوية>. للإنتاج، خزّن هذه القيم في ملف.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) فعّل المصادقة: في v1.x، N8N_BASIC_AUTH_ACTIVE=true؛ في v1.27+، يُفضَّل المصادقة الأصلية عبر الواجهة (الإعدادات → الأمان). (3) لمسارات العمل الذكاء الاصطناعي أو طويلة الأمد، انتقل إلى وضع queue مع نسخة worker مستقلة وطابور Redis.
تأمين التنفيذات المُخزَّنة (تنبيه 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 وفعّل تنظيف التنفيذات. انظر القسم المخصص.
الصيانة والتوسع
للتحديثات: Watchtower أو مهمة cron يدوية (docker pull n8nio/n8n:latest && docker compose up -d). احتفظ بتصديرات مسارات العمل في مستودع git.
لتنبيهات الأمان، تابع صفحة GitHub Security Advisories لمستودع n8n.
