الاستضافة الذاتية بأمان: مفتاح التشفير، وضع الطابور، والتخزين — وما الذي يغادر جهازك فعلاً

تشغيل n8n (تُنطق "n-eight-n"، أي «إن إتش إن» نطقاً) على خادمك قرار معماري، لا خطوة تثبيت. أنت على وشك أن تضع هناك أشياء لا تُستعاد: مفاتيح وبيانات اعتماد. سأبدأ بالمفاضلة لأنها تحدّد كل ما بعدها، ثم بقواعد لا تتأجل.

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

---

أين تعيش نسختك؟ المفاضلة قبل التوصية

الفرق الجوهري ليس «مجاني أم مدفوع»، بل من يحتفظ بمفتاحك ومن يخزّن بياناتك وأين يسقط العطل.

n8n يصوغها بجملة واحدة في صفحة الأسعار: For hosted plans, data is stored within the EU, on servers located in Frankfurt, Germany. For self-hosted plans, it's wherever you decide to host n8n. أي أن موضع بياناتك قرارٌ تتخذه أنت في الاستضافة الذاتية، وقرارٌ يتخذه غيرك في السحابة.

ماذا تشتري بالمال في السحابة؟ صيانة وترقيعات ومسؤولية. لا أحد يتصل بك في عطل.

ماذا تشتري بالمال في الاستضافة الذاتية؟ ثلاثة أشياء لا يمكن شراؤها ولا استئجارها:

• خطة Business نفسها — التي تضم SSO (SAML, LDAP) وEnvironments — غير متاحة إلا على n8n مُستضاف ذاتياً: Not yet. The Business plan is currently only available for self-hosted n8n. أي أن من يريد هذه الميزات لا يملك خيار السحابة أصلاً.
• بياناتك وتنفيذاتك تبقى حيث تضعها.
• نسخ العمل تجري على إيقاعك أنت، لا على إيقاع مطوّر آخر.

وماذا تدفع ثمناً؟ ثلاثتها ملموسة: قاعدة بيانات تتحمّل، ومفتاح تشفير لا يضيع، وترقيعات تذكّرك بها. وكل خطأ فيها خطأ بلا دعم فني.

كيف تقرر؟ ثلاثة أسئلة بالترتيب، وأولها يحسم الباقي:

1. هل تحتاج خطة Business؟ إن كان نعم، فالسؤال منتهٍ: السحابة ليست خيارك متاحاً.
2. هل يمنعك نظامك أو عقدك من إخراج بيانات إلى طرف ثالث؟ إن كان نعم، اقرأ قسم القياس عن بُعد قبل أن تقرّر — لأن الجواب ليس «نعم ولا شيء»، بل «يعتمد على أي خطة اشتريت».
3. هل تجاوز عملك نسخة واحدة؟ إن كان لا، فوضع الطابور — وهو أثقل ما في هذا المقال — تعقيد بلا عائد.

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

---

حزمة واحدة: ماذا يفعل كل ملف في الحزمة

التثبيت الذاتي ينتج بنية من ثلاثة أجزاء، لا تطبيقاً واحداً. أمر واحد في n8n يبني البنية كلها. هذا ناتج التشغيل الحقيقي كما يطبعه التوثيق:

# [مأخوذ من التوثيق] install-options/one-line-setup.md — ناتج التشغيل كما هو
$ curl -fsSL https://get.n8n.io | sh
✓ Created ./n8n/compose.yml
✓ Created ./n8n/searxng-settings.yml
✓ Created ./n8n/.env (unique secrets generated)
✓ Started n8n 2.32.0 and sandbox services
n8n is running at: http://localhost:5678
To upgrade: curl -fsSL https://get.n8n.io | sh -s -- --upgrade
To uninstall: docker compose -f ./n8n/compose.yml down -v   # -v DELETES all n8n data

• compose.yml يصف الخدمات وكيف تُشغَّل. هو تعريفك أنت، لا تعريف n8n.
• .env يحمل الأسرار، ولهذا هو الملف الذي يجب أن تأخذ منه نسخة ثانية إلى مدير أسرار.
• مجلد البيانات داخل المجلد n8n الذي ينشئه الأمر يحمل القاعدة وسجلّ التنفيذ، وهو نسختك الاحتياطية الأولى.

