تثبيت n8n على VPS بالـDocker خطوة بخطوة

n8n من أقوى أدوات أتمتة سير العمل مفتوحة المصدر، لكن قوّتها الحقيقية تظهر فقط حين تستضيفها بنفسك على خادم يعمل دون انقطاع. النسخة السحابية (n8n Cloud) مريحة للتجربة، لكنها تحاسبك على التنفيذات وتُبقي بياناتك على خوادم الشركة. أمّا الاستضافة الذاتية على VPS فتمنحك تحكّمًا كاملًا، وخصوصية مطلقة لاعتماداتك (credentials)، وتكلفة ثابتة لا تتضخّم مهما نما عدد التشغيلات. المشكلة الوحيدة أن خطوات الإعداد تربك المبتدئين: حاويات متعدّدة، شهادة SSL، ويبهوكات تحتاج عنوانًا عامًا صحيحًا، ومفتاح تشفير لا يجب أن تفقده أبدًا. هذا الدليل مكتوب ليزيل هذا الارتباك كاملًا. إن كنت جديدًا تمامًا على n8n وتريد فهم المفاهيم أولًا، فابدأ بدليل الأتمتة بـn8n من الصفر، ثم عُد إلى هنا للتنفيذ العملي على خادمك.

لماذا تستضيف n8n ذاتيًا على VPS بدل n8n Cloud؟

السؤال الأول الذي يجب أن تحسمه قبل أي أمر: هل تستضيف n8n بنفسك أم تشترك في n8n Cloud؟ القرار يعتمد على ثلاثة عوامل — التحكّم، والخصوصية، والتكلفة على المدى الطويل.

التحكّم: عند الاستضافة الذاتية أنت تملك كل شيء — الإصدار الذي تشغّله، حجم الموارد، التكاملات المخصّصة، وحتى الحزم npm الإضافية التي تركّبها داخل الحاوية. لا أحد يفرض عليك ترقية مفاجئة ولا يحجب عنك ميزة خلف باقة أغلى.

الخصوصية: هذا هو السبب الأهمّ لكثيرين. في الاستضافة الذاتية، كل بياناتك واعتماداتك (مفاتيح API، توكنات OAuth، كلمات المرور) تبقى مشفّرة على قاعدة بياناتك أنت، ولا تمرّ عبر طرف ثالث. للشركات الملتزمة بسياسات حماية البيانات أو العاملة في قطاعات حسّاسة، هذا فارق حاسم.

التكلفة: n8n Cloud تحاسبك حسب عدد التنفيذات أو الـworkflows النشطة، وتتضخّم الفاتورة مع نمو الأتمتة. أمّا الاستضافة الذاتية فتكلفتها ثابتة: سعر VPS صغير شهريًا، وتشغيلات غير محدودة عمليًا (حسب موارد خادمك فقط).

الخلاصة العملية: إن كنت تريد أقصى تحكّم وخصوصية وتكلفة منخفضة على المدى الطويل، ولا تمانع نصف ساعة من الإعداد الأولي، فالاستضافة الذاتية هي الخيار. وإن كنت تجرّب فقط أو لا تريد أي صيانة، فابدأ بـCloud ثم انتقل لاحقًا. بقيّة هذا الدليل تفترض أنك اخترت الاستضافة الذاتية.

سحابة الأتمتة n8n من wpressly

شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.

ابدأ مع سحابة الأتمتة

ما المتطلّبات قبل أن تبدأ؟

قبل أن تكتب أول أمر، تأكّد أن العناصر التالية جاهزة. غياب أحدها سيوقفك في منتصف الطريق:

مواصفات الخادم: n8n خفيفة نسبيًا، لكن استهلاكها يقفز مع عدد الـworkflows المتزامنة وحجم البيانات التي تعالجها. الجدول التالي يقترح أحجامًا حسب الحِمل المتوقّع:

قاعدة عملية: ابدأ بنواتين و2 جيجابايت ذاكرة كحدّ أدنى مريح إن كنت ستشغّل n8n مع PostgreSQL في الإنتاج. أقلّ من ذلك ممكن للتجربة، لكن المعالجة الثقيلة (تحويل JSON كبير، توليد صور، استدعاءات AI) قد تستنزف الذاكرة بسرعة.

