أفضل بدائل n8n المستضافة ذاتياً: مقارنة عملية

ما الذي تستخدمه بدلاً من n8n

بدائل n8n المستضافة ذاتياً التي تستحق وقتك على VPS (خادم افتراضي خاص) هي Activepieces وWindmill وNode-RED وAutomatisch وHuginn. يُعد Activepieces البديل الأقرب إلى طريقة استخدام معظم الأشخاص لـn8n، كما أن نواته مرخّصة بموجب MIT. يناسب Windmill فريقاً يفضّل كتابة Python أو TypeScript بدلاً من سحب المربعات على لوحة. أما Node-RED فهو الخيار الأبسط، ولا يحتاج إلى قاعدة بيانات إطلاقاً.

ينبغي لكثير من القراء البقاء على n8n. تسمح رخصة n8n بالاستخدام الداخلي للأعمال، لذلك إذا كنت تشغّل التدفقات لصالح شركتك، فلن تكون الرخصة مشكلة بالنسبة إليك. كما أن الترحيل ليس مجانياً. لا يستطيع أي عنصر في هذه القائمة قراءة تصدير n8n، لذلك ستعيد إنشاء كل تدفق يدوياً، وستُدخل كل بيانات اعتماد من جديد. تثبيت n8n نفسه مهمة منفصلة، ويغطيها تثبيت n8n على VPS باستخدام Docker وHTTPS، بينما يوضح مقارنة n8n مع Zapier وMake كيفية مقارنة هذه الفئة بأكملها بالخدمات المستضافة.

لماذا يبحث الناس عن بدائل n8n المستضافة ذاتياً

يتكرر سببان باستمرار.

السبب الأول هو الترخيص. يُصدر n8n بموجب Sustainable Use License v1.0، ويصف المشروع هذا الترخيص بأنه fair-code وليس مفتوح المصدر. يمنح الترخيص الحق في «استخدام البرنامج أو تعديله لأغراض الأعمال الداخلية الخاصة بك فقط، أو للاستخدام غير التجاري أو الشخصي»، ويمنع توفير البرنامج لأشخاص آخرين لأغراض تجارية. تخضع الملفات والمجلدات التي تحتوي أسماؤها على .ee لـ n8n Enterprise License منفصل. إذا كنت تريد تشغيل عمليات تلقائية نيابةً عن عملاء يدفعون، فهذا مانع قاطع. أما إذا كنت تعمل ضمن فريق عمليات داخلي، فلن يغيّر ذلك شيئاً في عملك اليومي.

السبب الثاني هو الذاكرة. n8n عملية Node.js، وتبقى بيانات سير العمل في الذاكرة أثناء التنفيذ. توثيق n8n يذكر الأسباب: مقدار بيانات JSON، وحجم البيانات الثنائية، وعدد العقد في سير العمل، وعقدة Code، وعمليات التنفيذ اليدوية التي تنسخ البيانات مرة أخرى للمحرر، وسير العمل الأخرى التي تعمل في الوقت نفسه. الإصلاح الموثق ليس استخدام منتج مختلف. بل هو استخدام وضع queue مع عمليات worker منفصلة، إلى جانب Postgres بدلاً من ملف SQLite الافتراضي في ~/.n8n/database.sqlite. تحتاج المهام الكبيرة أيضاً إلى المعالجة على دفعات، لأن عقدة Loop Over Items التي تغذي سير عمل فرعياً تحتفظ بجزء واحد فقط من البيانات في الذاكرة في كل مرة. جرّب ذلك قبل إعادة بناء ستين سير عمل في مكان آخر.

ما بدائل n8n المستضافة ذاتياً التي لا تزال قيد الصيانة

من السهل قراءة نص الترخيص، لذلك يقارن الجميع التراخيص. لكن من السهل تجاهل حالة المشروع. هذه هي المشاريع البالغ عددها 6 في هذه المقارنة، مع أحدث إصدار موسوم لكل منها في 4 August 2026.

