بقلم Matt Connor 2026-07-15 · آخر تحديث في 2026-07-22

استضافة n8n ذاتيًا على VPS: Docker وHTTPS

Q: لماذا لا تُطلَق webhooks n8n لديّ أبدًا؟

يكاد السبب يكون دائمًا WEBHOOK_URL. إن كان غير مضبوط أو خاطئًا، يطبع n8n عناوين webhook مبنية من N8N_HOST:N8N_PORT — غالبًا بها :5678 أو localhost — تبدو صالحة لكنها غير قابلة للوصول من الإنترنت، فلا تصل طلبات المستدعي أبدًا. اضبط WEBHOOK_URL=https://n8n.example.com/ وتأكد من أن العقدة تعرض رابطًا بلا منفذ. السبب الثاني هو استدعاء webhook لسير عمل غير مُبدَّل إلى Active، وهو ما يعيد The requested webhook ... is not registered.

Q: ما الذي يجب أن أنسخه احتياطيًا في n8n؟

شيئان. N8N_ENCRYPTION_KEY من ملف .env لديك، لأن كل بيانات اعتماد مخزَّنة تُشفَّر بها وفقدانه يجعلها غير قابلة لفك التشفير نهائيًا — انسخه إلى خارج الخادم في اليوم الذي تنشئه فيه. وتفريغ pg_dump لقاعدة بيانات Postgres من أجل سير العمل والسجلّ وبيانات الاعتماد. تحتاج الاستعادة إلى الاثنين معًا: المفتاح نفسه إلى جانب التفريغ.

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

ثبّت وسم صورة محددًا بدلًا من latest، وخذ pg_dump أولًا لأن n8n ينفّذ الترحيلات تلقائيًا عند البدء، واقرأ ملاحظات الإصدار بحثًا عن التغييرات غير المتوافقة، ثم ارفع الوسم ونفّذ docker compose pull n8n && docker compose up -d n8n. الحاوية قابلة للاستغناء عنها، فتراجع بتثبيت الوسم السابق واستعادة التفريغ الذي أخذته قبل الترقية.

شغّل n8n على VPS بـ Docker Compose وPostgres وHTTPS خلف وكيل عكسي: فخّا WEBHOOK_URL ومفتاح التشفير، وكل رسالة خطأ ستواجهها.

ما الذي ستبنيه

n8n أداة أتمتة سير العمل: محرر مرئي حيث يُطلق مُشغِّل — webhook، أو جدول زمني، أو إرسال نموذج — سلسلة من العُقد التي تستدعي واجهات API، وتعيد تشكيل البيانات، وتكتبها إلى أنظمة أخرى. أصبح n8n الأداة الرابطة الافتراضية لسير عمل وكلاء الذكاء الاصطناعي لأنه يتكامل مع كل مزوّد نماذج وكل قاعدة بيانات دون أن تكتب خدمة بنفسك. أمر docker run واحد يمنحك محررًا عاملًا خلال دقيقتين. هذا الدليل يتناول التسعين بالمئة الباقية: جعله متينًا بـ Postgres بدلًا من ملف SQLite الافتراضي، وقابلًا للوصول عبر HTTPS، وهو الجزء الذي يخطئ فيه الجميع تقريبًا: جعل الـ webhooks توزّع رابطًا يستطيع العالم الخارجي الوصول إليه فعلًا.

الحزمة النهائية حاويتان على شبكة Docker واحدة: n8n نفسه، وقاعدة بيانات Postgres تحمل سير عمله وبيانات اعتماده. وكيل عكسي (reverse proxy) على المضيف يُنهي TLS ويمرّر الطلبات إلى n8n على localhost، بحيث لا يتعرض شيء للإنترنت إلا عبر ذلك الوكيل. يقف n8n إلى جانب الخدمات الأخرى في قائمة الاستضافة الذاتية المختصرة لعام 2026.

المتطلبات المسبقة، والحدود الواقعية