ضبط DNS: قبل أي شيء، أنشئ سجل A في لوحة الدومين يربط النطاق الفرعي بعنوان IP الخادم. مثال: n8n ← 203.0.113.42. انتظر حتى ينتشر السجل (دقائق إلى ساعة)، وتحقّق بأمر dig n8n.example.com +short أنه يعيد IP الصحيح. هذه الخطوة شرط لإصدار شهادة SSL تلقائيًا لاحقًا — فلا تتجاوزها. إن أردت فهمًا أعمق لأنواع سجلات DNS وكيفية ضبطها، فدليل شرح سجلات DNS يغطّيها بالتفصيل.

تجهيز الخادم نفسه (تحديث النظام، إنشاء مستخدم non-root، مفاتيح SSH، جدار الحماية الأساسي) شرط مسبق لهذا الدليل ولن نكرّره هنا بالكامل. إن لم تكن قد جهّزت خادمك بعد، فاتبع أولًا دليل إعداد أول سيرفر VPS من الصفر خطوة بخطوة، ثم عُد إلى هنا بخادم نظيف ومؤمَّن.

كيف تثبّت Docker وDocker Compose؟

سنشغّل n8n عبر Docker لأنه يعزل التطبيق وتبعيّاته في حاويات، فتثبّت وتحدّث وتنقل النظام دون أن تلوّث الخادم بحزم متضاربة. خطوة الإعداد كلها تتلخّص في ملف واحد، والترقية أمر واحد. سنثبّت أحدث إصدار من Docker Engine من المستودع الرسمي (وليس النسخة القديمة في مستودعات التوزيعة).

نفّذ الأوامر التالية على خادم Ubuntu كمستخدم بصلاحيات sudo:

# 1) إزالة أي نسخ قديمة محتملة
for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt-get remove -y $pkg
done

# 2) تثبيت المتطلّبات وإضافة مفتاح GPG الرسمي لـDocker
sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# 3) إضافة مستودع Docker الرسمي
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 4) تثبيت Docker Engine + إضافة Compose (الإصدار v2 المدمج)
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

بعد التثبيت، أضِف مستخدمك إلى مجموعة docker حتى تشغّل الأوامر دون sudo في كل مرّة، ثم تحقّق من نجاح التثبيت:

# تشغيل docker دون sudo (يتطلّب إعادة تسجيل دخول أو newgrp)
sudo usermod -aG docker $USER
newgrp docker

# التحقّق من الإصدارات
docker --version
docker compose version

# اختبار سريع
docker run --rm hello-world

انتبه: في Docker الحديث، Compose صار إضافة (plugin) مدمجة تُستدعى بـdocker compose (بمسافة) لا docker-compose (بشرطة). كل أوامر هذا الدليل تستخدم الصيغة الحديثة docker compose.

ما بنية الحاويات التي سنبنيها؟

قبل كتابة الملف، افهم المعمارية. لن نشغّل n8n بمفردها، بل ثلاث حاويات متعاونة في شبكة Docker داخلية واحدة، كلٌّ بدور محدّد:

1. حاوية n8n: التطبيق نفسه — الواجهة، المحرّك، ومنفذها الداخلي 5678. لا نكشف هذا المنفذ مباشرة للإنترنت، بل نضعه خلف بروكسي.
2. حاوية PostgreSQL: قاعدة البيانات التي تخزّن الـworkflows والاعتمادات وسجلّ التنفيذات. n8n تستخدم افتراضيًا قاعدة SQLite (ملف واحد)، لكنها لا تصمد للإنتاج: تتعطّل تحت الكتابة المتزامنة وتنمو بلا حدود. PostgreSQL هو الخيار الإنتاجي الصحيح.
3. حاوية البروكسي العكسي: نقطة الدخول الوحيدة من الإنترنت (المنفذان 80 و443). تنهي شهادة SSL (HTTPS)، وتوجّه الطلبات داخليًا إلى n8n على 5678. سنستخدم Caddy لأنه يصدر ويجدّد شهادة Let's Encrypt تلقائيًا ببضعة أسطر — وهو أبسط خيار للمبتدئين.

