بهترین جایگزین‌های self-hosted برای n8n

جایگزین‌های n8n

جایگزین‌های self-hosted برای n8n که ارزش نصب روی یک VPS (سرور مجازی) را دارند، عبارتند از Activepieces، Windmill، Node-RED، Automatisch و Huginn. ابزار Activepieces نزدیک‌ترین جایگزین برای نحوه استفاده اکثر کاربران از n8n است و هسته آن تحت مجوز MIT ارائه می‌شود. ابزار Windmill برای تیم‌هایی مناسب است که ترجیح می‌دهند به‌جای کشیدن و رها کردن بلوک‌ها در یک محیط گرافیکی، کد Python یا TypeScript بنویسند. ابزار Node-RED سبک‌تر است و اصلاً نیازی به دیتابیس ندارد.

بسیاری از کاربران باید در همان پلتفرم فعلی خود باقی بمانند. مجوز n8n اجازه استفاده داخلی در کسب‌وکار را می‌دهد، بنابراین اگر جریان‌های کاری (flows) را برای شرکت خود اجرا می‌کنید، مجوز مشکلی برای شما ایجاد نمی‌کند. مهاجرت نیز هزینه‌بر است. هیچ‌کدام از ابزارهای این لیست قابلیت خواندن خروجی‌های n8n را ندارند، بنابراین باید تمام جریان‌های کاری را به‌صورت دستی بازسازی کرده و تمام اطلاعات احراز هویت را دوباره وارد کنید. نصب خودِ n8n یک کار مجزا است که در نصب n8n روی VPS با Docker و HTTPS پوشش داده شده است و مقایسه n8n با Zapier و Make توضیح می‌دهد که این دسته از ابزارها چگونه با سرویس‌های میزبانی‌شده (hosted) مقایسه می‌شوند.

چرا افراد به دنبال جایگزین‌های self-hosted برای n8n هستند

دو دلیل همواره تکرار می‌شوند.

دلیل اول مجوز (licence) است. n8n تحت مجوز Sustainable Use License v1.0 عرضه می‌شود که پروژه آن را به جای متن‌باز (open source)، «کد منصفانه» (fair-code) می‌نامد. این مجوز حق «استفاده یا تغییر نرم‌افزار صرفاً برای مقاصد تجاری داخلی یا استفاده غیرتجاری و شخصی» را اعطا می‌کند و ارائه تجاری نرم‌افزار به دیگران را ممنوع می‌سازد. فایل‌ها و پوشه‌هایی که در نام خود .ee دارند، تحت مجوز جداگانه n8n Enterprise قرار می‌گیرند. اگر قصد دارید اتوماسیون‌ها را به نمایندگی از مشتریان پرداخت‌کننده اجرا کنید، این یک مانع جدی است. اگر یک تیم عملیاتی داخلی هستید، این موضوع هیچ تغییری در کار روزمره شما ایجاد نمی‌کند.

دلیل دوم حافظه (memory) است. n8n یک پردازش Node.js است و داده‌های workflow در حین اجرا در حافظه قرار می‌گیرند. مستندات n8n دلایل این موضوع را ذکر کرده‌اند: حجم داده‌های JSON، اندازه داده‌های باینری، تعداد نودها در یک workflow، نود Code، اجرای دستی (که داده‌ها را دوباره برای ویرایشگر کپی می‌کند) و سایر workflowهایی که همزمان در حال اجرا هستند. راه‌حل مستندشده، استفاده از محصولی متفاوت نیست. راه‌حل، استفاده از حالت queue با پردازش‌های worker مجزا، به علاوه استفاده از Postgres به جای فایل پیش‌فرض SQLite در مسیر ~/.n8n/database.sqlite است. برای کارهای سنگین، استفاده از batching نیز توصیه می‌شود، زیرا یک نود Loop Over Items که به یک sub-workflow داده می‌فرستد، در هر لحظه فقط یک بخش از داده‌ها را در حافظه نگه می‌دارد. پیش از آنکه 60 فلو را در جای دیگری بازسازی کنید، این روش را امتحان کنید.