تحتاج إلى خادم VPS بذاكرة RAM لا تقل عن 1 غيغابايت؛ خطّط لـ 2 غيغابايت متى بدأ سير العمل يؤدي عملًا حقيقيًا، لأن عمليات التنفيذ إلى جانب بيئة تشغيل Node.js تستهلك الذاكرة، ورؤية قاتل نفاد الذاكرة (out-of-memory killer) يطيح بالحاوية في منتصف عملية تشغيل طريقة بائسة لتعلّم ذلك. معالج افتراضي واحد (vCPU) كافٍ للبدء.

تحتاج إلى نطاق أو نطاق فرعي — لنقل n8n.example.com — بسجل A يشير إلى عنوان IP العام لخادم VPS ويتحلّل قبل أن تطلب الشهادة. يجب أن يكون المنفذان 80 و443 مفتوحين نحو الوكيل؛ ويجب ألا يتعرض منفذ n8n الخاص 5678 للإنترنت. تحتاج إلى Docker Engine وإضافة Compose؛ فإن أخفق الأمر docker compose version برسالة docker: 'compose' is not a docker command فأنت تملك الملف التنفيذي المستقل القديم، والإضافة تُثبَّت بالأمر sudo apt install docker-compose-plugin.

SQLite يكفي للتجربة، وPostgres لكل ما تعتمد عليه

قاعدة بيانات n8n الافتراضية ملف SQLite في /home/node/.n8n/database.sqlite. للتجربة السريعة هذا يكفي — لا تُركِّب أي وحدة تخزين (volume) وستفقده عند أول إعادة إنشاء للحاوية، وهذا درس بحد ذاته. سبب الانتقال إلى Postgres ليس السرعة الخام؛ بل أن SQLite لا يتيح سوى قفل كتابة واحد، فأي نسخة تشغّل أكثر من سير عمل واحد في آن واحد، أو وضع قائمة الانتظار (queue mode) الذي ستحتاج إليه يومًا ما، يُصدر الخطأ SQLITE_BUSY: database is locked عند التزامن. Postgres لا يعاني من هذا القيد، ويُنسَخ احتياطيًا بسلاسة بالأمر pg_dump، وهو ما تفترضه وثائق n8n نفسها لخادم تعتمد عليه. التحول لاحقًا يعني ترحيل البيانات يدويًا، فإن كان هذا الجهاز مهمًّا، ابدأ بـ Postgres.

DNS وجدار الحماية

وجّه السجل وافتح المنافذ أولًا، حتى لا تفشل خطوة الشهادة لاحقًا بسبب اسم لا يتحلّل.

dig +short n8n.example.com
curl -s ifconfig.me
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw enable

لا تفتح المنفذ 5678. ملف compose يربط n8n بـ 127.0.0.1:5678 بحيث لا يصله سوى الوكيل العكسي على المضيف، وأمر ufw allow 5678 سينسف هذا العزل.

ملف Compose

أنشئ دليل عمل وملف docker-compose.yml. هذه هي الحزمة كاملة — خدمتان، وشبكة خاصة واحدة، ووحدتا تخزين مسمّاتان.

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

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.29.10
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Europe/London
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - n8n_net
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres_data:
  n8n_data:

networks:
  n8n_net:

قرارات قليلة تستحق أن تُذكَر صراحة. DB_POSTGRESDB_HOST=postgres هو اسم الخدمة، الذي يحلّه Docker على الشبكة المشتركة — لا localhost، الذي يعني، داخل حاوية n8n، n8n نفسه. depends_on مع condition: service_healthy يمنع n8n من التسابق مع Postgres عند الإقلاع؛ فمن دونه يبدأ n8n، ولا يجد قاعدة بيانات، ويخرج. وحدة التخزين المسمّاة n8n_data عند /home/node/.n8n تحمل مفتاح التشفير، وعلى SQLite، قاعدة البيانات — الدليل الوحيد الذي يجب ألا تفقده. ثبّت الصورة على إصدار محدد، لا latest أبدًا؛ الأسباب في قسم الترقيات أدناه.

ملف الأسرار

لا تضع كلمات المرور أبدًا في ملف compose. ضعها في ملف .env مجاور له يقرؤه Compose تلقائيًا، وولّدها لتكون عشوائية فعلًا.