⚠️ -v في أمر إزالة يعني حذف كل بيانات n8n سطر الإزالة في التوثيق نفسه يحمل تحذيراً صريحاً: To uninstall: docker compose -f ./n8n/compose.yml down -v # -v DELETES all n8n data. كل بيانات اعتماد وكل تنفيذ وكل سير عمل يختفي. لا تنسخ هذا الأمر إلا بعد نسخة احتياطية.

المحرّر نفسه يعمل على http://localhost:5678، وهو منفذ افتراضي داخلي لا يصلح للتعريض المباشر في الإنتاج.

---

⚠️ مفتاح التشفير: القرار الذي لا يمكن التراجع عنه

بيانات الاعتماد لا تُحفظ كنص صريح، بل مشفّرة — والمفتاح يُولَّد في أول تشغيل دون سؤالك. النص حرفي: `To make sure that the data is secure, it gets saved to the database encrypted. n8n uses a random personal encryption key, which it automatically generates on the first run of n8n and then saves under `~/.n8n/config`.`

من هذه الجملة تبدأ ثلاث قواعد عملية:

• أول تشغيل هو لحظة الخطر. المفتاح يُولَّد ويُكتب في ~/.n8n/config دون أن يطلب منك إقراراً. لو فقدت هذا الملف، فلا يوجد في n8n مسار لاستعادة بيانات الاعتماد: كل ما مُلِئ في الواجهة صار نصاً مشفّراً لا مفتاح له.
• انسخ ~/.n8n/config احتياطياً مع نسخة قاعدة البيانات، لا لوحده. نسخة القاعدة بلا مفتاحها لا قيمة لها.
• لا تضع المفتاح في نفس النسخة التي تحفظها. ضعه في مدير أسرار، واجعل النسخة الثانية هي النسخة الاحتياطية.

حين تضيف عمالاً في وضع الطابور، المفتاح يصير عقداً مشتركاً لا خياراً: The encryption key of the main n8n instance must be shared with all worker and webhooks processor nodes to ensure these worker nodes are able to access credentials stored in the database. أي عامل يحمل مفتاحاً مختلفاً عن مفتاح النسخة الرئيسية سيقرأ البيانات من القاعدة ولا يفكّها — وستظهر أخطاء غامضة لا تشرح نفسها.

ولأن التوليد التلقائي عشوائي، النسخة التي تغيّر فيها المفتاح بعد أول تشغيل تصير نسخة ثانية لا تقرأ أولها. ومكان الإخراج:

# [مأخوذ من التوثيق] set-a-custom-encryption-key.md
export N8N_ENCRYPTION_KEY=<SOME RANDOM STRING>

هنا السطر ليس مثالاً — هو نقطة البداية. اضبطه قبل أول تشغيل، واحتفظ به خارج نسخة بياناتك.

---

⚠️ «استضافة ذاتية» لا تعني «لا يغادر شيء جهازك»

الافتراض السائد خاطئ تماماً، والفكرة مخالفة للمنشور نفسه. By default, a self-hosted n8n instance sends data to n8n's servers. It notifies users about available updates, workflow templates, and diagnostics. — «افتراضياً». هذه هي الحالة التي تبدأ منها، لا الاستثناء.

والمشكلة أن التفعيل ليس تفصيلاً صامتاً: n8n enables telemetry collection by default. وn8n sends most data when events occur. Workflow execution counts and an instance pulse are sent periodically (every 6 hours).

بعبارة أوضح: تُرسل عدّادات تنفيذات سيرات عملك، ونبضة عن النسخة نفسها كل ست ساعات. بلا مفتاح عملك، بلا نص تنفيذاته، بلا بيانات اعتمادك — لكن بلا موافقتك أيضاً.

التعطيل يحتاج مفتاحين، لا مفتاحاً واحداً. أولاهما من صفحة القياس نفسه:

# [مأخوذ من التوثيق] security/control-telemetry.md — VERBATIM
export N8N_DIAGNOSTICS_ENABLED=false
export N8N_VERSION_NOTIFICATIONS_ENABLED=false