کدام جایگزین‌های self-hosted برای 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 روز از آن می‌گذرد و شاخه پیش‌فرض آن از تاریخ 15 January 2026 هیچ commit جدیدی نداشته است. پروژه Huginn آخرین نسخه خود را 1447 روز پیش تگ کرده است، با این حال لاگ commit آن در ماه جاری فعال است. این الگویی معکوس است: کد در حال تغییر است اما نسخه‌ای منتشر نمی‌شود؛ بنابراین اجرای آن به معنای استفاده از یک image بدون تگ است.

پیش از آنکه به هر مقایسه‌ای، از جمله این مورد، اعتماد کنید، خودتان آن را بررسی کنید. صفحه releases پروژه را در GitHub باز کنید و سپس لیست commitهای شاخه پیش‌فرض آن را چک کنید. پروژه‌ای با نسخه جدید و لاگ commit ساکت، در حال درجا زدن است. پروژه‌ای با commitهای تازه و بدون انتشار نسخه در سال‌های اخیر، از شما می‌خواهد کدی را اجرا کنید که هیچ‌کس برای آن نسخه‌ای نهایی (cut) نکرده است.

Activepieces: نزدیک‌ترین گزینه و دارای هسته MIT

Activepieces انتخاب مشابه و جایگزین مستقیم است. این ابزار یک سازنده بصری با تریگرها و مراحل مختلف است که آن‌ها را pieces می‌نامد و فایل README ادعا می‌کند بیش از 280 مورد از آن‌ها وجود دارد. هر piece همچنین به عنوان یک سرور MCP (پروتکل زمینه مدل) در دسترس است، بنابراین یک کلاینت LLM (مدل زبانی بزرگ) می‌تواند از همان کانکتورها به عنوان ابزار استفاده کند. هسته این پروژه تحت مجوز MIT است. دو دایرکتوری packages/ee/ و packages/server/api/src/app/ee دارای مجوز تجاری هستند و استفاده از محتویات آن‌ها روی سرور شخصی شما نیازمند یک توافق‌نامه پولی است.

پیش از مهاجرت، این تفکیک را مطالعه کنید، زیرا دامنه آن از اکثر پروژه‌های MIT گسترده‌تر است. صفحه قیمت‌گذاری Activepieces نسخه Community Edition را به عنوان «متن‌باز، رایگان برای همیشه، بدون محدودیت در اجرا، کاربر یا جریان‌ها» توصیف می‌کند و قابلیت‌هایی مانند Agents and Chat، پروژه‌ها، دسترسی API و کل لایه مدیریتی (ورود یکپارچه، نقش‌های کاربری، لاگ‌های حسابرسی، مدیریت اسرار، برندینگ، همگام‌سازی با Git) را خارج از آن قرار می‌دهد. بنابراین، نسخه Community Edition یک موتور اتوماسیون کامل با جریان‌ها و کاربران نامحدود است، اما پلتفرمی نیست که بتوانید آن را از طریق API کنترل کنید. اگر برنامه شما تولید برنامه‌نویسی‌شده جریان‌ها بوده است، آن برنامه نیازمند مجوز است.

ساختار زمان اجرا شامل یک کانتینر برنامه، یک یا چند کانتینر worker، دیتابیس Postgres و Redis است. AP_DB_TYPE=POSTGRES و AP_REDIS_TYPE=STANDALONE گزینه‌های پیش‌فرض هستند. یک حالت تک‌کانتینری با دیتابیس داخلی و صف درون‌پردازشی (AP_DB_TYPE=PGLITE با AP_REDIS_TYPE=MEMORY) نیز وجود دارد و مستندات تأکید می‌کند که این حالت «فقط برای استفاده شخصی یا تست در نظر گرفته شده است». این توصیه را جدی بگیرید. این حالت‌ها نمی‌توانند بیش از یک نمونه (instance) را اجرا کنند، بنابراین خروج از این محدودیت نیازمند مهاجرت است، نه صرفاً تغییر یک فلگ.

Windmill: رویکرد کد-محور و سنگین‌تر از ظاهر آن

Windmill اسکریپت‌ها را در زبان‌های Python، TypeScript، Go، Bash و SQL اجرا کرده و سپس آن‌ها را در قالب جریان‌های کاری (flows) ترکیب می‌کند. اگر اتوماسیون‌های شما عمدتاً شامل کد هستند و تنها مقدار کمی چسبندگی (glue) میان آن‌ها وجود دارد، این ابزار نسبت به هر بوم گره‌محور (node canvas) دیگری مناسب‌تر است.