كل حاوية تحفظ بياناتها في volume دائم، فلا تضيع البيانات عند إعادة بناء الحاوية أو ترقيتها. هذه نقطة جوهرية: الحاويات عابرة، لكن الـvolumes باقية.

هذا الفصل بين الطبقات هو ما يجعل النظام إنتاجيًا: قاعدة البيانات معزولة، البروكسي يحمي n8n من الكشف المباشر، والـSSL يُدار تلقائيًا. والآن نترجم هذه البنية إلى ملف docker-compose.yml واحد.

ملف docker-compose.yml الكامل المشروح

أنشئ مجلدًا للمشروع وادخله، ثم سننشئ بداخله ملفين: docker-compose.yml و.env.

mkdir -p ~/n8n && cd ~/n8n

أولًا، ملف .env لكل القيم الحسّاسة والمتغيّرة. لا تكتب هذه القيم مباشرة في compose — اعزلها هنا، ولا ترفع هذا الملف إلى Git أبدًا:

# ===== الدومين والبروتوكول =====
DOMAIN_NAME=n8n.example.com
GENERIC_TIMEZONE=Asia/Riyadh
SSL_EMAIL=admin@example.com

# ===== متغيّرات n8n الأساسية =====
N8N_HOST=n8n.example.com
N8N_PROTOCOL=https
N8N_PORT=5678
WEBHOOK_URL=https://n8n.example.com/
# مفتاح التشفير — ولّده مرّة واحدة واحفظه للأبد (لا تغيّره لاحقًا)
N8N_ENCRYPTION_KEY=ضع_هنا_مفتاحًا_عشوائيًا_طويلًا

# ===== قاعدة بيانات PostgreSQL =====
DB_TYPE=postgresdb
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=كلمة_مرور_قوية_للقاعدة

# بيانات تهيئة حاوية postgres (تُستخدم أول تشغيل فقط)
POSTGRES_USER=n8n
POSTGRES_PASSWORD=كلمة_مرور_قوية_للقاعدة
POSTGRES_DB=n8n

لتوليد N8N_ENCRYPTION_KEY ومفتاح قاعدة بيانات قويين، استخدم:

openssl rand -hex 32