وثانيهما يعطيك العزل الكامل، ومن صفحة العزل نفسها:

# [مأخوذ من التوثيق] configuration-examples/isolate-n8n.md — VERBATIM
N8N_DIAGNOSTICS_ENABLED=false
N8N_VERSION_NOTIFICATIONS_ENABLED=false
N8N_TEMPLATES_ENABLED=false
EXTERNAL_FRONTEND_HOOKS_URLS=
N8N_DIAGNOSTICS_CONFIG_FRONTEND=
N8N_DIAGNOSTICS_CONFIG_BACKEND=

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

وأخطر مما سبق: ترخيص الأعمال. هذه جملة يجب أن يعرفها كل مشترٍ قبل الدفع لا بعده:

To access Business or Enterprise features on your self-hosted instance, you receive a license key that must ping our license server daily to stay active. This ping includes data like the number of production executions, which helps us track usage.

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

فإن كان نظامك يمنع الاتصال الخارجي أصلاً، فالقرار الذي أمامك ليس «أعطّل القياس» — بل «هل أدفع ثمن خطة لا تستطيع تشغيلها على شبكتك؟».

---

قاعدة البيانات: لماذا SQLite يكفي للتجربة ولا يكفي لفريق

القاعدة الافتراضية مدمجة في المنتج ولا تحتاج قراراً — حتى تحتاجه. n8n يصفها هكذا: **A built-in database** | Stores your workflows, credentials, and execution history. This is [SQLite], a lightweight database that lives in a file. ملف واحد يحفظ سيرَياتك وبيانات اعتمادك وسجل تنفيذاتك.

ثم ينصح، في الجملة نفسها، نصيحة تُطبَّق على أي بيئة إنتاج: If you're setting n8n up for a team or a production environment, consider a more robust database like Postgres rather than the built-in default.

القاعدة التي أطبّقها: نسخة فردية على جهاز واحد يمكن أن تبقى على SQLite. أول ثلاثة مستخدمين حقيقيين يقرأون نفس النسخة، تخرج إلى Postgres. لا تنتظر تعطّلاً؛ تعارض قفل الكتابة على ملف واحد تحت ضغط متزامن هو ما يقلع القاعدة، لا حجم البيانات.

---

وضع الطابور: متى تختاره وماذا يكلّفك

وضع الطابور ليس «نسخة أسرع» — إنه تحويل n8n من تطبيق واحد إلى نظام موزّع. التوثيق يصف المسار بثلاث خطوات: 1. The main n8n instance handles timers and webhook calls, generating (but not running) a workflow execution. ثم 2. It passes the execution ID to a message broker, [Redis] ثم 3. A worker in the pool picks up message from Redis.

الفرق الجوهري في الجملة الأولى: النسخة الرئيسية لا تُنفّذ. تولّد معرّف التنفيذ وتسلّمه. البيانات لا تمرّ عبر Redis، المعرّف فقط.

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

# [مأخوذ من التوثيق] scaling/enable-queue-mode.md — VERBATIM
export EXECUTIONS_MODE=queue
export N8N_ENCRYPTION_KEY=<main_instance_encryption_key>
export WEBHOOK_URL=https://your-webhook-url.com
export N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true
docker run --name some-redis -p 6379:6379  -d redis
./packages/cli/bin/n8n worker
docker run --name n8n-queue -p 5679:5678 n8nio/n8n worker

قبل تشغيل أي عامل، مرّر له --concurrency بالقيمة التي نصح بها n8n، وضع نفس N8N_ENCRYPTION_KEY في بيئته.

متى تستحق الثمن؟ حين يتجاوز عبء عملك ما تنفّذه نسخة واحدة، أو حين تحتاج تنفيذات طويلة لا تشغل المحرّر. متى لا؟ حين لا تستطيع أن تضبط Postgres وRedis وتوازن الأحمال — عندها أضفت ثلاث أدوات جديدة إلى مشكلة واحدة.

توازن العمال: الرقم الذي يفاجئ