[
  {
    "tool": "n8n",
    "licence": "Sustainable Use License",
    "latest_release": "2.33.3",
    "released": "2026-07-31",
    "days_since_release": 4
  },
  {
    "tool": "Activepieces",
    "licence": "MIT core, commercial ee",
    "latest_release": "0.86.3",
    "released": "2026-07-17",
    "days_since_release": 18
  },
  {
    "tool": "Windmill",
    "licence": "AGPLv3 source, CE image",
    "latest_release": "v1.778.0",
    "released": "2026-08-04",
    "days_since_release": 0
  },
  {
    "tool": "Node-RED",
    "licence": "Apache 2.0",
    "latest_release": "5.0.4",
    "released": "2026-07-30",
    "days_since_release": 5
  },
  {
    "tool": "Automatisch",
    "licence": "AGPL-3.0, commercial ee",
    "latest_release": "v0.15.0",
    "released": "2025-08-08",
    "days_since_release": 361
  },
  {
    "tool": "Huginn",
    "licence": "MIT",
    "latest_release": "v2022.08.18",
    "released": "2022-08-18",
    "days_since_release": 1447
  }
]

يغيّر صفّان القائمة المختصرة. كان آخر إصدار موسوم لـAutomatisch هو v0.15.0، ويبلغ عمره 361 يوماً، كما لم يتضمن فرعه الافتراضي أي commit منذ 15 January 2026. أما Huginn، فقد وسم إصداراً قبل 1447 يوماً، لكن سجل commit الخاص به نشط هذا الشهر. هذا هو النمط المعاكس: يتغير الكود، لكن الإصدارات لا تصدر، لذلك يعني تشغيله تشغيل image غير موسومة بإصدار.

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

Activepieces: الخيار الأقرب، وMIT في صميمه

Activepieces هو الخيار المطابق تقريباً من حيث الوظائف. وهو أداة إنشاء مرئية تتضمن المشغلات والخطوات، وتسمّيها pieces، ويذكر ملف README وجود أكثر من 280 منها. كما يوفّر كل piece كخادم MCP (بروتوكول سياق النموذج)، لذلك يمكن لعميل LLM (نموذج لغوي كبير) استدعاء الموصلات نفسها بوصفها أدوات. النواة مرخّصة بموجب MIT. ويخضع الدليلان packages/ee/ وpackages/server/api/src/app/ee لترخيص تجاري، ويتطلب استخدام محتوياتهما على خادمك اتفاقية مدفوعة.

اقرأ تفاصيل هذا الفصل قبل الترحيل، لأن نطاقه أوسع مما هو معتاد في معظم مشاريع MIT. تصف صفحة تسعير Activepieces إصدار Community Edition بأنه «مفتوح المصدر، ومجاني إلى الأبد، ومن دون حد لعدد عمليات التشغيل أو المستخدمين أو التدفقات»، وتضع Agents وChat وProjects والوصول إلى API وطبقة الإدارة بأكملها خارج هذا الإصدار، بما في ذلك تسجيل الدخول الموحّد وأدوار المستخدمين وسجلات التدقيق ومديري الأسرار والعلامة التجارية ومزامنة Git. لذلك فإن Community Edition هو محرك أتمتة كامل يوفّر تدفقات ومستخدمين غير محدودين، لكنه ليس منصة يمكنك تشغيلها عبر API. إذا كانت خطتك هي إنشاء التدفقات برمجياً، فهذه الخطة تتطلب ترخيصاً.

يتكوّن شكل التشغيل من حاوية تطبيق واحدة، وحاوية عامل واحدة أو أكثر، وPostgres وRedis. ويُعد AP_DB_TYPE=POSTGRES وAP_REDIS_TYPE=STANDALONE الإعدادين الافتراضيين. ويتوفر وضع الحاوية الواحدة مع قاعدة بيانات مضمّنة وطابور داخل العملية (AP_DB_TYPE=PGLITE مع AP_REDIS_TYPE=MEMORY)، وتذكر الوثائق أنه «مخصّص للاستخدام الشخصي أو للاختبار فقط». تعامل مع ذلك على أنه قيد فعلي. لا يمكن لهذه الأوضاع تشغيل أكثر من نسخة واحدة، لذا فإن تجاوزها مع نمو الاستخدام هو عملية ترحيل، وليس مجرد تغيير flag.