نفّذه مرّتين، وضع الناتج في الحقلين المناسبين. الآن ملف docker-compose.yml نفسه:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=${POSTGRES_DB}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - n8n_net

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    environment:
      - N8N_HOST=${N8N_HOST}
      - N8N_PROTOCOL=${N8N_PROTOCOL}
      - N8N_PORT=${N8N_PORT}
      - WEBHOOK_URL=${WEBHOOK_URL}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - DB_TYPE=${DB_TYPE}
      - DB_POSTGRESDB_DATABASE=${DB_POSTGRESDB_DATABASE}
      - DB_POSTGRESDB_HOST=${DB_POSTGRESDB_HOST}
      - DB_POSTGRESDB_PORT=${DB_POSTGRESDB_PORT}
      - DB_POSTGRESDB_USER=${DB_POSTGRESDB_USER}
      - DB_POSTGRESDB_PASSWORD=${DB_POSTGRESDB_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - n8n_net

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - n8n
    networks:
      - n8n_net

volumes:
  postgres_data:
  n8n_data:
  caddy_data:
  caddy_config:

networks:
  n8n_net:

شرح أبرز المقاطع:

• restart: unless-stopped يعيد تشغيل الحاوية تلقائيًا بعد إعادة إقلاع الخادم أو أي تعطّل — أساسي للإنتاج.
• depends_on مع condition: service_healthy يضمن ألا تبدأ n8n قبل أن تكون PostgreSQL جاهزة فعلًا (لا مجرّد "بدأت")، فيمنع أخطاء الاتصال عند الإقلاع.
• الـvolumes (n8n_data، postgres_data، caddy_data) هي حيث تُحفظ البيانات بشكل دائم. حذف الحاوية لا يحذفها.
• n8n لا تكشف منفذها (5678) للمضيف — لا يوجد ports تحتها. الوصول إليها يتمّ داخليًا عبر شبكة n8n_net من Caddy فقط.

أخيرًا، أنشئ ملف Caddyfile في المجلد نفسه — هذا كل ما يلزم Caddy لإصدار SSL والتوجيه:

n8n.example.com {
    reverse_proxy n8n:5678
}

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

متغيّرات البيئة وWEBHOOK_URL وN8N_ENCRYPTION_KEY

أكثر نقطتين تتسبّبان في مشاكل لدى المبتدئين هما WEBHOOK_URL وN8N_ENCRYPTION_KEY. خذهما بجدّية.

WEBHOOK_URL هو العنوان العام الذي تخبر به n8n لتبني روابط الويبهوك الخارجية. حين تنشئ workflow يبدأ بـTrigger من نوع Webhook (مثلًا استقبال إشعار من خدمة خارجية)، تولّد n8n رابطًا يجب أن تصله الخدمة الخارجية. إن لم تضبط WEBHOOK_URL على دومينك العام بالبروتوكول الصحيح، ستولّد n8n روابط بـlocalhost أو IP داخلي لا تصله الخدمات الخارجية — فلا يعمل أي webhook. اضبطه دائمًا على https://دومينك/ بشرطة مائلة في النهاية.

N8N_ENCRYPTION_KEY هو المفتاح الذي تشفّر به n8n كل الاعتمادات (credentials) المخزّنة في قاعدة البيانات. خطورته أنه إن تغيّر أو ضاع، لن تستطيع n8n فكّ تشفير اعتماداتك القديمة — ستضطر لإعادة إدخالها كلّها يدويًا. لذلك: ولّده مرّة واحدة، احفظه في مكان آمن (مدير كلمات مرور)، ولا تغيّره أبدًا بعد أول تشغيل. إن لم تحدّده، تولّده n8n تلقائيًا وتحفظه داخل volume الإعداد — لكن تحديده يدويًا أأمن للنسخ الاحتياطي والترحيل.

الجدول التالي يلخّص أهمّ متغيّرات البيئة:

ملاحظة عن GENERIC_TIMEZONE: إن كانت لديك workflows مجدولة بعقدة Schedule/Cron، فالمنطقة الزمنية تحدّد متى تعمل فعلًا. اضبطها على منطقتك (مثلًا Asia/Riyadh) وإلا ستُجدوَل الأمور بتوقيت UTC.

ولأن n8n هي الواجهة التي تستقبل وتعالج بياناتك الحسّاسة، فإن صحّة هذه المتغيّرات شرط لتشغيل آمن وموثوق — وهنا تظهر قيمة استضافتها على VPS تتحكّم فيه بالكامل.

سحابة الأتمتة n8n من wpressly

شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.

ابدأ مع سحابة الأتمتة

ربط الدومين وإصدار SSL: أول تشغيل وتسجيل المالك

بعد أن جهّزت الملفات الثلاثة (docker-compose.yml، .env، Caddyfile) وتأكّدت أن سجل DNS من نوع A يشير إلى IP الخادم، شغّل الستاك:

cd ~/n8n
docker compose up -d

سيسحب Docker الصور (n8n، postgres، caddy) ويشغّل الحاويات في الخلفية. أول تشغيل قد يأخذ دقيقة أو دقيقتين. تابع السجلّات للتأكّد من عدم وجود أخطاء:

docker compose logs -f

ابحث عن سطر يفيد أن n8n تعمل وتستمع على 5678، وأن Caddy نجح في إصدار شهادة الدومين. لإنهاء المتابعة اضغط Ctrl+C (هذا يوقف المتابعة فقط، لا الحاويات).

الآن افتح المتصفّح على https://n8n.example.com. إن نجح إصدار SSL، سترى واجهة n8n مع قفل آمن. أول ما يطلبه منك هو إنشاء حساب المالك (owner): بريد، اسم، وكلمة مرور. هذا الحساب الأول هو المدير الأعلى للنسخة — احفظ بياناته جيدًا. بعد التسجيل تدخل إلى لوحة n8n وتبدأ بناء الـworkflows.

لاحظ القاعدة الذهبية: المنفذان المكشوفان فقط 80 و443. كل ما عداهما داخلي ضمن شبكة Docker. هذا أساس التأمين الذي سنعمّقه لاحقًا.

إن أردت بناء أتمتة حقيقية بعد التسجيل، فدليل أمثلة workflows عملية يقدّم سيناريوهات جاهزة تطبّقها مباشرةً على نسختك الجديدة.

كيف تبني أول workflow بعد التثبيت؟

بعد تسجيل المالك، تظهر لك لوحة فارغة. الـworkflow في n8n سلسلة عُقد (nodes) تبدأ بـTrigger (محفّز) ثم تتسلسل عبر خطوات معالجة وإجراءات. لنفهم التدفّق:

1. Trigger: نقطة البداية — قد تكون جدولًا زمنيًا (Schedule)، أو ويبهوك (Webhook) يستقبل طلبًا خارجيًا، أو حدثًا من تطبيق (وصول بريد مثلًا).
2. عُقد المعالجة: تحوّل البيانات، تفلتر، تتّخذ قرارات شرطية (IF)، أو تستدعي APIs.
3. عُقد الإجراء: تكتب النتيجة في وجهة — إرسال رسالة، تحديث صفّ في قاعدة بيانات، أو نداء HTTP.

نصيحة عملية للتجربة الأولى: أنشئ workflow بسيطًا من عقدة Schedule Trigger (كل ساعة) ← عقدة HTTP Request (تجلب بيانات من API عام) ← عقدة تكتب الناتج في رسالة. شغّله يدويًا بزرّ Execute لترى البيانات تتدفّق بين العُقد، ثم فعّله (Active) ليعمل تلقائيًا حسب الجدول. هكذا تتأكّد أن نسختك تعمل من الطرف إلى الطرف.

كيف ترقّي n8n بأمان؟

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

cd ~/n8n

# 1) نسخة احتياطية لقاعدة البيانات قبل أي ترقية (مهم)
docker compose exec postgres pg_dump -U n8n n8n > backup-$(date +%F).sql

# 2) سحب أحدث الصور
docker compose pull

# 3) إعادة إنشاء الحاويات بالصور الجديدة (يحفظ الـvolumes)
docker compose up -d

# 4) التأكّد من أن كل شيء يعمل
docker compose ps
docker compose logs -f n8n

لأن البيانات في volumes منفصلة عن الحاويات، إعادة الإنشاء (up -d) تستبدل صور الحاويات وتبقي البيانات سليمة. مع ذلك، خذ النسخة الاحتياطية دائمًا قبل الترقية — أحيانًا تجري ترقية كبرى تغييرات في مخطّط قاعدة البيانات (migrations)، والتراجع يحتاج النسخة.

تثبيت إصدار محدّد بدل latest: في الإنتاج، يفضّل كثيرون تثبيت رقم إصدار صريح بدل :latest (مثلًا docker.n8n.io/n8nio/n8n:1.70.0) لتتحكّم تمامًا في توقيت الترقية وتتجنّب مفاجآت سحب نسخة غير مختبَرة. عدّل وسم الصورة في compose، ثم نفّذ docker compose up -d.

كيف تأخذ نسخة احتياطية موثوقة؟

النسخ الاحتياطي عنصران: قاعدة البيانات (الـworkflows والاعتمادات والتنفيذات) وvolume إعداد n8n (مفتاح التشفير وملفّات الإعداد). انسخهما معًا.

1) نسخة قاعدة البيانات بـpg_dump:

cd ~/n8n
docker compose exec -T postgres pg_dump -U n8n -d n8n > n8n-db-$(date +%F).sql

2) نسخة volume إعداد n8n (يحتوي على بيانات الإعداد ومفتاح التشفير إن وُلِّد تلقائيًا):

docker run --rm \
  -v n8n_n8n_data:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/n8n-data-$(date +%F).tar.gz -C /data .

اسم الـvolume قد يكون مسبوقًا باسم المجلد (مثل n8n_n8n_data). تحقّق بأمر docker volume ls.

استعادة قاعدة البيانات من نسخة:

cat n8n-db-2026-06-13.sql | docker compose exec -T postgres psql -U n8n -d n8n

أتمتة النسخ: أضِف الأمرين إلى مهمّة cron يومية على الخادم، وانقل النسخ إلى تخزين خارجي (object storage مثل R2 أو S3) حتى لا تفقدها إن تعطّل الخادم نفسه. للتعمّق في استراتيجيات النسخ الكاملة، راجع دليل النسخ الاحتياطي للمواقع.

كيف تؤمّن n8n على الخادم؟

n8n تخزّن مفاتيح API وتوكنات حسّاسة، فتأمينها ليس رفاهية. اتبع هذه الطبقات:

1) جدار الحماية — لا تكشف إلا 80 و443: هذه أهمّ قاعدة. أغلق كل المنافذ عدا SSH (22) وHTTP/HTTPS. لا تكشف 5678 (n8n) ولا 5432 (PostgreSQL) للإنترنت أبدًا — البروكسي وحده بوّابتك.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