الرقم الافتراضي ليس محايداً، بل ناقص إلى درجة الخطورة. النص: `You can define the number of jobs a worker can run in parallel by using the `concurrency` flag. It defaults to `10`.` — أي عشرة أعمال متوازية لكل عامل افتراضياً. لكن n8n ينصح بغير هذا: `n8n recommends setting concurrency to 5 or higher for your worker instances. Setting low concurrency values with a large numbers of workers can exhaust your database's connection pool, leading to processing delays and failures.`

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

---

⚠️ حدود وضع الطابور: ثلاثة أسوار لا تُخترق

وضع الطابور ليس توسّعاً كاملاً لنسخة واحدة — بل له حدودان مكتوبتان صراحة، وحدّ ثالث يخصّ الوكلاء.

السار الأول: لا تخزين ثنائي على نظام الملفات. n8n doesn't support queue mode with binary data storage in filesystem. If your workflows need to persist binary data in queue mode, you can use S3 external storage. أي أن سير عملاً يعالج صوراً أو ملفات وينجو منها في النسخة الواحدة ينهار عند التحوّل إلى الطابور، إلا إذا جهّزت تخزيناً خارجياً من نوع S3.

السار الثاني: SQLite خارج المعادلة. `Running n8n with execution mode set to `queue` with an SQLite database isn't recommended.` — كلام خفيف القلم لكنه واضح المعنى: النظام الموزّع فوق ملف واحد لا يعمل.

السار الثالث: الوكلاء خارج الطابور. Queue mode isn't supported for agents yet, and connecting channels (such as Telegram) can fail. Run agents in regular mode for now. هذا يعني أن من بنى وكيلاً — لا عقدة AI Agent داخل سير عمل، بل الوكيل نفسه — (وإذا كان هذا الاسم غاماضاً فهناك مقال يفرّق بين الثلاثة) — لا ينتقل إلى الطابور الآن.

اجمع الأقواس الثلاثة قبل أن تاخذ قرار التوسّع: الطابور بلا تخزين خارجي، ولا فوق SQLite، ولا مع الوكلاء. الخطأ الشائع هنا ليس الجهل بالمصطلحات — بل الانتقال من «نسخة واحدة ناجحة» إلى «نظام موزّع» قبل أن يسأل أحد: هل سيرَياتي تعالج ملفات أصلاً؟ وهل سأكتب تلك الملفات أم سألتهم من خوادم أخرى؟

---

التوسّع الأفقي: ما هو متاح في Community وما هو Enterprise

وضع الطابور متاح في إصدار Community — أما تشغيل أكثر من نسخة رئيسية فلا. n8n يذكر التفصيل الدقيق: Multi-main mode (Queue mode *is* included). أي أن «متعدد الرئيسية» مستثنى، بينما الطابور نفسه داخل نطاق الإصدار المجاني. وهذا تفصيل يغيّر قرار التوسّع: التوسّع بالطابور متاح دون اشتراك، أما توزيع الأحمال على أكثر من نسخة رئيسية فيندرج تحت ترخيص مدفوع.

وما هو مدفوع تحديداً:

• متعدد الرئيسية (multi-main): * **Self-hosted:** Enterprise — وهو غير متاح في السحابة أصلاً: It isn't available on n8n Cloud. ويحتاج ضبط N8N_MULTI_MAIN_SETUP_ENABLED مع N8N_MULTI_MAIN_SETUP_KEY_TTL=10 وN8N_MULTI_MAIN_SETUP_CHECK_INTERVAL=3.
• مشاهدة العمال أثناء العمل: Viewing running workers is available on: / * **Self-hosted:** Enterprise — أي أن Community يشغّل العمال لكنه لا يريك ما يفعلونه. تشخيص عطل في العمال يصبح قراءة سجلات بدل واجهة.

الفارق العملي: من يدفع ثمن Enterprise في هذا الموضع لا يشتري قدرة جديدة، بل قدرة تشخيص: عمال يعملون عندك لكنك لا ترى حالتهم — وهذا يجعل أخطاء «لم يُنفَّذ شيء» تُحلّ بالتخمين لا بالقراءة.