Windmill: البرمجة أولاً، لكنه أثقل مما يبدو

يشغّل Windmill البرامج النصية المكتوبة بـPython وTypeScript وGo وBash وSQL، ثم يركّبها في تدفقات. إذا كانت عمليات الأتمتة لديك تتكوّن أساساً من التعليمات البرمجية مع قدر صغير من الربط بينها، فسيكون أنسب من أي لوحة تعتمد على العقد.

يتطلب الترخيص عناية. تكون الشيفرة المصدرية مرخّصة بموجب AGPLv3 عند الترجمة من دون تفعيل علامة ميزات المؤسسات. الصور المنشورة في ghcr.io/windmill-labs/windmill هي Community Edition، وتتضمن شيفرة ليست مفتوحة المصدر، ويُسمح باستخدامها مجاناً ضمن الحصص. تحدد صفحة أسعار Windmill هذه الحصص بـ50 مستخدماً، و3 مساحات عمل، و10 GiB من تخزين كائنات مساحة العمل، مع عمليات تنفيذ غير محدودة. بالنسبة إلى شخص واحد أو فريق صغير واحد، من غير المرجح بلوغ هذا الحد قريباً، لذا فالسؤال العملي لا يتعلق بالحصّة. بل يتعلق بأن الملف الثنائي الذي تشغّله ليس إصدار AGPL.

الحجم عامل آخر يجب أخذه في الاعتبار. يوفّر docker-compose.yml الرسمي من Windmill قاعدة بيانات Postgres 16، وخادماً واحداً، وثلاثة عمال افتراضيين بحد ذاكرة قدره 2048M لكل واحد منهم، وعاملاً أصلياً ووكيل Caddy. والقاعدة التقريبية الموثقة هي: "عامل واحد لكل 1vCPU و1-2 GB من RAM". يمكنك تقليل عدد النسخ في خادم صغير. لكن يجب أن تعرف أنك تقلله، لأن العمال هم الذين ينفذون مهامك فعلياً.

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

Node-RED: الخيار الصغير، من دون قاعدة بيانات إطلاقاً

يستخدم Node-RED ترخيص Apache 2.0، وهو الترخيص الأكثر تساهلاً في هذه المقارنة. وهو عبارة عن عملية Node.js واحدة مع وحدة تخزين /data. لا توجد Postgres. ولا Redis. ثبّته على الإصدار nodered/node-red:5.0.4، فهو الإصدار الحالي.

نشأ Node-RED من توصيلات إنترنت الأشياء، لذلك يعتمد على الأحداث بدلاً من الموصلات. تأتي عقد الخدمات التابعة لجهات خارجية من مكتبة المجتمع، وتختلف جودتها. وهذا هو المقابل للحجم الصغير. لا توجد خطوة مدمجة من الدرجة الأولى لوكيل ذكاء اصطناعي. بالنسبة إلى VPS صغير يعالج webhooks وحركة مرور قوائم انتظار الرسائل، فهو أخف خيار هنا ويعمل، ويبدأ خلال ثوانٍ.

Huginn وAutomatisch: افحص سجل الالتزامات أولاً

Huginn مرخّص بموجب MIT، ومكتوب بلغة Ruby on Rails، ويحتاج إلى MySQL أو PostgreSQL. يعتمد على وكلاء يراقبون مصدراً ويصدرون أحداثاً. وهذا نموذج مختلف عن لوحة التدفقات، كما أنه لا يوفّر دعماً لنماذج LLM. لا يزال المستودع يتلقى التزامات، لكن آخر إصدار موسوم يعود إلى August 2022. لذلك يعني تشغيله استخدام صورة ghcr.io/huginn/huginn المبنية من الفرع الافتراضي. اختره عندما يناسب نموذج الوكلاء المشكلة التي تريد حلها، وليس بديلاً عاماً لـn8n.