2) HTTPS إلزامي: بفضل Caddy، كل الحركة مشفّرة تلقائيًا. تأكّد أن N8N_PROTOCOL=https وWEBHOOK_URL يبدأ بـhttps://.

3) المصادقة: حساب المالك (owner) محميّ بكلمة مرور. استخدم كلمة مرور قوية وفريدة، وفعّل المصادقة الثنائية (2FA) من إعدادات n8n إن كانت متاحة في نسختك. إن أردت طبقة إضافية، يمكن وضع n8n خلف Basic Auth على مستوى البروكسي.

4) عدم كشف المنافذ الداخلية: كما في ملف compose، لم نضع ports تحت n8n أو postgres — هذا متعمّد. الوصول داخلي عبر شبكة Docker فقط.

5) تحديثات منتظمة: حدّث n8n (الترقية أعلاه) ونظام الخادم دوريًا لسدّ الثغرات.

6) مفتاح التشفير في أمان: احفظ N8N_ENCRYPTION_KEY خارج الخادم (مدير كلمات مرور)، فهو مفتاح فكّ كل اعتماداتك.

للتعمّق في تأمين الخادم نفسه (Fail2ban، تعطيل دخول root، مفاتيح SSH، التحديثات التلقائية)، يغطّي دليل إعداد أول سيرفر VPS من الصفر هذه الطبقات بالأوامر.

خيارات البروكسي العكسي: Caddy مقابل Nginx مقابل Traefik

استخدمنا Caddy لبساطته، لكن لك بدائل حسب احتياجك وخبرتك. جميعها تؤدّي الدور نفسه (إنهاء SSL + التوجيه إلى 5678)، لكنها تختلف في التعقيد والمرونة:

Nginx + Certbot خيار قوي إن كنت تشغّل خدمات أخرى على Nginx بالفعل. تكتب block خادم يوجّه proxy_pass إلى http://127.0.0.1:5678، ثم تصدر الشهادة بأمر sudo certbot --nginx -d n8n.example.com، وتجدّدها تلقائيًا عبر مؤقّت Certbot. الفارق أنك تتولّى تجديد الشهادة وضبط رؤوس الويبهوك يدويًا.

Traefik يلمع حين تدير عدّة خدمات بحاويات: يكتشف الحاويات تلقائيًا عبر تسميات (labels) في compose ويصدر شهاداتها دون ملف إعداد منفصل لكل واحدة. لكنه أعقد قليلًا للمبتدئ صاحب الخدمة الواحدة، ولهذا بدأنا بـCaddy.

النصيحة: ابدأ بـCaddy ما لم يكن لديك سبب محدّد لغيره. تستطيع تبديل البروكسي لاحقًا دون المساس بـn8n أو قاعدة البيانات.

وضع الطابور (Queue Mode) للتوسّع