مجوز (licence) این ابزار نیازمند توجه است. سورس‌کد در صورت کامپایل بدون flag ویژگی‌های سازمانی (enterprise)، تحت مجوز AGPLv3 است. ایمیج‌هایی که در ghcr.io/windmill-labs/windmill منتشر می‌شوند، نسخه Community Edition هستند که شامل کدهایی است که متن‌باز (open source) نبوده و استفاده از آن‌ها تا سقف سهمیه‌های مشخصی رایگان است. صفحه قیمت‌گذاری Windmill این سهمیه‌ها را 50 کاربر، 3 فضای کاری (workspace) و 10 گیگابایت فضای ذخیره‌سازی اشیاء در فضای کاری با تعداد اجرای نامحدود تعیین کرده است. برای یک فرد یا یک تیم کوچک، این سقف بسیار دور از دسترس است، بنابراین پرسش عملی، سهمیه نیست؛ بلکه این است که باینری که اجرا می‌کنید، build نسخه AGPL نیست.

وزن (سنگینی) ابزار، ملاحظه دیگر است. docker-compose.yml خودِ Windmill شامل یک دیتابیس Postgres 16، یک سرور، سه worker پیش‌فرض با محدودیت حافظه 2048M برای هر کدام، یک worker بومی و یک proxy از نوع Caddy است. قاعده کلی مستندشده این است: "1 worker به ازای هر 1vCPU و 1 تا 2 گیگابایت رم". شما می‌توانید تعداد replicaها را در یک سرور کوچک کاهش دهید. باید بدانید که با این کار، ظرفیت پردازشی را محدود می‌کنید، زیرا workerها همان بخش‌هایی هستند که در واقع وظایف (jobs) شما را اجرا می‌کنند.

ویژگی‌های هوش مصنوعی Windmill به عنوان ابزارهای کمکی در زمان توسعه مستند شده‌اند: تولید کد، ساخت جریان کاری، چت و پر کردن فرم. این ویژگی‌ها نیازمند آن هستند که ابتدا یک منبع ارائه‌دهنده مدل (model provider resource) در تنظیمات فضای کاری اضافه کنید. اگر هدف شما یک گامِ عامل (agent step) است که طبق زمان‌بندی اجرا شده و ابزارها را فراخوانی می‌کند، گره AI Agent در n8n همچنان مسیر مستقیم‌تری است و ساخت یک عامل هوش مصنوعی در n8n آن ساختار را پوشش می‌دهد.

Node-RED: گزینه سبک، بدون نیاز به هیچ دیتابیسی

Node-RED تحت مجوز Apache 2.0 عرضه می‌شود که منعطف‌ترین مجوز در این مقایسه است. این ابزار یک پردازش Node.js واحد با یک /data volume است. نه Postgres دارد و نه Redis. آن را روی نسخه nodered/node-red:5.0.4 که نسخه فعلی است، ثابت (Pin) کنید.

این ابزار از دل سیم‌کشی‌های IoT (اینترنت اشیاء) بیرون آمده است، بنابراین ساختار آن بیشتر مبتنی بر رویداد (event-shaped) است تا مبتنی بر اتصال (connector-shaped). نودهای مربوط به سرویس‌های شخص ثالث از کتابخانه جامعه کاربری تأمین می‌شوند و کیفیت آن‌ها متغیر است؛ این همان هزینه‌ای است که برای داشتن یک ابزار کم‌حجم می‌پردازید. هیچ مرحله‌ای برای عامل‌های هوش مصنوعی (AI agent) در سطح اول وجود ندارد. برای یک VPS کوچک که وظیفه مدیریت webhooks و ترافیک message-queue را بر عهده دارد، این سبک‌ترین گزینه موجود است که به درستی کار می‌کند و در عرض چند ثانیه بالا می‌آید.

بررسی Huginn و Automatisch: ابتدا لاگ commitها را چک کنید