Automatisch مرخّص بموجب AGPL-3.0 باستثناء ملفاته .ee، ويبدو كإصدار أبسط من n8n: Postgres وRedis وكتالوج صغير من التطبيقات. وهو الأداة التي تستمر البرامج التعليمية الخاصة بالنشر الفردي في التوصية بها. لكن سجل الإصدارات يشير إلى ضرورة الانتظار. عدم صدور إصدار لمدة عام وعدم تسجيل أي التزام لمدة نصف عام ليسا سبباً للقلق إذا كنت تشغّله بالفعل، لكنه سبب لعدم بدء نشر إنتاجي جديد عليه.

ما التكلفة الفعلية لمكدس Activepieces من ذاكرة RAM

لا يمكن لأي جهة نشر رقم ثابت للذاكرة المستخدمة في وضع الخمول وأثناء التشغيل، لأن ذلك يعتمد على التدفقات الخاصة بك وكمية البيانات التي تعالجها. لكن يمكنك قراءة الموارد التي يطلب منك كل مورّد تخصيصها. توثّق Activepieces البنية أدناه، والجملة المرافقة لها أهم من الأرقام: "يظل العامل ذو التزامن 1 مشغولاً طوال مدة التدفق (حتى 10 min)، لذا احسب الحجم وفقاً لعدد التدفقات المتزامنة، لا وفقاً لمعدل التشغيل."

[
  {
    "label": "App container",
    "vcpu": 1,
    "ram_gb": 1
  },
  {
    "label": "Worker (each)",
    "vcpu": 0.5,
    "ram_gb": 1
  },
  {
    "label": "Postgres",
    "vcpu": 2,
    "ram_gb": 4
  },
  {
    "label": "Redis",
    "vcpu": 1,
    "ram_gb": 1
  }
]

يحتاج العامل الواحد إلى 0.5 vCPU و1 GB، ويشغّل تدفقاً واحداً فقط في كل مرة. ويُخصَّص لـPostgres مقدار 4 GB. يحتوي ملف compose الخاص بالمشروع على خمس نسخ من العامل، لذلك يطلب المكدس في المستودع، وفق هذا التخصيص، نحو 11 GB قبل أن تنفّذ تدفقاتك أي عمل مهم. تنسخ البرامج التعليمية التي تستخدم أداة واحدة هذا الملف وتصف النشر بأنه صغير.

على VPS بسعة 4 GB، شغّل عاملين، وأبقِ Postgres في مشروع compose نفسه، ثم قِس الاستخدام. يطبع docker stats --no-stream سطراً واحداً لكل حاوية، يتضمن الذاكرة المقيمة الفعلية التي تستخدمها، وهذا أدق من أي رقم ينشره مورّد أو مدونة. إذا زاد استهلاك حاوية دون حد، فضع له حداً، ويعرض حدود الذاكرة في Docker Compose البنية المطلوبة لذلك.

ملف Compose لـActivepieces على VPS واحد

ثبّت الوسم. يتيح latest للعنصر التالي docker compose pull تغيير مخطط قاعدة البيانات تلقائياً ومن دون تحذير. الإصدار 0.86.3 هو الإصدار الذي يثبّته المشروع في ملف Compose الخاص به حتى 4 August 2026.

أنشئ السريَّن أولاً، باستخدام الأطوال التي تحددها الوثائق.

openssl rand -hex 16    # AP_ENCRYPTION_KEY, encrypts stored connections
openssl rand -hex 32    # AP_JWT_SECRET, signs session tokens

اكتب .env بجانب ملف Compose:

AP_ENGINE_EXECUTABLE_PATH=dist/packages/engine/main.js
AP_ENVIRONMENT=prod
AP_FRONTEND_URL=https://automation.example.com
AP_ENCRYPTION_KEY=REPLACE_WITH_HEX_16
AP_JWT_SECRET=REPLACE_WITH_HEX_32
AP_DB_TYPE=POSTGRES
AP_POSTGRES_DATABASE=activepieces
AP_POSTGRES_HOST=postgres
AP_POSTGRES_PORT=5432
AP_POSTGRES_USERNAME=postgres
AP_POSTGRES_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_PASSWORD
AP_REDIS_TYPE=STANDALONE
AP_REDIS_HOST=redis
AP_REDIS_PORT=6379
AP_EXECUTION_MODE=UNSANDBOXED
AP_TELEMETRY_ENABLED=false

يجب أن تكون قيمة AP_FRONTEND_URL هي عنوان HTTPS العام، لأن Activepieces يحاول خلاف ذلك استخدام عنوان IP العام عند إنشاء عناوين URL الخاصة بـwebhook. يُنشأ كل webhook تسلّمه إلى جهة خارجية من هذه القيمة. لذلك، إذا ظلّت تشير إلى localhost، فلن يصل عنوان URL الذي تلصقه في خدمة أخرى إلى خادمك.

services:
  app:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - postgres
      - redis
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=APP
    volumes:
      - ./cache:/usr/src/app/cache
  worker:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    depends_on:
      - app
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=WORKER
    deploy:
      replicas: 2
    volumes:
      - ./cache:/usr/src/app/cache
  postgres:
    image: pgvector/pgvector:0.8.0-pg14
    restart: unless-stopped
    env_file: .env
    environment:
      - POSTGRES_DB=${AP_POSTGRES_DATABASE}
      - POSTGRES_USER=${AP_POSTGRES_USERNAME}
      - POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
  redis:
    image: redis:7.0.7
    restart: unless-stopped
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

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

docker compose up -d
docker compose ps

يجب أن تعرض كل خدمة Up، بما في ذلك حاويتا worker. تطبع الحاوية التي تعيد التشغيل في حلقة سبب ذلك في docker compose logs worker، لذا اقرأه قبل تغيير أي شيء. يعني ربط المنفذ أن الاتصالات الخارجية لا تصل إلى التطبيق قبل وضع Reverse Proxy مع TLS (أمن طبقة النقل) أمامه. يشرح تشغيل Traefik أمام عدة تطبيقات Compose ذلك. أبقِ .env بالوضع 600 وخارجه من git، كما هو موضح في التعامل مع الأسرار في ملفات env الخاصة بـCompose.

النسخة الاحتياطية التي يغفل عنها كل دليل

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

تُعد n8n أوضح مثال على ذلك. إذا لم تضبط N8N_ENCRYPTION_KEY مطلقاً، فإن n8n «ينشئ مفتاح تشفير عشوائياً تلقائياً عند التشغيل الأول ويحفظه في مجلد ~/.n8n»، ثم يستخدم هذا المفتاح لتشفير بيانات الاعتماد قبل وصولها إلى قاعدة البيانات. إذا فرّغت Postgres ثم استعدتها إلى حاوية جديدة ذات volume جديد، فستعود مسارات العمل، بينما تصبح كل بيانات الاعتماد نصاً مشفراً لا يستطيع أحد قراءته. اضبط المتغير صراحةً، واستخدم القيمة نفسها على كل worker عند تشغيل queue mode.

يتبع Node-RED النمط نفسه. تُخزّن بيانات الاعتماد في ملف مشفّر مستقل، ويكون المفتاح في credentialSecret داخل settings.js. عندما لا تضبط مفتاحاً، ينشئ runtime مفتاحاً عشوائياً ويحفظه ضمن _credentialSecret في مخزن الإعدادات الخاص به داخل /data. يوضح ملف الإعدادات الافتراضي النتيجة: «بمجرد ضبط هذه الخاصية، لا تغيّرها؛ لأن ذلك سيمنع node-red من فك تشفير بيانات الاعتماد الحالية، وستُفقد هذه البيانات». أنشئ نسخة احتياطية من volume /data بأكمله، وليس من ملف flows فقط.