printf 'POSTGRES_PASSWORD=%s\n'  "$(openssl rand -hex 24)" >  .env
printf 'N8N_ENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" >> .env
chmod 600 .env

N8N_ENCRYPTION_KEY هي السلسلة الأهم هنا على الإطلاق — إنها المفتاح الذي يُشفَّر به كل بيانات اعتماد مخزَّنة. اضبطها صراحة بدلًا من ترك n8n يولّد واحدة، لأن القيمة التي تولّدها أنت قيمة يمكنك تدوينها واستعادتها. بمجرد أن يشفّر n8n أول بيانات اعتماد بهذا المفتاح، تغييره يجعل كل بيانات الاعتماد غير قابلة لفك التشفير — لذا اضبطه مرة واحدة، الآن، ولا تلمس ذلك السطر ثانية أبدًا.

متغيرات البيئة التي تقرر ما إذا كانت الـ webhooks تعمل

أربعة متغيرات تتحكم في الطريقة التي يصف بها n8n نفسه للعالم الخارجي، وضبطها خطأً هو سؤال الدعم الفني الأول لـ n8n.

N8N_HOST هو اسم المضيف العام، n8n.example.com. اتركه على القيمة الافتراضية localhost خلف وكيل عكسي ويحاول المحرر تحميل واجهة API الخاصة به من localhost داخل متصفحك أنت، فيفشل.
N8N_PROTOCOL=https يخبر n8n أنه يُقدَّم عبر TLS، فيضع علامة Secure على ملف تعريف ارتباط الجلسة ويبني روابط بصيغة https://.
N8N_PORT=5678 هو المنفذ الذي يستمع عليه n8n داخل الحاوية. ليس المنفذ العام؛ فالوكيل يملك المنفذ 443.
WEBHOOK_URL=https://n8n.example.com/ هو المتغير الذي يؤلم. يطبع n8n عناوين الـ webhook التي تلصقها في Stripe أو GitHub أو أي طرف خارجي مستدعٍ ببنائها من هذه القيم. إن كان غير مضبوط أو خاطئًا، يعود n8n إلى N8N_HOST:N8N_PORT ويعطيك https://n8n.example.com:5678/webhook/... أو، أسوأ من ذلك، http://localhost:5678/webhook/... — يُطبَع دون أي خطأ، ويبدو معقولًا، وغير قابل للوصول من الإنترنت، فلا تصل طلبات المستدعي أبدًا، بصمت. اضبطه على رابط الأساس العام الدقيق، بما في ذلك الشرطة المائلة الأخيرة، ثم تأكد من أن عقدة الـ webhook تعرض رابطًا بلا منفذ.

N8N_PROXY_HOPS=1 يخبر خادم Express الخاص بـ n8n بأن يثق بوكيل واحد أمامه، بحيث يرى تحديد المعدل (rate limiting) وأي ميزة تقرأ عنوان IP العميل العنوان الحقيقي بدلًا من عنوان الوكيل. متغير تتعمد ألا تضبطه هنا هو N8N_RUNNERS_ENABLED: منفّذات المهام (task runners) — تشغيل n8n لمنطق عقدة Code في عملية معزولة منفصلة — أصبحت الافتراضي منذ الإصدار 1.69، وباتت إلزامية من سلسلة 2.x التي يثبّتها هذا الدليل، فالتفعيل اليدوي القديم أصبح مهجورًا. اضبطه الآن ولن يفعل n8n شيئًا سوى تسجيل إشعار يطلب منك إزالته.

أول تشغيل

docker compose up -d
docker compose ps
docker compose logs -f n8n

الإقلاع الأول السليم ينتهي بسطر Editor is now accessible via:، يسبقه سطر n8n ready on ..., port 5678. يجب أن يُظهر docker compose ps كلتا الحاويتين بحالة Up، مع تمييز postgres بـ (healthy). إن ظل n8n عالقًا في حلقة Restarting، اقرأ السجلّات — غالبًا ما تكون المشكلة اتصال قاعدة البيانات أو أذونات وحدة التخزين المشروحة أدناه.

TLS مع وكيل عكسي