نرم‌افزار Huginn تحت لایسنس MIT و با استفاده از Ruby on Rails نوشته شده است و به MySQL یا PostgreSQL نیاز دارد. این ابزار بر اساس مدل «عامل‌ها» (agents) کار می‌کند که یک منبع را زیر نظر گرفته و رویدادهایی را منتشر می‌کنند؛ این مدل با بوم‌های جریان‌کاری (flow canvas) متفاوت است و قابلیت بومی برای LLM ندارد. کد این پروژه همچنان commit دریافت می‌کند، اما آخرین نسخهٔ تگ‌شده (tagged release) مربوط به اوت 2022 است؛ بنابراین اجرای آن به معنای استفاده از ایمیج ghcr.io/huginn/huginn است که از branch پیش‌فرض ساخته شده است. تنها زمانی آن را انتخاب کنید که مدل عامل‌محور با مسئلهٔ شما همخوانی داشته باشد، نه به عنوان جایگزین عمومی برای n8n.

نرم‌افزار Automatisch به جز فایل‌های .ee خود، تحت لایسنس AGPL-3.0 است و شبیه به یک نسخهٔ ساده‌تر از n8n به نظر می‌رسد: شامل Postgres، Redis و کاتالوگ کوچکی از برنامه‌هاست. این همان ابزاری است که آموزش‌های تک‌سروری (single-deploy) مدام آن را توصیه می‌کنند. تاریخچهٔ انتشار آن نشان می‌دهد که باید منتظر ماند. یک سال بدون انتشار نسخهٔ جدید و نیم سال بدون commit، اگر در حال حاضر از آن استفاده می‌کنید دلیلی برای نگرانی نیست، اما دلیلی کافی برای عدم شروع یک deployment جدید در محیط production محسوب می‌شود.

هزینه واقعی یک استک Activepieces از نظر RAM چقدر است

میزان حافظه مصرفی در حالت بیکار (idle) و در حال کار، عددی نیست که بتوان برای شما منتشر کرد، زیرا این مقدار به جریان‌های (flows) کاری شما و حجم داده‌هایی که جابه‌جا می‌کنند بستگی دارد. آنچه می‌توانید مطالعه کنید، بودجه‌بندی پیشنهادی هر فروشنده است. Activepieces ساختار زیر را مستند کرده است و جمله‌ای که در کنار آن آمده، از خود اعداد اهمیت بیشتری دارد: "یک worker با concurrency-1 برای کل مدت زمان اجرای یک جریان (تا 10 دقیقه) مشغول است، بنابراین مقیاس‌بندی را بر اساس جریان‌های همزمان انجام دهید، نه نرخ تریگر."

[
  {
    "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
  }
]

هر worker برابر با 0.5 vCPU و 1 گیگابایت رم است و در هر لحظه دقیقاً یک جریان را اجرا می‌کند. Postgres نیز با 4 گیگابایت رم در نظر گرفته شده است. فایل compose خود پروژه، پنج replica برای worker تعریف می‌کند؛ بنابراین با این محاسبات، استک موجود در مخزن پیش از آنکه جریان‌های شما کار خاصی انجام دهند، به حدود 11 گیگابایت رم نیاز دارد. آموزش‌های تک‌ابزاری، همان فایل را کپی کرده و آن را یک استقرار کوچک می‌نامند.

روی یک VPS با 4 گیگابایت رم، دو worker اجرا کنید، Postgres را در همان پروژه compose نگه دارید و اندازه‌گیری کنید. دستور docker stats --no-stream برای هر container یک خط شامل حافظه واقعی resident آن چاپ می‌کند که از هر عددی که توسط فروشنده یا وبلاگ‌ها منتشر شده، دقیق‌تر است. اگر یک container بدون محدودیت رشد کرد، برای آن سقف تعیین کنید؛ محدودیت‌های حافظه در Docker Compose سینتکس آن را نشان می‌دهد.

فایل compose برای Activepieces روی یک VPS

تگ نسخه را ثابت نگه دارید. latest به این معناست که docker compose pull بعدی می‌تواند بدون هشدار، طرح‌واره (schema) پایگاه داده را تغییر دهد. نسخه 0.86.3 همان نسخه‌ای است که پروژه تا تاریخ 4 August 2026 در فایل compose خود ثابت کرده است.

