نحن نعمل بجد على مساعد ذكاء اصطناعي أقوى بكثير - فكر في Claude Code، لكن مدمج في n8n. هذا كان في قائمة أمنيات المجتمع لفترة طويلة، وهو مهم جداً أن نوفره للخوادم المستضافة بشكل ذاتي. نستهدف إطلاق نسخة مستضافة بشكل ذاتي هذا الصيف.
من أجل الأمان، تحتاج هذه المساعد إلى صندوق رمل (sandbox). يجب نشر هذا الصندوق في حاوية Docker منفصلة. هذا يعني أن n8n سيكون لديه اعتماد على Docker. لهذا السبب، من المنطقي أن نوحد على نشر قائم على Docker - خاصة لأنها طريقة نشر أكثر موثوقية على أي حال.
ما الذي ستعنيه هذه الخطوة لعمليات التثبيت القائمة على npm
إذا أردت الترقية، ستحتاج إلى التأكد من تثبيت Docker والنشر باستخدامه بدلاً من ذلك. يمكنك الاحتفاظ بتثبيتك في نفس المجلد وتجميع ذلك المجلد في Docker. سنوفر لك إرشادات حول كيفية القيام بذلك.
إذا كنت لا أريد المساعد، لماذا لا أستطيع الاستمرار في تشغيل بقية n8n عبر npm؟
بينما هذا ممكن من الناحية التقنية، كلما زاد عدد النكهات والتكوينات المختلفة للمنتج، زادت التعقيد والأخطاء التي نقدمها.
هناك فوائد أخرى للانتقال إلى Docker فقط؛ المساعد هو الأكثر إلحاحاً فقط. القيام بذلك سيؤدي إلى:
تسريع تطوير n8n
جعل n8n أسهل في الدعم
فتح الباب أمام دمج منتجات أخرى مع n8n في المستقبل إذا احتجنا إلى ذلك، على سبيل المثال قاعدة بيانات متجهة أو Redis.
ما الذي نود معرفته
نحن ندرك أنه قد توجد بعض الحالات التي يكون استخدام Docker فيها صعباً. يتم استخدام n8n بطرق عديدة ومختلفة وبعضها لا نعرف عنه حتى. لذا نود سماع الآراء من الجميع حول هذا الموضوع، سواء كنت تستخدم npm أو Docker حالياً - يرجى ملء الاستبيان أدناه!
أنا أدعم هذا. مضى وقت طويل منذ استخدمت npm لتثبيت n8n، باستثناء عند تطوير العُقد.
استخدام npm لتثبيت n8n سيؤدي دائماً إلى مشاكل في مرحلة ما. Docker أكثر أماناً أيضاً.
عندما يريد عملاؤنا منا إدارة نسخهم الخاصة، نشجعهم دائماً على استخدام Docker إذا كانوا يستخدمون npm. هذا يجعل كل شيء أسهل في الإدارة.
أنا أؤيد هذا التوجه. أنا أشغل n8n بنفسي في Docker وجربت npm قبلاً بشكل سريع. الفرق في الاستقرار والصيانة واضح جداً.
ما أقنعني في هذا القرار: مساعد الذكاء الاصطناعي المدمج يحتاج إلى بيئة عزل (Sandbox)، والبيئة العزل تحتاج Docker. هذا ليس اعتماداً تعسفياً بل له أساس تقني سليم. من يستخدم n8n بجدية، عادة ما يكون لديه Docker مشغلاً بالفعل.
النقطة الوحيدة التي تثير تأملاتي: هناك مستخدمون يشغلون n8n في بيئات محدودة جداً، على سبيل المثال خوادم افتراضية صغيرة بذاكرة محدودة، حيث يستهلك Docker موارد أكثر بملاحظة من تثبيت npm النقي. بالنسبة لهم، ستكون مساعدة هجرة واضحة وصورة Docker محسّنة مهمة جداً.
بشكل عام: عدد أقل من الخيارات يعني عدد أقل من الأخطاء وتطوراً أسرع. وهذا يفيد المجتمع بأكمله.
حسناً، حان الوقت للدخول إلى عالم Docker من خلال دروس CLI و Desktop.
إذا استطاع أحد الخبراء مشاركة ملف Docker كامل يتضمن queue و workers و task runners و postgresql و redis على سبيل المثال… يمكننا بالتأكيد منع محبي npm من فعل ذلك مرة أخرى في المستقبل
ملاحظة: يحب البعض npm… والبعض يحب docker… لكن الأهم من ذلك هو أن الجميع يحبون N8N!!!
أؤيد هذا الاتجاه. من خلال تشغيل n8n على خوادم VPS لبيئات عملاء متعددة، كان Docker أكثر استقراراً بكثير من npm عبر إصدارات n8n المختلفة - خاصةً عندما بدأت رمز الذكاء الاصطناعي (AI sandbox) بالحاجة إلى عزل العملية المنفصل.
الطلب الملموس الوحيد الذي أود أضيفه: ملف Compose بسيط في حاوية واحدة محسّن لخوادم VPS صغيرة (1-2 vCPU، 1-2 GB RAM) مع توثيق واضح حول الخدمات التي يمكن تعطيلها لتقليل الحمل. الكثير من مستخدمي الخدمات الذاتية يشغلون n8n على خوادم VPS بميزانية محدودة حيث يضيف Docker daemon نفسه ضغطاً على الذاكرة، لذا فإن التوجيهات حول إعداد Docker الأدنى القابل للتطبيق ستقلل الاحتكاك بالنسبة لتلك الترحيلات.
أقوم بتشغيل Docker على خادم VPS يعمل بنظام Ubuntu عبر MobaXterm. هذه الطريقة تقنية قليلاً، لكن أي شخص استخدمها من قبل سيفضلها على الأرجح على المدى الطويل.
Docker Compose + Cloudflare Tunnel هي إعدادات أساسية للمستخدمين - سهلة جداً في النسخ الاحتياطي والصيانة وحتى نقل البيانات.
متطلب بيئة الحماية (Sandbox) لمساعد الذكاء الاصطناعي هو مجرد فائدة إضافية.
ومع ذلك، هل تحتاج إعدادات Docker Compose الحالية إلى أي تغييرات عند إطلاق المساعد؟ أم أنها مجرد حاوية إضافية تتصل بالنظام ذاته وتعمل عليه؟
شكراً على الشفافية بشأن هذا الموضوع. أوافق على أن هناك فوائد للانتقال إلى Docker لكن هناك أيضاً بعض التحديات التقنية، بما في ذلك الوصول إلى الملفات المحلية والسماح بعمليات تشبه سطر الأوامر مثل إنشاء المجلدات والملفات. هذا يعمل مع عدة تعديلات اليوم وسيصبح أكثر تعقيداً مع إضافة Docker في الخليط.
جزء آخر قد يعقد الأمور هو ترخيص Docker نفسه وما يعنيه ذلك لبعض المستخدمين.
فكرة جيدة جداً، بالإضافة إلى ذلك، اسم الاختراق عبر npm قد نما، لذا قد يضر ببيانات المرء عند العمل في n8n. وتثبيت n8n على docker يتطلب معرفة تقنية لكن يمكن للمرء أن يتعلم، أنا شخصياً واجهت مشاكل عند تثبيت n8n على docker desktop لكنني حللتها خطوة بخطوة من خلال البحث على youtube والسؤال من الذكاء الاصطناعي الصيني Deepseek.
تشغيل n8n ذاتي الاستضافة لمنصة SaaS بأنماط متعددة - دعم كامل لـ Docker-first. كل شيء متعلق بإعداد multi-worker وqueue-mode يعمل بموثوقية أكبر عندما تكون نسخة n8n وبيئة التشغيل متسقة عبر حاويات main وworkers وwebhooks. عمليات التثبيت المستندة إلى npm تنجرف على مستوى نظام التشغيل المضيف وتسبب اختلافات دقيقة بين البيئات يصعب تصحيحها. متطلب sandbox مساعد الذكاء الاصطناعي هو ببساطة نقطة النهاية الطبيعية لاتجاه كان بالفعل القرار الصحيح لنشرات الإنتاج.
هذا خبر مخيب للآمال - أنا لست (حتى الآن خبيراً لكنني حاولت استخدام Docker وقد جعل جهازي متوقفاً تماماً (Windows 16Gb RAM مع تثبيت n8n محلياً). عندما قمت بإزالة Docker والعودة إلى استخدام NPM تمكنت من الالتفات للعمل الفعلي على n8n بدلاً من قضاء الوقت في الغوص في مشاكل استهلاك الموارد. نعم، يمكنني ترقية جهازي لكن بعض عملائي لديهم إعدادات أكثر بساطة وأحياناً أحتاج إلى العمل بما لدينا. من منظوري (وإن كان محدوداً)، يبدو أن استخدام Docker يضيف طبقة معقدة وغير ضرورية وتكاليف إضافية للحالات البسيطة. إذا كان يجب متابعة Docker لأسباب تقنية، هل يجب أن يكون متطلباً لموارد كثيرة؟
في رأيي، حتى المسؤولون غير التقنيين يمكنهم تثبيت Docker، وبفضل أدوات مثل Portainer، من السهل أيضاً إدارته. هذا يجعل من الأسهل على المبتدئين (مثلي) الذين لا يريدون حلاً قائماً على السحابة أن يبدأوا.
وجود خيارات متعددة غالباً ما يترك الكثير من الناس في حيرة عند اتخاذ قرار. أحياناً يكون من الجيد أن يتم اتخاذ القرار نيابة عنك (أشير هنا إلى المستخدمين الذين يريدون فقط تجربة التثبيت).
أنا متحمس لفكرة مساعد ذكي، وأنا متأكد من أنه سيساعد n8n على إحراز تقدم كبير.
أنا مؤيد للاتجاه الذي يقتصر على Docker فقط لمعظم المستخدمين، وصورة افتراضية منخفضة الموارد وقوية وغير جذرية تبدو معقولة. لكن لها خاصيتان تجعل من الصعب تشغيلها بشكل جيد على أجهزة NAS/الخادم المستقل (Unraid و Synology و…)، والانتقال إلى Docker فقط يحول هذه من “استخدم npm فقط” إلى عوائق حقيقية:
عدم وجود تعيين UID/GID المضيف. الصورة تعمل كمستخدم node ثابت (uid 1000)، لذا تنتهي المشاركات المثبتة بالربط بملكية UID/GID خاطئة على المضيف. الحل المعروف (صور LinuxServer.io والأصدقاء) هو البدء كجذر، تنفيذ إعداد التشغيل الأول، ثم الانخفاض إلى مستخدم تم إعادة تعيينه من PUID/PGID المقدم من المضيف - بحيث لا يؤدي الحاوية أبداً إلى إتلاف أذونات المشاركة.
عدم وجود مدير حزم (apk تم حذفه). تحتاج بعض تكاملات NAS إلى جذر + مدير حزم عند التشغيل الأول - على سبيل المثال، يستخدم تكامل Tailscale في Unraid خطاف يقوم بتثبيت وتكوين Tailscale عند بدء الحاوية، وهو أمر مستحيل بمجرد حذف apk/apt.
المهم هو أن (1) لا يمكن أن يكون مجرد علامة env على الصورة الحالية: إعادة تعيين UID (chown للبيانات المثبتة، usermod، الانخفاض عبر su-exec/gosu) تتطلب بشكل أساسي أن تبدأ الحاوية كجذر. هذا تغيير متعمد في الموقف من الافتراضي الصارم غير الجذري - وهذا هو بالضبط السبب في أعتقد أن هذا ينبغي أن يكون في صورة منفصلة بدلاً من إضعاف الافتراضي.
إذن: هل ستأخذ الفريق في الاعتبار تطوير صورة متغير موجهة للخادم المستقل/NAS - على سبيل المثال n8nio/n8n:<version>-nas - التي تبدأ كجذر، وتعيد تعيين PUID/PGID المضيف، وتنخفض امتيازات، وتحافظ على توفر مدير الحزم لخطافات التشغيل الأول؟ يبقى الافتراضي الصارم تماماً كما هو للجميع آخرين.
لا شكراً. انتقلت من Docker إلى bare metal. هناك الكثير من أوامر “docker says” الإضافية فقط لتنفيذ ما أحتاج إلى إنجازه. “لكن Docker أكثر أماناً بكثير!” كما لو أن المتسللين لا يعرفون أوامر Docker وكيفية التحايل على الأشياء… لا شكراً..
خبيراً لكنني حاولت استخدام Docker وقد جعل جهازي متوقفاً تماماً (Windows 16Gb RAM مع تثبيت n8n محلياً). عندما قمت بإزالة Docker والعودة إلى استخدام NPM تمكنت من الالتفات للعمل الفعلي على n8n بدلاً من قضاء الوقت في الغوص في مشاكل استهلاك الموارد. نعم، يمكنني ترقية جهازي لكن بعض عملائي لديهم إعدادات أكثر بساطة وأحياناً أحتاج إلى العمل بما لدينا. من منظوري (وإن كان محدوداً)، يبدو أن استخدام Docker يضيف طبقة معقدة وغير ضرورية وتكاليف إضافية للحالات البسيطة. إذا كان يجب متابعة Docker لأسباب تقنية، هل يجب أن يكون متطلباً لموارد كثيرة؟