يتحدث n8n نفسه بـ HTTP الصريح على المنفذ 5678؛ شيء أمامه يُنهي HTTPS. خياران نظيفان.

إن كنت تشغّل بالفعل عدة حاويات، ضع n8n خلف وكيل Traefik العكسي الذي يُصدر شهادات TLS تلقائيًا ببضع علامات (labels) فقط — يطلب Traefik الشهادة ويجدّدها نيابة عنك.

إن كان هذا هو التطبيق الوحيد على الجهاز، فمضيف افتراضي في nginx بشهادة Let's Encrypt أبسط. استخدم إعداد TLS بـ Certbot وnginx على Ubuntu 24.04 للحصول على الشهادة، ثم كتلة server هذه:

server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate     /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600;
        client_max_body_size 16m;
    }
}

ترويستا Upgrade وConnection "upgrade" ليستا اختياريتين. يدفع n8n تحديثات التنفيذ الحية إلى المحرر عبر WebSocket، ومن دون هذين السطرين تُحمَّل صفحة تسجيل الدخول ثم تتجمد ببانر اتصال مفقود. proxy_read_timeout 3600 يمنع قطع عمليات التنفيذ الطويلة عند حد الستين ثانية الافتراضي في nginx. ترويسة X-Forwarded-Proto $scheme هي رفيقة N8N_PROXY_HOPS=1: تخبر n8n أن الطلب الأصلي كان عبر HTTPS رغم أن الوكيل يصله عبر HTTP صريح، بحيث لا يقرر n8n أن الاتصال غير آمن فيرفض ملف تعريف الارتباط الخاص به.

سير عملك الأول، ليصبح الأمر ملموسًا

افتح https://n8n.example.com/، وأنشئ حساب المالك (القسم التالي)، وابنِ أصغر سير عمل يثبت أن المسار يعمل: webhook في الدخول، استدعاء HTTP، استجابة في الخروج.

أضف عقدة Webhook. اضبط الطريقة على POST ومسارًا مثل hello. تعرض العقدة رابطين، Test URL وProduction URL — مصدر نصف التقارير من نوع «الـ webhook لا يعمل عندي». يجيب Test URL على استدعاء واحد فقط، وفقط طالما ضغطت Listen for test event؛ ثم تنتهي صلاحيته. يجيب Production URL كلما كان سير العمل Active.
أضف بعده عقدة HTTP Request، موجَّهة إلى أي واجهة JSON عامة — طلب GET إلى https://api.github.com/zen يعيد سلسلة من سطر واحد، وهذا كافٍ.
أضف عقدة Respond to Webhook، واضبط خيار Respond في عقدة Webhook على "Using Respond to Webhook node" حتى يحصل المستدعي على مخرجات عقدة HTTP.
بدّل سير العمل إلى Active (أعلى اليمين) واستدعه: curl -X POST https://n8n.example.com/webhook/hello. ينبغي أن تسترجع سطر zen — POST في الدخول، استدعاء API، استجابة في الخروج، وهو شكل معظم الأتمتة الحقيقية.

نسخة مجدولة تستبدل عقدة Webhook بعقدة Schedule Trigger وتستدعي نقطة نهاية نموذج بدلًا من ذلك — نموذج مستضاف ذاتيًا من Ollama يعمل على خادم VPS نفسه طريقة أنيقة لبناء ملخِّص ليلي.

إدارة المستخدمين، لا المصادقة الأساسية

الأدلة القديمة لـ n8n تطلب منك ضبط N8N_BASIC_AUTH_ACTIVE=true. حُذفت تلك المتغيرات في n8n 1.0 ولم تعد تفعل شيئًا. المصادقة اليوم هي حساب المالك: في المرة الأولى التي تحمّل فيها المحرر، يُجبرك n8n على إنشاء مالك ببريد إلكتروني وكلمة مرور، وهذه البوابة إلزامية — لا وجود لوضع مجهول. أنشئه فور الإقلاع الأول، قبل أن تعطي الرابط لأي أحد: فبين docker compose up وإرسال ذلك النموذج الأول، يمكن لأول من يصل إلى النسخة أن يستحوذ عليها. طبقة مصادقة أساسية على الوكيل العكسي فوق ذلك قفل إضافي معقول، لكنه عامل ثانٍ، لا المصادقة الحقيقية.