ولنعد إلى القائمة الكاملة لما يستثنيه إصدار Community، فهي ما تقارنه باحتياجك قبل الاشتراك: Custom variables وEnvironments وExternal secrets وExternal storage for binary data وLog streaming وMulti-main mode وProjects وSSO (SAML, LDAP) وSharing (workflows, credentials) وVersion control using Git. وللأسعار وتفاصيل الخطط الأربعة، انظر مقال الترخيص والإصدارات.

---

⚠️ SOAP: نقطتان لا يجب أن يمرّ إليك كل طلب

خلف موازن تحميل، بعض المسارات لا يجوز أن تتوزّع على أكثر من نسخة. التوثيق يسمّي مسارين اثنين: ` * `/webhook/*`: Webhook trigger node endpoints` و` * `/webhook-waiting/*`: Human-in-the-loop webhook endpoints used by nodes that perform "send and wait" operations (for example, the Slack node).` أما المسارات التجريبية منفصلة: The default URL for manual workflow executions is /webhook-test/*.

لماذا المساران خطيران؟ لأنهما يحملان حالة معلّقة. طلب إلى /webhook-waiting/* هو إنسان ينتظر إجابة؛ إن وصل الطلب إلى نسخة أخرى، ذهب إلى نسخة لا تعرف أنه ينتظر. النتيجة: انتهاء مهلة، أو «تعذّر التنفيذ» بلا رسالة خطأ واضحة. أما /webhook/* فالمشكلة فيه معاكسة: نسخة تستقبل الطلب قد لا تكون هي التي تكمل الإعداد، فتفقد تنفيذاً كان يجب أن يقع.

القاعدة: وجّه هذين المسارين إلى نسخة واحدة مخصّصة، ولا توزّعهما. وهذا ينطبق أيضاً على /mcp* إن أضفت خادم MCP — الدليل في مشروع الإنتاج من الصفر.

وفي وضع الطابور، انتبه للذاكرة قبل الطلبات. حدّ حجم الردّ المعلّق: `N8N_WEBHOOK_RESPONSE_RELAY_SIZE_MAX` sets how large that message can be, in MiB. It defaults to `64`.` — و`Redis holds several copies of a response in flight, so budget about 1.5 times this value in Redis memory` — أي أن Redis الذي ظننته رقيقاً يحتاج هذا المضاعف على الأقل.

---

قائمة تحقّق قبل أن تقول «نسختي جاهزة»

كل بند في هذه القائمة يمنع كارثة، وأغلبها لا يكلّف شيئاً. مرّ عليها قبل أن تدفع باسم هذه النسخة إلى الإنتاج:

• N8N_ENCRYPTION_KEY مضبوط في .env قبل أول تشغيل، ونسخة منه في مكان آمن خارج بيانات n8n.
• نسخة احتياطية من مجلد بيانات n8n مع ملف ~/.n8n/config.
• متغيّرات العزل الستة مضبوطة، أو قرارك بالاعتماد على القياس موثّق ولمَن يقرؤه.
• خطة Business أو Enterprise لا تعمل على شبكة معزولة — فقرار الدفع يسبق قرار الشبكة.
• Postgres لا SQLite، إن كان هناك أكثر من مستخدم حقيقي واحد.
• عمال الطابور يحملون نفس المفتاح، وconcurrency مضبوط وفق توصية n8n.
• تخزين خارجي من نوع S3 إن كانت سيرَياتك تعالج ملفات ثنائية، وإلا فوضع الطابور مغلق عليك.
• /webhook/* و/webhook-waiting/* إلى نسخة واحدة في موازن التحميل.
• نسخة احتياطية قبل أي docker compose down -v.

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

للمزيد من السياق الترخيصي — ولماذا يهمّك أن n8n ليس MIT، وما الذي يُحذف عند الترقية الكبرى — تابع من صفحة الترخيص والإصدارات. وإن كنت في أول سلسلة مقالات عن هذه الأداة، فالمدخل الأنسب من صفحة السلسلة.

---

أُراجع في n8n 2.42.5 (2026-10-08). n8n يُصدر نسخاً جديدة أسبوعياً تقريباً، فراجع التوثيق إن كان عمرك يتجاوز بضعة أشهر.

---

تحتاج أتمتة تعمل فعلاً؟

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