العودة إلى المدونة

استضافة n8n على سيرفر VPS في 2026: دليل الإعداد لبيئة الإنتاج

فريق تحرير IM Host3 أكتوبر 20265 دقائق قراءة
استضافة n8n على سيرفر VPS في 2026: دليل الإعداد لبيئة الإنتاج

أصبحت n8n الخيار الأول للفرق التي تريد أتمتة شبيهة بـ Zapier من دون تسعير لكل مهمة، ومن دون تمرير بيانات العملاء عبر سحابة طرف ثالث. تشغيلها بنفسك أمر سهل، لكن تشغيلها بحيث تصمد أمام إعادة التشغيل والتحديثات وضغط العمل يحتاج إلى قليل من التخطيط. يشرح هذا الدليل إعدادًا جاهزًا للإنتاج لـ n8n على سيرفر VPS: حجم السيرفر المناسب، والتثبيت باستخدام Docker Compose وPostgreSQL، وتشغيلها خلف HTTPS، وما الذي يجب نسخه احتياطيًا حتى لا تفقد أي workflow.

لماذا تستضيف n8n بنفسك بدلًا من الخطة السحابية؟

  • تكلفة متوقعة: تدفع ثمن السيرفر، لا ثمن كل تنفيذ. الـ workflows الثقيلة التي تستعلم من الـ APIs كل دقيقة لم تعد مشكلة في الفاتورة.

  • تحكم في البيانات: بيانات الاعتماد (Credentials) وحمولات الـ Webhooks وسجلات التنفيذ تبقى على بنية تختارها أنت، وفي الدولة التي تختارها.

  • بدون قيود مصطنعة: العُقد المخصصة وعُقد المجتمع والتنفيذات الطويلة والوصول المباشر إلى قواعد بياناتك الداخلية، كلها متاحة.

في المقابل، تصبح أنت المسؤول عن التحديثات والنسخ الاحتياطي واستمرارية التشغيل. وبقية الدليل هدفها أن تجعل هذا الجزء روتينيًا ومملًّا.

ما حجم السيرفر الذي تحتاجه n8n فعلًا؟

n8n تطبيق Node.js خفيف في حالة الخمول. ما يحدد استهلاك الموارد هو عدد التنفيذات التي تعمل في الوقت نفسه وحجم البيانات التي يحملها كل تنفيذ في الذاكرة. كقاعدة تقريبية:

  • استخدام شخصي أو فريق صغير (أقل من بضعة آلاف تنفيذ يوميًا): معالجان (2 vCPU) و4 جيجابايت رام تكفي براحة.

  • أحمال أعمال فيها JSON كبير أو معالجة ملفات أو عُقد ذكاء اصطناعي: ابدأ من 4 vCPU و8 جيجابايت رام.

  • وضع الطوابير (Queue mode) مع Workers منفصلة: اجعل حجم كل Worker مناسبًا لأثقل workflow لديك، وأضف Workers بدلًا من تكبير سيرفر واحد.

سرعة التخزين NVMe مهمة أكثر مما يتوقع كثيرون، لأن كل تنفيذ يُكتب في قاعدة البيانات. سيرفر Linux VPS بتخزين NVMe وصلاحيات root كاملة مناسب لمعظم الفرق، وإذا أردت موارد لا يشاركك فيها أحد إطلاقًا فإن Cloud VPS بمعالج وذاكرة مخصصين يلغي مشكلة "الجيران المزعجين" من الأساس.

الخطوة 1: تجهيز السيرفر

ابدأ بنسخة نظيفة من Ubuntu 24.04 أو Debian 12. أنشئ مستخدمًا غير root، وفعّل الدخول بمفاتيح SSH، وثبّت Docker Engine مع إضافة Compose من المستودع الرسمي لـ Docker. وجّه نطاقًا فرعيًا مثل automation.yourcompany.com إلى عنوان IP الخاص بالسيرفر قبل المتابعة، لأن شهادة HTTPS تعتمد عليه.

الخطوة 2: استخدم PostgreSQL بدلًا من SQLite الافتراضية