النسخ الاحتياطي: مفتاح التشفير أولًا، ثم قاعدة البيانات

يحتاج شيئان إلى نسخ احتياطي، وهما ليسا قابلين للتعويض بالتساوي.

N8N_ENCRYPTION_KEY. كل بيانات اعتماد تخزّنها في n8n — توكنات API، وكلمات مرور قواعد بيانات، وأسرار OAuth — تُشفَّر أثناء السكون بهذا المفتاح. سير العمل في Postgres عديم الفائدة من دونه: استعِد قاعدة البيانات على جهاز جديد بمفتاح مختلف ولن يستطيع n8n فك تشفير بيانات اعتماد واحدة، دون استرجاع ودون إعادة ضبط. ملف .env لديك يحمل المفتاح؛ انسخه إلى مكان خارج الخادم — إدخال في مدير كلمات مرور خيار مثالي — في اليوم الذي تنشئه فيه. هذه هي النسخة الاحتياطية التي تهم فعلًا.

قاعدة بيانات Postgres، من أجل سير العمل وسجلّ التنفيذ وبيانات الاعتماد المشفَّرة نفسها:

docker compose exec -T postgres pg_dump -U n8n -d n8n \
  | gzip > n8n-db-$(date +%F).sql.gz

نفّذ ذلك وفق جدول زمني وانسخ التفريغ (dump) إلى خارج الجهاز. للاستعادة على خادم VPS جديد: شغّل الحزمة مرة حتى توجد قاعدة البيانات، أوقف n8n، أعد تحميل التفريغ بالأمر psql، ضع نفس N8N_ENCRYPTION_KEY في .env، وابدأ n8n. المفتاح نفسه إلى جانب التفريغ يعطي نسخة عاملة؛ ومفتاح جديد يعطي سير عمل عاجزًا عن استخدام أي بيانات اعتماد.

الترقيات: ثبّت الوسم

يثبّت ملف compose الوسم n8nio/n8n:2.29.10 بدلًا من latest عن قصد. يُصدر n8n إصدارًا ثانويًا جديدًا في معظم الأسابيع، ويغيّر أحيانًا مخطط قاعدة البيانات أو سلوك العقد بين إصدار وآخر، فـ latest تعني أن سحبًا (pull) غير مراقَب قد يمنحك بناءً (build) يُرحِّل قاعدة بياناتك لحظة بدئه. ثبّت إصدارًا، واقرأ ملاحظات الإصدار قبل الترقية — يذكر n8n فيها التغييرات غير المتوافقة — ورَقِّ عن قصد:

docker compose exec -T postgres pg_dump -U n8n -d n8n | gzip > pre-upgrade.sql.gz
# edit the image tag in docker-compose.yml, then:
docker compose pull n8n
docker compose up -d n8n
docker compose logs -f n8n

وعند القفزات بين الإصدارات الرئيسية يهم هذا أكثر ما يكون. سلسلة 2.0، على سبيل المثال، قلبت N8N_BLOCK_ENV_ACCESS_IN_NODE إلى true افتراضيًا، فأي عقدة Code تقرأ process.env تفقد الوصول بصمت حتى تعيدها إلى false؛ وبدأ الإصدار نفسه بفرض أذونات صارمة على ملف الإعدادات. اقرأ صفحة التغييرات غير المتوافقة في 2.0 قبل عبور حد إصدار رئيسي. ينفّذ n8n تلقائيًا عند البدء أي ترحيلات (migrations) لازمة لقاعدة البيانات — ولهذا بالضبط لا يكون pg_dump قبل الترقية اختياريًا. ولأن بيانات الاعتماد مخزَّنة مشفَّرة بمفتاح في .env والبيانات موجودة في Postgres، فالحاويات قابلة للاستغناء عنها: تُرقّي باستبدالها، وتتراجع بتثبيت الوسم السابق واستعادة التفريغ.

أنماط الفشل، مع النصوص التي سترى