يحتفظ Activepieces بـAP_ENCRYPTION_KEY في .env لديك، وقد وُثّق بأنه «مفتاح سداسي عشري مكوّن من 32 محرفاً (16 بايت) يُستخدم لتشفير الاتصالات». ويحتفظ Huginn بـAPP_SECRET_TOKEN في بيئته. أما Automatisch فلديه ثلاثة مفاتيح: ENCRYPTION_KEY وWEBHOOK_SECRET_KEY وAPP_SECRET_KEY. في كل حالة، يكون السر في ملف بيئة، ولذلك يُعد ملف البيئة جزءاً من النسخة الاحتياطية.

يُعد Windmill استثناءً مهماً. تُشفّر متغيراته وأسراره باستخدام مفتاح متماثل خاص بمساحة العمل، ويخزّن Windmill هذا المفتاح في قاعدة بياناته الخاصة، لذلك يحتوي تفريغ Postgres واحد على كلا الجزأين. هذا يسهّل الاستعادة، لكنه يعني أن التفريغ وحده يكفي لقراءة كل سر، لذا احمِ الملف كما تحمي الأسرار نفسها.

بالنسبة إلى مكدس Activepieces السابق، تتكوّن النسخة الاحتياطية من ملفين:

cd /srv/activepieces
docker compose exec -T postgres pg_dump -U postgres -Fc activepieces > "ap-$(date +%F).dump"
cp .env "ap-env-$(date +%F).bak"
chmod 600 ap-*.dump ap-env-*.bak

بعد ذلك، أثبت أن النسخة الاحتياطية تعمل، لأن النسخة غير المختبرة مجرد تخمين. استعد التفريغ إلى مشروع compose تجريبي يستخدم AP_ENCRYPTION_KEY مختلفاً عمداً، ثم شغّل مساراً يستخدم اتصالاً محفوظاً. سيفشل، لأن النص المشفّر في قاعدة البيانات أُنشئ باستخدام المفتاح الآخر. كرر الاستعادة باستخدام المفتاح الحقيقي من .env، وسيعمل المسار نفسه. هاتان التجربتان هما الدليل الوحيد على أن نسختك الاحتياطية صالحة. انقل الملفين خارج الخادم وفق جدول زمني باستخدام نسخ restic الاحتياطية من VPS، لأن النسخة الاحتياطية الموجودة على القرص نفسه ستتلف مع القرص.

متى تبقى على n8n

ابقَ على n8n إذا كان العمل داخلياً في شركتك، لأن ذلك يطابق تماماً ما تسمح به Sustainable Use License. ابقَ عليه إذا كنت تعتمد على اتساع نطاق التكاملات، إذ يذكر n8n أنه يوفّر أكثر من 1500 تكامل، أو إذا كنت تعتمد على عقدة AI Agent المبنية على LangChain، والتي لا يضاهيها أي خيار آخر هنا من حيث خطوات الوكلاء الجاهزة. يوضّح تشغيل تدفقات n8n باستخدام Claude كيف يبدو ذلك عملياً.

انتقل إلى Activepieces إذا أردت ترخيصاً متساهلاً لنواة الأتمتة ومكدساً يمكنك قراءة مكوناته من البداية إلى النهاية. انتقل إلى Windmill إذا كانت تدفقاتك في الواقع تعليمات برمجية بواجهة مستخدم. انتقل إلى Node-RED إذا كان الخادم صغيراً وكان العمل قائماً على الأحداث. لا تنتقل لأن اختباراً معيارياً أخبرك بأن n8n يستهلك موارد كثيرة. قِس مثيلك أولاً، ثم اقرأ ما يستحق الاستضافة الذاتية في 2026 واختر مرة واحدة، لأن عملية الترحيل الثانية تكلّف بقدر الأولى.

FAQ

ما البديل المستضاف ذاتياً لـ n8n الأقرب إلى n8n؟