تأتي n8n مع SQLite لتجربتها في دقائق. أما في الإنتاج فانتقل إلى PostgreSQL: فهي تتعامل مع التنفيذات المتزامنة بشكل أفضل، ونسخها احتياطيًا أسهل وأكثر اتساقًا، وهي مطلوبة إذا انتقلت لاحقًا إلى وضع الطوابير. هذا ملف docker-compose.yml مبسّط:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - pg_data:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    depends_on: [postgres]
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_HOST: automation.yourcompany.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://automation.yourcompany.com/
      N8N_ENCRYPTION_KEY: generate-a-long-random-string
      GENERIC_TIMEZONE: Africa/Cairo
      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: "336"
    ports:
      - "127.0.0.1:5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  pg_data:
  n8n_data:

هناك إعدادان يستحقان الانتباه. N8N_ENCRYPTION_KEY يشفّر كل بيانات الاعتماد المخزنة، وإذا فقدته فلن يمكن فك تشفيرها، لذا احتفظ بنسخة منه في مدير كلمات المرور. أما EXECUTIONS_DATA_PRUNE مع أقصى عمر للبيانات (بالساعات) فيمنع سجل التنفيذات من ملء القرص تدريجيًا.

الخطوة 3: شغّل n8n خلف HTTPS

لاحظ أن المنفذ 5678 مربوط بـ 127.0.0.1 فقط، لأن n8n لا يجب أن تكون مكشوفة مباشرة على الإنترنت. ضع أمامها Reverse Proxy، وأسهل خيار هو Caddy لأنه يطلب شهادات Let's Encrypt ويجددها تلقائيًا:

automation.yourcompany.com {
    reverse_proxy 127.0.0.1:5678
}

Nginx أو Traefik يعملان بالكفاءة نفسها إذا كنت تستخدم أحدهما بالفعل. المهم أن تتأكد من تمرير اتصالات WebSocket، وإلا ستبدو واجهة التحرير معطلة.

الخطوة 4: انسخ احتياطيًا الأشياء الثلاثة المهمة

  1. قاعدة بيانات PostgreSQL: وفيها الـ workflows وبيانات الاعتماد وسجل التنفيذات. جدول pg_dump ليليًا وانقله خارج السيرفر.

  2. مفتاح التشفير: احفظه في مكان آخر غير السيرفر نفسه.

  3. تصدير الـ workflows: ويُفضّل حفظها في مستودع Git خاص، لتعرف ما الذي تغيّر وتتمكن من استرجاع workflow واحد دون استرجاع قاعدة البيانات كاملة.

جرّب الاسترجاع مرة واحدة على الأقل. النسخة الاحتياطية التي لم تُجرَّب استعادتها مجرد أمل، وليست خطة.

الخطوة 5: التوسع بوضع الطوابير عند الحاجة

عندما لا يعود سيرفر واحد كافيًا، يقسّم وضع الطوابير في n8n العمل: النسخة الرئيسية تستقبل المُشغّلات والـ Webhooks، وRedis يحفظ الطابور، وحاوية Worker واحدة أو أكثر تنفّذ المهام. يتم تفعيله عبر EXECUTIONS_MODE=queue مع توجيه كل النسخ إلى Redis وPostgreSQL نفسيهما. يمكن أن تعمل الـ Workers على نفس السيرفر في البداية، ثم تنتقل إلى سيرفرات منفصلة لاحقًا دون تغيير أي workflow.

قائمة تحقق ما بعد التشغيل

  • ثبّت إصدار صورة n8n وحدّث بشكل مقصود بعد قراءة ملاحظات الإصدار.

  • فعّل التحقق بخطوتين لكل مستخدمي n8n.

  • راقب مساحة القرص وإعادة تشغيل الحاويات، لا مجرد استجابة السيرفر للـ ping.

  • لا تضع روابط الـ Webhooks في مستودعات عامة، وتعامل معها ككلمات مرور.

أين تشغّلها؟

اختر مركز بيانات قريبًا من الخدمات التي تتعامل معها الـ workflows أكثر من غيرها. توفر IM HOST خوادم Linux VPS وCloud VPS في الولايات المتحدة والمملكة المتحدة وبولندا وألمانيا ومصر، بصلاحيات root كاملة وتخزين NVMe ودعم فني من مهندسين على مدار الساعة، لتضع n8n بجوار بياناتك. قارن الخطط في صفحتي Linux VPS وCloud VPS، أو اطّلع على مواقع مراكز البيانات.

المزيد من مدونتنا

اكتشف المزيد من الأدلة العملية ورؤى الخدمات من فريق IM Host.

عرض كل المقالات