The requested webhook "POST hello" is not registered. خطأ 404 ناتج عن استدعاء webhook لسير عمل غير Active، أو عن استدعاء مسار الاختبار حين لا أحد يستمع. مسارات الاختبار (/webhook-test/...) تجيب فقط طالما ضغطت "Listen for test event"؛ ومسارات الإنتاج (/webhook/...) تجيب فقط حين يكون مفتاح سير العمل مفعّلًا. الرسالة الشقيقة This webhook is not registered for GET requests. Did you mean to make a POST request? تعني أن الطريقة خاطئة — العقدة تتوقع POST وأرسلت أنت GET.

رابط الـ webhook يعرض :5678 أو localhost. تعرض العقدة https://n8n.example.com:5678/webhook/... أو http://localhost:5678/.... WEBHOOK_URL غير مضبوط أو خاطئ، فبنى n8n العنوان من N8N_HOST:N8N_PORT بدلًا من أساسك العام. اضبط WEBHOOK_URL=https://n8n.example.com/، أعد إنشاء الحاوية بالأمر docker compose up -d، ويختفي المنفذ.

There was a problem loading init data في المتصفح. يُحمَّل المحرر لكنه يعجز عن الوصول إلى واجهة API الخلفية الخاصة به. خلف وكيل عكسي يكون السبب في الغالب N8N_HOST أو WEBHOOK_URL خاطئًا، أو وكيلًا يفتقد ترويستي WebSocket من نوع Upgrade، أو N8N_PROTOCOL لا يطابق طريقة اتصالك. تأكد من المتغيرات الأربعة الموجَّهة للعامة ومن أن الوكيل يمرّر Upgrade وConnection.

password authentication failed for user "n8n" في السجلّات، مع إعادة تشغيل الحاوية. كلمة المرور التي يرسلها n8n لا تطابق ما بدأت به قاعدة البيانات. الفخ: لا يقرأ Postgres POSTGRES_PASSWORD إلا حين يهيّئ دليل بيانات فارغًا. ابدأ الحزمة مرة، ثم غيّر POSTGRES_PASSWORD في .env، ووحدة التخزين postgres_data الموجودة لا تزال تحمل كلمة المرور القديمة. أعدها إلى الأصل، أو، إن لم يكن لديك بيانات تريد الاحتفاظ بها، نفّذ docker compose down ثم docker volume rm على وحدة تخزين postgres، وأقلع من جديد.

EACCES: permission denied, open '/home/node/.n8n/config' عند البدء. يعمل n8n بمستخدم node (المعرّف 1000) ولا يستطيع الكتابة في دليل إعداداته. يصيب هذا من يربط (bind-mount) مجلدًا من المضيف (./n8n_data:/home/node/.n8n) مملوكًا لـ root. استخدم وحدة التخزين المسمّاة الموضحة أعلاه، أو إن أصررت على ربط مجلد، نفّذ sudo chown -R 1000:1000 ./n8n_data أولًا.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. من سلسلة 2.x يفرض n8n القيمة 0600 على ملف الإعدادات هذا افتراضيًا ويصلحها بنفسه عند الإقلاع — هذا السطر في السجل يعني أنه صحّح الوضع بالفعل، غالبًا بعد ربط مجلد أو بعد أن أعادت عملية استعادة نسخ الملف بأذونات فضفاضة. لا حاجة إلى أي إجراء؛ لا تضبط N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false إلا إن كان نظام الملفات لديك غير قادر فعلًا على دعم الأذونات.

Mismatching encryption keys — السطر الكامل يقول إن مفتاح التشفير في ملف الإعدادات /home/node/.n8n/config لا يطابق N8N_ENCRYPTION_KEY في بيئتك. المفتاح في بيئتك يختلف عن ذلك الذي كتبه n8n في وحدة تخزين بياناته في تشغيل سابق — غالبًا لأن n8n ولّد مفتاحًا عشوائيًا في إقلاع سابق حين كان المتغير غير مضبوط، ثم ضبطت أنت مفتاحًا مختلفًا. أعد المفتاح الأصلي إلى .env، أو، فقط إن لم تكن لديك حقًّا أي بيانات اعتماد مخزَّنة تستحق الاحتفاظ بها، احذف ملف config داخل وحدة التخزين n8n_data ودع n8n يعيد توليده — مع قبول أن بيانات الاعتماد الحالية تصبح غير قابلة للقراءة.