ابتدا دو secret را با استفاده از طول مشخص‌شده در مستندات ایجاد کنید.

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 در غیر این صورت هنگام ساخت URLهای webhook از آدرس IP عمومی شما استفاده می‌کند. هر 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 خود پروژه است که چهار تغییر در آن اعمال شده است: تعداد workerها از پنج به دو کاهش یافته، پورت منتشرشده به‌جای تمام اینترفیس‌ها فقط به 127.0.0.1 متصل شده، نام‌های ثابت containerها حذف شده‌اند (زیرا سرویسی که replica دارد نمی‌تواند از نام ثابت استفاده کند)، و بلوک شبکه صریح نیز حذف شده است زیرا compose به‌هرحال یک شبکه ایجاد می‌کند.

docker compose up -d
docker compose ps

هر سرویس باید وضعیت Up را نشان دهد، که شامل دو container worker است. containerای که در یک حلقه مدام restart می‌شود، دلیل آن را در docker compose logs worker چاپ می‌کند؛ بنابراین پیش از هر تغییری آن را بخوانید. اتصال پورت به این معناست که تا زمانی که یک reverse proxy با TLS (امنیت لایه انتقال) در مقابل آن قرار ندهید، هیچ ترافیکی از بیرون به برنامه نمی‌رسد که در اجرای Traefik در مقابل چندین برنامه compose به آن پرداخته شده است. فایل .env را با مجوز 600 نگه دارید و آن را در git قرار ندهید، همان‌طور که در مدیریت secretها در فایل‌های env برای compose توضیح داده شده است.

پشتیبان‌گیری که در تمام راهنماها نادیده گرفته می‌شود

تمام این ابزارها اعتبارنامه‌های ذخیره‌شده را رمزنگاری می‌کنند، بنابراین یک dump از پایگاه داده به‌تنهایی یک نسخه پشتیبان کامل نیست. شما به dump و کلیدی که آن را رمزگشایی می‌کند نیاز دارید. دام اینجاست که اکثر این ابزارها آن کلید را به‌صورت خودکار و بی‌سروصدا برای شما تولید کرده و در جایی ذخیره می‌کنند که شما از آن نسخه پشتیبان تهیه نمی‌کنید.

n8n واضح‌ترین نمونه است. اگر هرگز N8N_ENCRYPTION_KEY را تنظیم نکنید، n8n «در اولین اجرا به‌طور خودکار یک کلید رمزنگاری تصادفی ایجاد کرده و آن را در پوشه ~/.n8n ذخیره می‌کند» و سپس از آن کلید برای رمزنگاری اعتبارنامه‌ها پیش از رسیدن به پایگاه داده استفاده می‌کند. اگر از Postgres نسخه dump بگیرید و آن را روی یک کانتینر جدید با volume تازه بازیابی کنید، گردش‌کارها (workflows) بازمی‌گردند اما تمام اعتبارنامه‌ها به صورت متن رمزنگاری‌شده‌ای درمی‌آیند که هیچ‌کس قادر به خواندن آن نیست. این متغیر را به‌طور صریح تنظیم کنید و هنگام اجرای حالت queue، همان مقدار را روی تمام workerها قرار دهید.

Node-RED نیز وضعیت مشابهی دارد. اعتبارنامه‌ها در فایل رمزنگاری‌شده مخصوص خود قرار دارند و کلید آن credentialSecret در settings.js است. وقتی آن را تنظیم نمی‌کنید، runtime یک کلید تصادفی تولید کرده و آن را تحت _credentialSecret در تنظیمات داخلی خود در /data ذخیره می‌کند. فایل تنظیمات پیش‌فرض پیامد آن را این‌گونه بیان می‌کند: «هنگامی که این ویژگی را تنظیم کردید، آن را تغییر ندهید؛ انجام این کار باعث می‌شود Node-RED نتواند اعتبارنامه‌های موجود شما را رمزگشایی کند و آن‌ها از دست خواهند رفت.» از کل volume مربوط به /data نسخه پشتیبان تهیه کنید، نه فقط از فایل flows.

Activepieces مقدار AP_ENCRYPTION_KEY را در .env شما نگه می‌دارد که به‌عنوان «یک کلید هگزادسیمال 32 کاراکتری (16 بایتی) برای رمزنگاری اتصالات» مستند شده است. Huginn مقدار APP_SECRET_TOKEN را در محیط (environment) خود نگه می‌دارد. Automatisch سه مورد از آن‌ها را دارد: ENCRYPTION_KEY، WEBHOOK_SECRET_KEY و APP_SECRET_KEY. در هر مورد، این کلید امنیتی در یک فایل محیطی (environment file) قرار دارد، به این معنی که فایل محیطی بخشی از نسخه پشتیبان است.