Activepieces. الفكرة نفسها: منشئ مرئي يبدأ فيه trigger تدفقاً، وتستدعي كل خطوة خدمة، مع فهرس كبير من الموصلات. نواته مرخّصة بموجب MIT، ويعمل على Postgres وRedis ضمن Docker، كما تعمل pieces فيه كخوادم MCP لعملاء LLM. النقطة التي يجب الانتباه إليها هي أن الوصول إلى API وميزات الوكلاء موجودان ضمن دلائل المؤسسات التجارية، لذلك تُدار نسخة Community Edition عبر واجهة الويب بدلاً من إدارتها برمجياً.

هل Activepieces مفتوح المصدر فعلاً؟

النواة مفتوحة المصدر بموجب ترخيص MIT. الدليلان packages/ee/ وpackages/server/api/src/app/ee مرخّصان تجارياً، ويتطلب استخدام هذه الميزات على خادمك ترخيصاً مدفوعاً. تعرض صفحة أسعار المورّد Agents وChat والوصول إلى API وتسجيل الدخول الموحّد وأدوار المستخدمين وسجلات التدقيق ومديري الأسرار والعلامة التجارية ومزامنة Git خارج Community Edition، بينما تبقى عمليات التشغيل والمستخدمون والتدفقات بلا حدود. لذلك فهو مفتوح المصدر فعلاً لبناء عمليات التشغيل الآلية وتشغيلها، لكنه ليس مفتوح المصدر لطبقة الفريق والحوكمة.

ما مقدار RAM الذي يحتاج إليه Activepieces على VPS؟

يوثّق Activepieces مقدار 0.5 vCPU و1 GB لكل worker، و1 vCPU و1 GB لحاوية التطبيق، و4 GB لـ Postgres و1 GB لـ Redis. يعالج worker تدفقاً واحداً في كل مرة طوال مدة ذلك التدفق، لذلك احسب الموارد وفقاً لعدد التدفقات المتزامنة الأقصى، لا وفقاً لعدد مرات تشغيل triggers. يتضمن ملف compose في المستودع خمسة workers، أي ما يقارب 11 GB وفقاً للأحجام المنشورة. يُعد تشغيل workerين على VPS بسعة 4 GB بداية معقولة، ويؤكد docker stats --no-stream العدد الفعلي لتدفقاتك أثناء تشغيلها.

ما الذي يجب أن أنسخه احتياطياً حتى تنجح الاستعادة فعلياً؟

نسخة قاعدة البيانات ومفتاح التشفير معاً. في Activepieces، هذا يعني pg_dump من قاعدة بيانات activepieces، إضافة إلى ملف .env الذي يحتوي على AP_ENCRYPTION_KEY. أما في n8n، فانسخ قاعدة البيانات وN8N_ENCRYPTION_KEY احتياطياً؛ إذ ينشئ n8n هذا الملف داخل مجلد ~/.n8n إذا لم تضبطه بنفسك. وبالنسبة إلى Node-RED، انسخ كامل وحدة التخزين /data، لأن ملف بيانات الاعتماد والمفتاح الذي يفك تشفيره موجودان فيها معاً. Windmill هو الاستثناء: يوجد مفتاح مساحة العمل داخل قاعدة بيانات Postgres الخاصة به، لذلك تتضمن النسخة كل شيء، ويجب حمايتها كما تحمي الأسرار نفسها.

هل يمكنني استيراد تدفقات n8n إلى أداة أخرى؟

لا. تستورد هذه المشاريع تنسيقات التدفقات الخاصة بها وتصدّرها، وليس تنسيق n8n. تتطلب عملية النقل إعادة بناء كل تدفق في المنشئ الجديد، وإنشاء كل بيانات اعتماد مرة أخرى من الخدمة الأصلية. هذا العمل هو التكلفة الفعلية للانتقال، لذلك أحصِ تدفقاتك قبل اتخاذ القرار. إعادة بناء 12 تدفقاً تستغرق فترة بعد الظهر. أما 200 تدفق فهي مشروع كامل، وغالباً ما يكون إصلاح استهلاك n8n للذاكرة باستخدام queue mode وPostgres أرخص من إعادة بنائها جميعاً.