بانر تسجيل دخول عن ملفات تعريف الارتباط الآمنة: Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari. ضبطت N8N_PROTOCOL=https لكنك وصلت إلى n8n عبر HTTP صريح — عادة بالوصول مباشرة إلى IP والمنفذ بدلًا من وكيل HTTPS. صِل عبر https://n8n.example.com/. لا تضبط N8N_SECURE_COOKIE=false إلا إن كنت حقًّا عاجزًا عن استخدام HTTPS، وأبدًا على جهاز يتعرض للإنترنت.

لوضع نموذج لغوي داخل سير العمل هذا، راجع بناء سير عمل بالذكاء الاصطناعي مع Claude وn8n.

FAQ

هل أستخدم SQLite أم Postgres مع n8n؟

SQLite (الافتراضي) يكفي لتجربة n8n ولنسخة شخصية تشغّل سير عمل واحدًا في كل مرة. انتقل إلى Postgres لكل ما تعتمد عليه: قفل الكتابة الواحد في SQLite يُصدر database is locked عند التزامن، وPostgres يُنسَخ احتياطيًا بسلاسة بالأمر pg_dump. الترحيل لاحقًا يدوي، فإن كان الجهاز مهمًّا، ابدأ بـ Postgres.

لماذا لا تُطلَق webhooks n8n لديّ أبدًا؟

يكاد السبب يكون دائمًا WEBHOOK_URL. إن كان غير مضبوط أو خاطئًا، يطبع n8n عناوين webhook مبنية من N8N_HOST:N8N_PORT — غالبًا بها :5678 أو localhost — تبدو صالحة لكنها غير قابلة للوصول من الإنترنت، فلا تصل طلبات المستدعي أبدًا. اضبط WEBHOOK_URL=https://n8n.example.com/ وتأكد من أن العقدة تعرض رابطًا بلا منفذ. السبب الثاني هو استدعاء webhook لسير عمل غير مُبدَّل إلى Active، وهو ما يعيد The requested webhook ... is not registered.

ما الذي يجب أن أنسخه احتياطيًا في n8n؟

شيئان. N8N_ENCRYPTION_KEY من ملف .env لديك، لأن كل بيانات اعتماد مخزَّنة تُشفَّر بها وفقدانه يجعلها غير قابلة لفك التشفير نهائيًا — انسخه إلى خارج الخادم في اليوم الذي تنشئه فيه. وتفريغ pg_dump لقاعدة بيانات Postgres من أجل سير العمل والسجلّ وبيانات الاعتماد. تحتاج الاستعادة إلى الاثنين معًا: المفتاح نفسه إلى جانب التفريغ.

كيف أضع n8n خلف HTTPS؟

يقدّم n8n HTTP صريحًا على المنفذ 5678؛ وكيل عكسي أمامه يُنهي TLS. اربط n8n بـ 127.0.0.1:5678 بحيث لا يصله سوى الوكيل، ثم استخدم Traefik بشهادات تلقائية أو nginx بشهادة Let's Encrypt. اضبط N8N_PROTOCOL=https وWEBHOOK_URL=https://your-host/، وتأكد من أن الوكيل يمرّر ترويستي WebSocket من نوع Upgrade وإلا تجمّد المحرر.

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

ثبّت وسم صورة محددًا بدلًا من latest، وخذ pg_dump أولًا لأن n8n ينفّذ الترحيلات تلقائيًا عند البدء، واقرأ ملاحظات الإصدار بحثًا عن التغييرات غير المتوافقة، ثم ارفع الوسم ونفّذ docker compose pull n8n && docker compose up -d n8n. الحاوية قابلة للاستغناء عنها، فتراجع بتثبيت الوسم السابق واستعادة التفريغ الذي أخذته قبل الترقية.

#n8n #automation #Docker #استضافة ذاتية#https