في الإعداد الافتراضي (regular mode)، تنفّذ حاوية n8n واحدة كل الـworkflows. هذا يكفي لأغلب الحالات. لكن مع حِمل ثقيل (مئات التنفيذات المتزامنة، معالجة طويلة)، قد تصبح الحاوية الواحدة عنق زجاجة.

هنا يأتي queue mode: تفصل بين عملية رئيسية (main) تستقبل الطلبات والواجهة، وعدّة عمليات عاملة (workers) تنفّذ المهام بالتوازي، يربطها طابور رسائل عبر Redis. تضيف حاوية Redis وتشغّل عاملًا أو أكثر بالأمر نفسه مع --worker، وتضبط EXECUTIONS_MODE=queue. النتيجة: توسّع أفقي — تزيد عدد الـworkers مع نموّ الحِمل.

هذه إشارة فقط لأنها متقدّمة ولا يحتاجها المبتدئ. ابدأ بالوضع العادي، وحين تلاحظ أن التنفيذات تتأخّر أو تتراكم، فكّر حينها في queue mode وRedis. البنية التي بنيناها (Docker Compose + PostgreSQL) تتوسّع إلى queue mode بسلاسة دون إعادة بناء من الصفر.

حلّ المشاكل الشائعة (Troubleshooting)

أكثر الأعطال شيوعًا وحلولها المباشرة:

أوامر تشخيص سريعة عند أي عطل:

# حالة الحاويات
docker compose ps

# سجلّات خدمة بعينها
docker compose logs --tail=100 n8n
docker compose logs --tail=100 caddy

# اختبار وصول n8n داخليًا من داخل شبكة Docker
docker compose exec caddy wget -qO- http://n8n:5678/healthz

# التحقّق من اتصال القاعدة
docker compose exec postgres pg_isready -U n8n

تحذير حرج: لا تستخدم docker compose down -v إلا إن كنت تقصد فعلًا حذف كل البيانات — العَلَم -v يحذف الـvolumes (قاعدة البيانات والإعداد). للإيقاف العادي استخدم docker compose down أو docker compose stop فقط.

نصائح خبير قبل أن تنطلق

• ثبّت رقم إصدار صريح في الإنتاج بدل :latest، ورقِّ عمدًا بعد قراءة ملاحظات الإصدار.
• افصل الـ.env عن Git تمامًا وأضِفه إلى .gitignore؛ فيه أسرارك كلها.
• اختبر استعادة النسخة الاحتياطية فعليًا مرّة على خادم تجريبي — نسخة لا تُختبَر ليست نسخة.
• راقب استهلاك الذاكرة بأمر docker stats؛ workflows الثقيلة (AI، معالجة ملفات) تستهلك أكثر مما تتوقّع.
• ضع حدًّا لسجلّ التنفيذات (pruning) حتى لا تتضخّم قاعدة البيانات بلا نهاية مع الوقت.
• استخدم نطاقًا فرعيًا مخصّصًا لـn8n (مثل n8n. أو automation.) لفصلها عن موقعك الرئيسي وتسهيل إدارة SSL.

بهذا تكون انتقلت من خادم فارغ إلى نسخة n8n إنتاجية: حاويات معزولة، قاعدة بيانات ثابتة، SSL تلقائي، ويبهوكات تعمل، نسخ احتياطية، وتأمين محكم. كل ما تبقّى هو بناء الأتمتة التي ستوفّر عليك ساعات كل أسبوع. وإن أردت إطلاق نسختك على خادم سريع ومستقرّ يعمل دون انقطاع، فاختر خطة VPS مناسبة وابدأ اليوم.

سحابة الأتمتة n8n من wpressly

شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.

ابدأ مع سحابة الأتمتة

الأسئلة الشائعة

هل أحتاج خبرة في Linux لتثبيت n8n على VPS؟ خبرة أساسية كافية: الاتصال عبر SSH، نسخ أوامر ولصقها، وتحرير ملف نصّي. هذا الدليل يعطيك كل الأوامر جاهزة. إن كنت جديدًا تمامًا، اقرأ أولًا دليل إعداد أول VPS لتألف التعامل مع الخادم.

