ما الذي يتغير مع n8n 3.0 ولماذا يجب التصرف الآن
توثيق التغييرات الجذرية الرسمي لـ n8n 3.0 لا يترك مجالًا للشك: «سيتطلب n8n المستضاف ذاتيًا نشرًا قائمًا على Docker. لن يدعم n8n 3.0 بعد الآن التثبيت عبر npm أو npx n8n.» هذا ليس تحذير إيقاف تدريجي — بل موعد نهائي صارم. في أكتوبر 2026، لن يمكن تحديث أي تطبيق يعمل عبر npx n8n أو حزمة npm عامة، وسيتجمد على آخر إصدار من السلسلة 2.x دون تصحيحات أمنية.
مخاطر تأجيل الترحيل إلى أكتوبر
- ترحيل تحت الضغط — الترحيل في حالة طوارئ بينما تعمل أتمتة حرجة يعرّضك لأخطاء إعداد يصعب تشخيصها.
- فقدان بيانات SQLite — توثق المشكلة رقم #22341 على GitHub حالات حدثت فيها انتكاسة في قاعدة البيانات عند تحديث حاويات Docker دون احتياطات: تعود سير العمل والتنفيذات إلى حالة نسخة احتياطية قديمة.
- غياب التصحيحات الأمنية — تطبيق npm المجمَّد على الإصدار 2.x لا يتلقى تصحيحات الأمان ولا إصلاحات الاستقرار.
- تراكم التعارضات — عمليات التكامل والعقد المجتمعية والـ webhooks تعتمد على واجهات برمجية تتطور مع الوقت.
- مدة غير متوقعة — ترحيل مُعدّ له يستغرق ساعة واحدة؛ ترحيل مرتجل قد يستغرق يومًا كاملًا تتوقف خلاله سير عملك.
المتطلبات الأساسية قبل البدء
هذه الإجراءات مخصصة لتطبيق n8n قائم في الإنتاج. إذا كنت تبدأ من الصفر، راجع المقال المخصص لتثبيت n8n على VPS.
ما تحتاجه
- VPS بصلاحية root — يُنصح بـ Ubuntu 22.04 أو Debian 12، بحد أدنى 2 vCPU و2 GB RAM لـ n8n وحده، و4 GB إذا أضفت PostgreSQL على الخادم نفسه.
- Docker Engine وDocker Compose v2 — تحقق بـ
docker --version وdocker compose version (صيغة بدون شرطة، الإضافة v2). - يُوصى بـ PostgreSQL — n8n يدعم SQLite وPostgreSQL، لكن SQLite على Docker ينطوي على مخاطر فقدان البيانات (راجع المشكلة #22341).
- الوصول إلى تطبيق npm الحالي — يتطلب الترحيل تصدير سير العمل عبر REST API قبل إيقاف التطبيق القديم.
- اسم نطاق وشهادة TLS —
your-domain.com مع Let's Encrypt عبر Nginx كـ reverse proxy. - نافذة صيانة مجدولة — حتى قصيرة، تتجنب فقدان التنفيذات الجارية.
اكتشاف وضع التشغيل الحالي
قبل أي شيء، حدد بدقة كيف يُشغَّل تطبيق n8n لديك. الأمر المستخدم يعتمد على طريقة الإشراف.
اكتشف وصدِّر وانشر وتحقق
تحديد عملية n8n
ابحث عن الملف القابل للتنفيذ الجاري: which n8n يُظهر المسار إذا كان n8n مثبتًا عالميًا عبر npm. ثم تحقق من وجود خدمة نظام: systemctl status n8n. إذا لم توجد خدمة systemd، ابحث عن عملية نشطة: ps aux | grep n8n. نتيجة تحتوي على npx n8n تؤكد التثبيت عبر npm.
تحديد ملف الإعداد وقاعدة البيانات
مجلد البيانات الافتراضي هو ~/.n8n/. تحقق من محتواه: ls -la ~/.n8n/. وجود database.sqlite يشير إلى قاعدة بيانات SQLite. دوِّن المسار الكامل — ستحتاجه للتصدير.
تصدير جميع سير العمل عبر REST API
احصل أولًا على مفتاح API من الواجهة (Settings → API → Create API Key)، ثم صدِّر: curl -s -H 'X-N8N-API-KEY: YOUR_KEY' http://localhost:5678/api/v1/workflows | python3 -m json.tool > workflows-export-$(date +%Y%m%d).json. تحقق من أن الملف يحتوي على سير عملك قبل أي عملية.
إيقاف تطبيق npm بشكل صحيح
إذا كانت الخدمة مُشرفة عبر systemd: systemctl stop n8n && systemctl disable n8n. إذا كانت مُشغَّلة يدويًا، حدد الـ PID بـ pgrep -f n8n ثم kill -SIGTERM <PID>. انتظر بضع ثوانٍ لإتمام التنفيذات الجارية.
إنشاء ملف docker-compose.yml مع PostgreSQL
أنشئ مجلدًا مخصصًا: mkdir -p /opt/n8n && cd /opt/n8n. ثم أنشئ ملف docker-compose.yml بالمحتوى الكامل المذكور في النسخة الفرنسية مع تعديل كلمات المرور واستخدام your-domain.com. الإصدار مثبت على n8nio/n8n:2.38.4 (مستقر في 2026-09-09).
تشغيل المنظومة واستيراد سير العمل
شغِّل المنظومة: docker compose up -d. انتظر حتى تعمل الحاويتان بشكل سليم: docker compose ps. بمجرد وصول n8n على http://127.0.0.1:5678، استورد سير العمل عبر API وتحقق من وجودها في الواجهة.
ضبط Nginx كـ reverse proxy مع TLS
ثبِّت Nginx وCertbot: apt install nginx certbot python3-certbot-nginx -y. أنشئ إعداد Nginx بـ proxy_pass إلى http://127.0.0.1:5678 مع رؤوس WebSocket وmهلة قراءة 300 ثانية. فعِّل الموقع واحصل على الشهادة: certbot --nginx -d your-domain.com.
التحقق من نجاح الترحيل
نفِّذ هذه الفحوصات بالترتيب: 1) الوصول إلى https://your-domain.com — تظهر صفحة تسجيل الدخول بدون تحذير TLS؛ 2) تحقق من وجود سير عملك وتفعيلها؛ 3) شغِّل سير عمل بسيطًا يدويًا؛ 4) حدِّث الـ webhooks إذا كانت الخدمات الخارجية تشير إلى العنوان القديم؛ 5) راجع السجلات بعد 24 ساعة: docker compose logs n8n --since 24h | grep -i error.
دائمًا حدد إصدارًا، ولا تستخدم :latest
استخدام n8nio/n8n:latest يعرّضك لتحديثات تلقائية غير متحكم بها عند docker compose pull. على قاعدة SQLite، قفزة إصدار رئيسية دون ترحيل مسبق قد تُطلق السيناريو الموصوف في المشكلة #22341. دائمًا ثبِّت إصدارًا محددًا وخطط لترقياتك. للانتقال إلى إصدار جديد: docker compose pull && docker compose up -d.
استكشاف الأخطاء: الحالات الشائعة بعد الترحيل
إليك المشكلات الأكثر شيوعًا خلال هذا الانتقال.
المشكلات والحلول
- سير العمل فارغة بعد الاستيراد — تحقق من أن تنسيق JSON المُصدَّر يتوافق مع ما تتوقعه API الاستيراد؛ بعض إصدارات n8n تُصدِّر كائن
{ data: [] } وبعضها مصفوفة مباشرة. - الـ webhooks لا تستجيب — يجب أن يتطابق
WEBHOOK_URL تمامًا مع عنوان URL العام للتطبيق (بما فيه https://). - بيانات الاعتماد غير قابلة للوصول — بيانات الاعتماد مشفرة بمفتاح
N8N_ENCRYPTION_KEY. استرجعه من ~/.n8n/.n8n_encryption_key على التطبيق القديم وضعه كمتغير بيئة. - انتكاسة قاعدة SQLite (المشكلة #22341) — إذا احتفظت بـ SQLite مؤقتًا، تأكد من تثبيت حجم Docker بشكل دائم. الترحيل إلى PostgreSQL يظل الحل النهائي.
- خطأ
ECONNREFUSEDمع PostgreSQL — الشرط depends_on.postgres.condition: service_healthy وفحص الصحة pg_isready يضمنان انتظار n8n حتى يكون PostgreSQL جاهزًا.
ترحيل يجب إتمامه الآن، لا في أكتوبر
الإصدار المستقر من n8n وقت كتابة هذا المقال هو 2.38.4. لديك أسابيع لإجراء هذا الترحيل في ظروف مثالية: تصدير سير عملك بشكل صحيح، واختبار منظومة Docker على خادم اختباري، ثم التبديل في الإنتاج مع خطة تراجع حقيقية. في أكتوبر، عند توفر n8n 3.0، لن تحتاج إلا لتغيير رقم الإصدار في docker-compose.yml — خمس دقائق. الفرق بين خمس دقائق ويوم كامل من الضغط يبدأ الآن.