Windmill استثنایی است که ارزش دانستن دارد. متغیرها و اسرار آن با یک کلید متقارن مخصوص workspace رمزنگاری می‌شوند که Windmill آن را در پایگاه داده خود ذخیره می‌کند، بنابراین یک dump واحد از Postgres هر دو بخش را در بر می‌گیرد. این برای بازیابی راحت است و به این معنی است که dump به‌تنهایی برای خواندن تمام اسرار کافی است، پس از فایل آن طوری محافظت کنید که گویی خودِ اسرار هستند.

برای stack مربوط به 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

سپس ثابت کنید که نسخه پشتیبان کار می‌کند، زیرا نسخه پشتیبانی که تست نشده باشد، صرفاً یک حدس است. dump را در یک پروژه compose آزمایشی که عمداً از AP_ENCRYPTION_KEY متفاوتی استفاده می‌کند بازیابی کنید، سپس یک flow را اجرا کنید که از یک اتصال ذخیره‌شده استفاده می‌کند. این کار با شکست مواجه می‌شود، زیرا متن رمزنگاری‌شده در پایگاه داده با کلید دیگری تولید شده است. بازیابی را با کلید واقعی از .env تکرار کنید؛ در این صورت همان flow اجرا می‌شود. آن دو اجرا تنها مدرکی هستند که نشان می‌دهند نسخه پشتیبان شما واقعاً یک نسخه پشتیبان است. هر دو فایل را طبق یک برنامه زمانی از سرور خارج کنید، برای مثال با استفاده از پشتیبان‌گیری restic از یک VPS، زیرا نسخه پشتیبانی که روی همان دیسک باشد، با خرابی دیسک از بین می‌رود.

چه زمانی در n8n بمانیم

اگر فعالیت شما محدود به داخل شرکت خودتان است، در n8n بمانید؛ زیرا این دقیقاً همان چیزی است که مجوز Sustainable Use License اجازه می‌دهد. اگر به تنوع ابزارها متکی هستید، در n8n بمانید؛ چرا که این پلتفرم بیش از 1500 ادغام (integration) ارائه می‌دهد. همچنین اگر از نود AI Agent که بر پایه LangChain ساخته شده استفاده می‌کنید، در n8n بمانید؛ زیرا هیچ ابزار دیگری در اینجا، مراحل آماده برای عامل‌های هوشمند (agent steps) را با این کیفیت ارائه نمی‌دهد. مطلب اجرای گردش‌کارهای n8n با Claude نشان می‌دهد که این موضوع در عمل چگونه است.

اگر به دنبال مجوزی آزاد برای هسته اتوماسیون و پشته‌ای (stack) هستید که بتوانید آن را از ابتدا تا انتها بررسی کنید، به Activepieces مهاجرت کنید. اگر گردش‌کارهای شما در واقع کدهایی هستند که یک رابط کاربری بر تن دارند، به Windmill بروید. اگر سخت‌افزار شما کوچک است و کارها ماهیت رویداد-محور (event-shaped) دارند، از Node-RED استفاده کنید. صرفاً به این دلیل که یک بنچمارک ادعا می‌کند n8n سنگین است، مهاجرت نکنید. ابتدا نمونه (instance) خود را اندازه‌گیری کنید، سپس مطلب چه چیزی ارزش self-hosting در سال 2026 را دارد را بخوانید و یک‌بار تصمیم بگیرید؛ زیرا هزینه مهاجرت دوم به اندازه مهاجرت اول است.

FAQ

کدام جایگزین self-hosted برای n8n به آن نزدیک‌تر است؟

Activepieces. ایدهٔ آن دقیقاً مشابه است: یک محیط ساخت بصری که در آن یک trigger جریان کار را آغاز می‌کند و هر مرحله یک سرویس را فراخوانی می‌کند، به همراه کاتالوگ بزرگی از کانکتورها. هستهٔ آن تحت مجوز MIT است، روی Postgres و Redis در Docker اجرا می‌شود و قطعات (pieces) آن به‌عنوان سرورهای MCP برای کلاینت‌های LLM نیز عمل می‌کنند. نکته‌ای که باید در نظر داشت این است که دسترسی API و قابلیت‌های agent در بخش‌های تجاری (enterprise) قرار دارند، بنابراین نسخهٔ Community Edition بیشتر از طریق رابط کاربری وب مدیریت می‌شود تا به‌صورت برنامه‌نویسی.