لماذا PostgreSQL بدل SQLite الافتراضية؟ SQLite ملف واحد يكفي للتجربة، لكنه يتعثّر تحت الكتابة المتزامنة وينمو بلا حدود ويصعب نسخه احتياطيًا في الإنتاج. PostgreSQL أكثر متانة وموثوقية ومرونة في النسخ والترحيل، وهو المعيار الإنتاجي لـn8n.

ما أقلّ مواصفات VPS تكفي n8n؟ للتجربة تكفي نواة واحدة و1 جيجابايت ذاكرة. للاستخدام الجاد مع PostgreSQL، نواتان و2 جيجابايت ذاكرة هو الحدّ الأدنى المريح. الحِمل الثقيل (عشرات الـworkflows أو معالجة AI) يحتاج 4 جيجابايت فأكثر.

ماذا لو فقدت N8N_ENCRYPTION_KEY؟ لن تستطيع n8n فكّ تشفير اعتماداتك المخزّنة، وستضطر لإعادة إدخالها كلّها يدويًا. لذلك ولّد المفتاح مرّة واحدة، احفظه في مدير كلمات مرور، ولا تغيّره أبدًا. اجعله جزءًا من نسختك الاحتياطية.

لماذا لا يعمل الـwebhook عندي؟ السبب الأشيع أن WEBHOOK_URL غير مضبوط على دومينك العام بـHTTPS. اضبطه على https://دومينك/ وأعد تشغيل الحاوية. تأكّد أيضًا أن الدومين يُحلّ صحيحًا وأن البروكسي يصدر شهادة سارية.

كيف أصدر شهادة SSL تلقائيًا؟ Caddy يصدرها ويجدّدها تلقائيًا ببضعة أسطر في Caddyfile — وهو الأبسط. شرط النجاح أن يشير سجل DNS من نوع A إلى IP الخادم وأن يكون المنفذ 80 مفتوحًا ليتمّ تحدّي Let's Encrypt. البديل هو Nginx مع Certbot.

كيف أرقّي n8n دون فقد بياناتي؟ خذ نسخة pg_dump أولًا، ثم docker compose pull لسحب الصورة الجديدة، ثم docker compose up -d لإعادة الإنشاء. البيانات في volumes منفصلة فتبقى سليمة. تجنّب down -v لأنه يحذف الـvolumes.

هل يمكن تشغيل عدّة مواقع/خدمات مع n8n على الخادم نفسه؟ نعم. ضع كل خدمة في حاوية ووجّهها عبر بروكسي عكسي واحد بدومينات فرعية مختلفة. Caddy أو Traefik يديران شهادات عدّة دومينات تلقائيًا. انتبه فقط لكفاية الذاكرة لكل الخدمات.

ما الفرق بين الوضع العادي وqueue mode؟ في الوضع العادي تنفّذ حاوية واحدة كل شيء، ويكفي أغلب الحالات. queue mode يفصل الواجهة عن عمّال (workers) ينفّذون بالتوازي عبر Redis، فيتوسّع أفقيًا للحِمل الثقيل. ابدأ بالعادي وانتقل لـqueue mode حين تتراكم التنفيذات فعلًا.

هل أكشف منفذ 5678 للوصول المباشر؟ لا. لا تكشف 5678 (n8n) ولا 5432 (PostgreSQL) للإنترنت أبدًا. الوصول يتمّ عبر البروكسي العكسي على 80/443 فقط، والبروكسي يوجّه داخليًا. كشف المنفذ المباشر يفتح ثغرة أمنية كبيرة.

كم تكلّفني استضافة n8n ذاتيًا مقابل n8n Cloud؟ الاستضافة الذاتية تكلفتها ثابتة تقريبًا = سعر الـVPS شهريًا (يبدأ من مبلغ صغير لخادم متواضع)، مع تنفيذات غير محدودة عمليًا. n8n Cloud تتضخّم فاتورتها مع عدد التنفيذات والـworkflows النشطة. على المدى الطويل وللاستخدام الكثيف، الاستضافة الذاتية أوفر بوضوح.