آیا Activepieces واقعاً متن‌باز است؟

هستهٔ آن تحت مجوز MIT متن‌باز است. دو دایرکتوری packages/ee/ و packages/server/api/src/app/ee دارای مجوز تجاری هستند و استفاده از آن قابلیت‌ها روی سرور شخصی نیازمند خرید لایسنس است. صفحهٔ قیمت‌گذاری فروشنده، قابلیت‌هایی مانند Agents و Chat، پروژه‌ها، دسترسی API، ورود یکپارچه (SSO)، نقش‌های کاربری، لاگ‌های حسابرسی، مدیریت رمزها، شخصی‌سازی برند و همگام‌سازی با Git را خارج از نسخهٔ Community Edition قرار داده است، در حالی که تعداد اجراها، کاربران و جریان‌های کاری محدودیت ندارند. بنابراین، این ابزار برای ساخت و اجرای اتوماسیون‌ها کاملاً متن‌باز است، اما برای لایهٔ مدیریت تیم و حاکمیت، متن‌باز محسوب نمی‌شود.

Activepieces روی یک VPS به چه مقدار RAM نیاز دارد؟

مستندات Activepieces برای هر worker مقدار 0.5 vCPU و 1 گیگابایت رم، برای کانتینر برنامه 1 vCPU و 1 گیگابایت رم، برای Postgres مقدار 4 گیگابایت و برای Redis مقدار 1 گیگابایت رم پیشنهاد می‌دهد. هر worker در هر لحظه یک جریان کاری را تا پایان کامل آن مدیریت می‌کند، بنابراین ظرفیت سرور را باید بر اساس پیک جریان‌های همزمان تعیین کنید، نه تعداد دفعات فعال شدن triggerها. فایل compose موجود در مخزن، پنج worker را به‌صورت پیش‌فرض تعریف کرده که حدود 11 گیگابایت رم نیاز دارد. شروع با دو worker روی یک VPS با 4 گیگابایت رم منطقی است و docker stats --no-stream مقدار واقعی مورد نیاز برای جریان‌های شما را در حین اجرا مشخص می‌کند.

برای اطمینان از موفقیت در بازیابی (restore)، از چه چیزهایی باید بک‌آپ گرفت؟

باید از dump دیتابیس و کلید رمزنگاری به‌صورت همزمان بک‌آپ بگیرید. برای Activepieces، این شامل یک pg_dump از دیتابیس activepieces به همراه فایل .env است که حاوی AP_ENCRYPTION_KEY می‌باشد. برای n8n، این شامل دیتابیس به همراه N8N_ENCRYPTION_KEY است که اگر خودتان آن را تنظیم نکرده باشید، n8n آن را در پوشهٔ ~/.n8n ایجاد کرده است. برای Node-RED، از کل volume مربوط به /data بک‌آپ بگیرید، زیرا فایل اعتبارنامه‌ها و کلیدی که آن را رمزگشایی می‌کند هر دو در آنجا قرار دارند. Windmill یک استثنا است: کلید workspace آن داخل دیتابیس Postgres خودش قرار دارد، بنابراین dump دیتابیس شامل همه چیز است و باید از آن به اندازهٔ خودِ رمزها محافظت شود.

آیا می‌توانم جریان‌های کاری n8n را به ابزار دیگری وارد (import) کنم؟

خیر. این پروژه‌ها فرمت‌های جریان کاری مخصوص به خود را وارد و صادر می‌کنند، نه فرمت n8n را. مهاجرت به معنای بازسازی تک‌تک جریان‌ها در محیط جدید و ایجاد دوبارهٔ هر اعتبارنامه از سرویس اصلی است. این کار هزینهٔ واقعی تغییر ابزار است، بنابراین پیش از تصمیم‌گیری، تعداد جریان‌های خود را بشمارید. دوازده جریان کاری، کار یک بعدازظهر است. دویست جریان کاری یک پروژه محسوب می‌شود و معمولاً اصلاح مصرف حافظه در n8n با استفاده از queue mode و Postgres، ارزان‌تر از بازسازی همهٔ آن‌هاست.