n8n-এর সেরা self-hosted বিকল্পসমূহ: একটি বিস্তারিত তুলনা

n8n-এর পরিবর্তে কী ব্যবহার করবেন

VPS (virtual private server)-এ n8n-এর পরিবর্তে যে বিকল্পগুলো ব্যবহার করা যুক্তিযুক্ত, সেগুলো হলো Activepieces, Windmill, Node-RED, Automatisch এবং Huginn। অধিকাংশ ব্যবহারকারী যেভাবে n8n ব্যবহার করেন, তার জন্য Activepieces সবচেয়ে কাছাকাছি বিকল্প এবং এর মূল অংশটি MIT লাইসেন্সের আওতাভুক্ত। যারা ক্যানভাসে বক্স টেনে কাজ করার চেয়ে Python বা TypeScript কোড লিখতে পছন্দ করেন, তাদের জন্য Windmill উপযুক্ত। Node-RED হলো হালকা ওজনের একটি টুল, যার কোনো ডেটাবেসের প্রয়োজন হয় না।

অনেক ব্যবহারকারীর বর্তমান সেটআপেই থাকা উচিত। n8n-এর লাইসেন্স অভ্যন্তরীণ ব্যবসায়িক ব্যবহারের অনুমতি দেয়, তাই আপনি যদি নিজের কোম্পানির জন্য ফ্লো (flow) চালান, তবে লাইসেন্স নিয়ে আপনার চিন্তার কিছু নেই। মাইগ্রেশনও বিনামূল্যে হয় না। এই তালিকার কোনো টুলই n8n-এর এক্সপোর্ট ফাইল পড়তে পারে না, তাই আপনাকে প্রতিটি ফ্লো হাতে তৈরি করতে হবে এবং প্রতিটি ক্রেডেনশিয়াল পুনরায় ইনপুট দিতে হবে। n8n ইনস্টল করার প্রক্রিয়াটি একটি আলাদা কাজ, যা Docker এবং HTTPS ব্যবহার করে VPS-এ n8n ইনস্টল-এ আলোচনা করা হয়েছে এবং Zapier এবং Make-এর বিপরীতে n8n-এ এই ক্যাটাগরির টুলগুলোর সাথে হোস্ট করা সার্ভিসগুলোর তুলনা করা হয়েছে।

কেন মানুষ n8n-এর self-hosted বিকল্প খোঁজে

দুটি কারণ বারবার সামনে আসে।

প্রথমটি হলো লাইসেন্স। n8n, Sustainable Use License v1.0-এর অধীনে রিলিজ করা হয়, যাকে প্রজেক্টটি ওপেন সোর্স না বলে ফেয়ার-কোড (fair-code) বলে। এই লাইসেন্সটি "সফটওয়্যারটিকে শুধুমাত্র আপনার অভ্যন্তরীণ ব্যবসায়িক উদ্দেশ্যে অথবা অবাণিজ্যিক বা ব্যক্তিগত ব্যবহারের জন্য" ব্যবহার বা পরিবর্তন করার অধিকার দেয় এবং এটি বাণিজ্যিকভাবে অন্য কাউকে সফটওয়্যারটি প্রদান করা নিষিদ্ধ করে। .ee নামযুক্ত ফাইল এবং ফোল্ডারগুলো একটি আলাদা n8n Enterprise License-এর অধীনে থাকে। আপনি যদি অর্থ প্রদানকারী ক্লায়েন্টদের হয়ে অটোমেশন চালাতে চান, তবে এটি একটি বড় বাধা। আপনি যদি একটি অভ্যন্তরীণ অপারেশনস টিমের অংশ হন, তবে এটি আপনার দৈনন্দিন কাজে কোনো পরিবর্তন আনে না।

দ্বিতীয়টি হলো মেমরি। n8n একটি Node.js প্রসেস এবং রান চলাকালীন ওয়ার্কফ্লো ডেটা মেমরিতে থাকে। n8n-এর ডকুমেন্টেশনে এর কারণগুলো উল্লেখ করা হয়েছে: JSON ডেটার পরিমাণ, বাইনারি ডেটার আকার, একটি ওয়ার্কফ্লোতে নোডের সংখ্যা, Code নোড, ম্যানুয়াল এক্সিকিউশন (যা এডিটরের জন্য ডেটা পুনরায় কপি করে) এবং একই সময়ে চলমান অন্যান্য ওয়ার্কফ্লো। ডকুমেন্টেশনে বর্ণিত সমাধানটি অন্য কোনো প্রোডাক্ট নয়। এটি হলো কিউ মোড (queue mode) যার সাথে আলাদা ওয়ার্কার প্রসেস থাকে এবং ~/.n8n/database.sqlite-এ ডিফল্ট SQLite ফাইলের পরিবর্তে Postgres ব্যবহার করা হয়। বড় কাজের ক্ষেত্রে ব্যাচিং (batching) প্রয়োজন, কারণ একটি Loop Over Items নোড যা একটি সাব-ওয়ার্কফ্লোতে ডেটা পাঠায়, তা একবারে ডেটার মাত্র একটি অংশ মেমরিতে রাখে। অন্য কোথাও ষাটটি ফ্লো পুনরায় তৈরি করার আগে এটি চেষ্টা করে দেখুন।

n8n-এর কোন self-hosted বিকল্পগুলো বর্তমানে রক্ষণাবেক্ষণ করা হচ্ছে

লাইসেন্সের টেক্সট পড়া সহজ, তাই সবাই লাইসেন্সের তুলনা করে। প্রজেক্টের স্বাস্থ্য যাচাই করা এড়িয়ে যাওয়া সহজ। এই তুলনামূলক আলোচনায় 6 টি প্রজেক্ট রয়েছে, যার প্রতিটির সর্বশেষ tagged release 4 আগস্ট 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-এর সর্বশেষ tagged release ছিল v0.15.0, যা 361 দিন আগের, এবং এর default branch-এ 15 জানুয়ারি 2026-এর পর কোনো commit নেই। Huginn-এর সর্বশেষ release 1447 দিন আগে হয়েছে, তবুও এর commit log এই মাসেও সক্রিয়। এটি বিপরীত চিত্র: কোড আপডেট হচ্ছে কিন্তু release হচ্ছে না, তাই এটি চালানোর অর্থ হলো একটি untagged image চালানো।

যেকোনো তুলনার ওপর আস্থা রাখার আগে এটি নিজে যাচাই করুন। GitHub-এ প্রজেক্টটির releases পেজ খুলুন, তারপর এর default branch-এর commit লিস্ট দেখুন। একটি প্রজেক্ট যার release নতুন কিন্তু commit log শান্ত, সেটি কেবল আগের গতিতে চলছে। আর যে প্রজেক্টে নতুন commit আছে কিন্তু কয়েক বছর ধরে কোনো release নেই, সেটি এমন কোড চালানোর পরামর্শ দিচ্ছে যার জন্য কেউ কোনো ভার্সন তৈরি করেনি।

Activepieces: সবচেয়ে কাছাকাছি বিকল্প এবং এর MIT কোর

Activepieces হলো একটি সরাসরি বিকল্প। এটি একটি ভিজ্যুয়াল বিল্ডার যেখানে ট্রিগার এবং ধাপ থাকে, যেগুলোকে তারা pieces বলে। README অনুযায়ী এতে 280টিরও বেশি piece রয়েছে। প্রতিটি piece একটি MCP (model context protocol) সার্ভার হিসেবেও কাজ করে, ফলে একটি LLM (large language model) ক্লায়েন্ট একই কানেক্টরগুলোকে টুল হিসেবে ব্যবহার করতে পারে। এর কোর অংশটি MIT লাইসেন্সভুক্ত। packages/ee/ এবং packages/server/api/src/app/ee ডিরেক্টরি দুটি বাণিজ্যিক লাইসেন্সের আওতাভুক্ত এবং এগুলোর ভেতরের অংশ নিজের সার্ভারে ব্যবহার করতে হলে একটি পেইড এগ্রিমেন্ট প্রয়োজন।

মাইগ্রেট করার আগে এই বিভাজনটি ভালোভাবে বুঝে নিন, কারণ বেশিরভাগ MIT প্রজেক্টের তুলনায় এখানে পার্থক্যটি বেশ বড়। Activepieces-এর প্রাইসিং পেজে Community Edition-কে "ওপেন সোর্স, চিরতরে ফ্রি, রান, ইউজার বা ফ্লো-এর কোনো সীমাবদ্ধতা নেই" হিসেবে বর্ণনা করা হয়েছে। তবে Agents এবং Chat, Projects, API অ্যাক্সেস এবং সম্পূর্ণ অ্যাডমিনিস্ট্রেশন লেয়ার (single sign-on, user roles, audit logs, secret managers, branding, Git sync) এর বাইরে রাখা হয়েছে। অর্থাৎ, Community Edition একটি পূর্ণাঙ্গ অটোমেশন ইঞ্জিন যাতে আনলিমিটেড ফ্লো এবং ইউজার ব্যবহার করা যায়, কিন্তু এটি এমন কোনো প্ল্যাটফর্ম নয় যা আপনি API দিয়ে নিয়ন্ত্রণ করতে পারবেন। যদি আপনার পরিকল্পনা প্রোগ্রাম্যাটিকভাবে ফ্লো তৈরি করার হয়, তবে সেই পরিকল্পনার জন্য লাইসেন্স প্রয়োজন।

এর রানটাইম কাঠামোতে একটি অ্যাপ কন্টেইনার, এক বা একাধিক ওয়ার্কার কন্টেইনার, Postgres এবং Redis থাকে। AP_DB_TYPE=POSTGRES এবং AP_REDIS_TYPE=STANDALONE হলো ডিফল্ট। একটি সিঙ্গেল-কন্টেইনার মোডও আছে যেখানে এমবেডেড ডাটাবেস এবং ইন-প্রসেস কিউ (AP_DB_TYPE=PGLITE এবং AP_REDIS_TYPE=MEMORY সহ) থাকে, তবে ডকুমেন্টেশনে বলা হয়েছে এটি "শুধুমাত্র ব্যক্তিগত ব্যবহার বা পরীক্ষার জন্য"। এই কথাটি গুরুত্বের সাথে নিন। এই মোডগুলোতে একাধিক ইনস্ট্যান্স চালানো সম্ভব নয়, তাই এগুলো থেকে বড় পরিসরে যেতে হলে আপনাকে মাইগ্রেশন করতে হবে, এটি কোনো সাধারণ ফ্ল্যাগ পরিবর্তনের বিষয় নয়।

Windmill: কোড-ফার্স্ট এবং প্রত্যাশার চেয়ে ভারী

Windmill Python, TypeScript, Go, Bash এবং SQL-এ স্ক্রিপ্ট রান করে এবং সেগুলোকে ফ্লো (flow)-তে রূপান্তর করে। আপনার অটোমেশন যদি মূলত কোড এবং তার চারপাশে সামান্য কিছু গ্লু-কোড দিয়ে তৈরি হয়, তবে এটি যেকোনো নোড ক্যানভাসের চেয়ে ভালো কাজ করবে।

লাইসেন্সের বিষয়টি সতর্কতার সাথে দেখা প্রয়োজন। এন্টারপ্রাইজ ফিচার ফ্ল্যাগ ছাড়া কম্পাইল করলে এর সোর্স কোড AGPLv3 লাইসেন্সের অন্তর্ভুক্ত। ghcr.io/windmill-labs/windmill-এ প্রকাশিত ইমেজগুলো হলো কমিউনিটি এডিশন, যার মধ্যে এমন কোড রয়েছে যা ওপেন সোর্স নয়, তবে কোটার ভেতরে বিনামূল্যে ব্যবহারযোগ্য। Windmill-এর প্রাইসিং পেজ অনুযায়ী এই কোটা হলো 50 জন ব্যবহারকারী, 3টি ওয়ার্কস্পেস এবং 10 GiB ওয়ার্কস্পেস অবজেক্ট স্টোরেজ, যেখানে এক্সিকিউশনের কোনো সীমা নেই। একজন ব্যক্তি বা ছোট দলের জন্য এই সীমা অনেক বেশি, তাই ব্যবহারিক প্রশ্নটি কোটা নিয়ে নয়। মূল বিষয়টি হলো, আপনি যে বাইনারিটি রান করছেন তা AGPL বিল্ড নয়।

অন্য বিবেচ্য বিষয়টি হলো এর ওজন। Windmill-এর নিজস্ব docker-compose.yml-এ একটি Postgres 16 ডাটাবেস, একটি সার্ভার, তিনটি ডিফল্ট ওয়ার্কার (প্রতিটির জন্য 2048M মেমোরি লিমিট), একটি নেটিভ ওয়ার্কার এবং একটি Caddy প্রক্সি থাকে। নথিপত্র অনুযায়ী সাধারণ নিয়ম হলো "প্রতি 1টি vCPU এবং 1-2 GB RAM-এর জন্য 1টি ওয়ার্কার"। ছোট সার্ভারে আপনি রেপ্লিকার সংখ্যা কমাতে পারেন। তবে আপনার জানা থাকা উচিত যে আপনি সংখ্যা কমাচ্ছেন, কারণ এই ওয়ার্কাররাই মূলত আপনার জবগুলো রান করে।

Windmill-এর AI ফিচারগুলো বিল্ড-টাইমের সহায়তাকারী হিসেবে নথিবদ্ধ করা হয়েছে: কোড জেনারেশন, ফ্লো বিল্ডিং, চ্যাট এবং ফর্ম ফিলাপ। এগুলো ব্যবহারের জন্য আপনাকে প্রথমে ওয়ার্কস্পেস সেটিংসে একটি মডেল প্রোভাইডার রিসোর্স যোগ করতে হবে। আপনি যদি এমন একটি এজেন্ট স্টেপ চান যা শিডিউল অনুযায়ী রান করবে এবং টুলস কল করবে, তবে n8n-এর AI Agent নোডটি সরাসরি কার্যকর উপায়। আর n8n-এ AI এজেন্ট তৈরি বিষয়টি সেই প্রক্রিয়াটি কভার করে।

Node-RED: ডাটাবেসবিহীন ক্ষুদ্রতম সংস্করণ

Node-RED হলো Apache 2.0 লাইসেন্সভুক্ত, যা এই তুলনার মধ্যে সবচেয়ে নমনীয় লাইসেন্স। এটি একটি একক Node.js প্রসেস এবং এতে /data ভলিউম ব্যবহৃত হয়। এতে কোনো Postgres বা Redis নেই। এটিকে nodered/node-red:5.0.4 ভার্সনে পিন করুন, যা বর্তমান রিলিজ।

এটি IoT (Internet of Things) ওয়্যারিং থেকে উদ্ভূত, তাই এটি কানেক্টর-ভিত্তিক হওয়ার পরিবর্তে ইভেন্ট-ভিত্তিক। তৃতীয় পক্ষের পরিষেবার জন্য নোডগুলো কমিউনিটি লাইব্রেরি থেকে আসে এবং সেগুলোর গুণমান ভিন্ন হতে পারে; ক্ষুদ্র ফুটপ্রিন্টের বিনিময়ে এটিই আপনাকে মেনে নিতে হবে। এতে কোনো ফার্স্ট-ক্লাস AI এজেন্ট ধাপ নেই। ওয়েবহুক এবং মেসেজ-কিউ ট্রাফিক হ্যান্ডেল করে এমন ছোট VPS-এর জন্য এটি সবচেয়ে হালকা কার্যকর সমাধান এবং এটি কয়েক সেকেন্ডের মধ্যেই চালু হয়।

Huginn এবং Automatisch: প্রথমে commit log পরীক্ষা করুন

Huginn হলো MIT লাইসেন্সভুক্ত, Ruby on Rails-এ লেখা এবং এর জন্য MySQL বা PostgreSQL প্রয়োজন। এটি এমন সব agent-এর মাধ্যমে কাজ করে যা কোনো উৎস পর্যবেক্ষণ করে এবং ইভেন্ট তৈরি করে; এটি flow canvas-এর চেয়ে ভিন্ন একটি মডেল এবং এতে কোনো LLM-এর সুবিধা নেই। এর কোডে এখনো commit আসে, কিন্তু সর্বশেষ tagged release ছিল আগস্ট 2022-এ, তাই এটি চালানোর অর্থ হলো default branch থেকে তৈরি ghcr.io/huginn/huginn image ব্যবহার করা। যখন আপনার সমস্যার জন্য agent মডেলটি উপযুক্ত হবে তখনই এটি বেছে নিন, n8n-এর সাধারণ বিকল্প হিসেবে নয়।

Automatisch হলো AGPL-3.0 লাইসেন্সভুক্ত (এর .ee ফাইলগুলো বাদে) এবং এটি দেখতে অনেকটা সাধারণ n8n-এর মতো: Postgres, Redis এবং অ্যাপের একটি ছোট ক্যাটালগ। এটি এমন একটি টুল যা single-deploy টিউটোরিয়ালগুলোতে বারবার সুপারিশ করা হয়। এর release history বলছে অপেক্ষা করতে। এক বছর কোনো release না হওয়া এবং ছয় মাস কোনো commit না থাকা মানেই আতঙ্কিত হওয়ার কারণ নেই যদি আপনি এটি ইতিমধ্যে চালিয়ে থাকেন, তবে নতুন কোনো production deployment শুরু করার জন্য এটি উপযুক্ত নয়।

Activepieces স্ট্যাকের প্রকৃত RAM খরচ

নিষ্ক্রিয় এবং চলমান অবস্থায় মেমরির ব্যবহার এমন কোনো সংখ্যা নয় যা কেউ আপনার জন্য প্রকাশ করতে পারে, কারণ এটি আপনার নিজস্ব ফ্লো এবং সেগুলোর ডেটার পরিমাণের ওপর নির্ভর করে। আপনি যা পড়তে পারেন তা হলো প্রতিটি ভেন্ডর আপনাকে কী পরিমাণ বাজেট রাখতে পরামর্শ দেয়। Activepieces নিচের কাঠামোটি নথিবদ্ধ করেছে, এবং সংখ্যার চেয়ে এর পাশের বাক্যটি বেশি গুরুত্বপূর্ণ: "একটি 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
  }
]

একটি ওয়ার্কার হলো 0.5 vCPU এবং 1 GB, এবং এটি একবারে ঠিক একটি ফ্লো চালায়। Postgres-এর সাইজ নির্ধারণ করা হয়েছে 4 GB। প্রজেক্টের নিজস্ব compose ফাইলে পাঁচটি ওয়ার্কার রেপ্লিকা থাকে, তাই সেই সাইজিং অনুযায়ী রিপোজিটরিতে থাকা স্ট্যাকটি আপনার ফ্লো কোনো গুরুত্বপূর্ণ কাজ করার আগেই প্রায় 11 GB মেমরি দাবি করে। সিঙ্গেল-টুল টিউটোরিয়ালগুলো সেই ফাইলটি কপি করে সেটিকে একটি ছোট ডিপ্লয়মেন্ট বলে অভিহিত করে।

4 GB-এর একটি VPS-এ দুটি ওয়ার্কার চালান, Postgres-কে একই compose প্রজেক্টে রাখুন এবং পরিমাপ করুন। docker stats --no-stream প্রতিটি কন্টেইনারের জন্য তার প্রকৃত রেসিডেন্ট মেমরি সহ একটি লাইন প্রিন্ট করে, যা কোনো ভেন্ডর বা ব্লগের প্রকাশিত যেকোনো সংখ্যার চেয়ে নির্ভুল। যদি কোনো কন্টেইনারের মেমরি ব্যবহার সীমা ছাড়া বাড়তে থাকে, তবে তা সীমাবদ্ধ করুন, এবং Docker Compose-এ মেমরি লিমিট বিষয়টি সিনট্যাক্সটি দেখায়।

একটি VPS-এ Activepieces-এর জন্য compose ফাইল

ট্যাগটি পিন করুন। latest মানে হলো পরবর্তী docker compose pull কোনো সতর্কতা ছাড়াই আপনার ডাটাবেস স্কিমা পরিবর্তন করতে পারে। 4 আগস্ট 2026 অনুযায়ী, প্রজেক্টটি তাদের নিজস্ব compose ফাইলে 0.86.3 ভার্সনটি পিন করে রেখেছে।

প্রথমে ডকুমেন্টেশনে উল্লেখিত দৈর্ঘ্য অনুযায়ী দুটি সিক্রেট তৈরি করুন।

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

compose ফাইলের পাশে .env লিখুন:

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 webhook URL তৈরির সময় আপনার পাবলিক 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 ফাইল, যেখানে চারটি পরিবর্তন করা হয়েছে: ওয়ার্কারের সংখ্যা পাঁচ থেকে কমিয়ে দুই করা হয়েছে, প্রকাশিত পোর্টটি সব ইন্টারফেসের পরিবর্তে 127.0.0.1-এ বাইন্ড করা হয়েছে, নির্দিষ্ট কন্টেইনারের নামগুলো সরিয়ে ফেলা হয়েছে কারণ রেপ্লিকা থাকা সার্ভিসগুলোতে এগুলো ব্যবহার করা যায় না, এবং এক্সপ্লিসিট নেটওয়ার্ক ব্লকটি বাদ দেওয়া হয়েছে কারণ compose এমনিতেই একটি তৈরি করে নেয়।

docker compose up -d
docker compose ps

প্রতিটি সার্ভিসকে Up দেখাতে হবে, যার মধ্যে দুটি worker কন্টেইনার অন্তর্ভুক্ত। যে কন্টেইনারটি লুপে রিস্টার্ট হয়, সেটি docker compose logs worker-এ তার কারণ প্রদর্শন করে, তাই কিছু পরিবর্তন করার আগে সেটি পড়ে নিন। পোর্ট বাইন্ডিংয়ের অর্থ হলো, আপনি সামনে TLS (transport layer security) সহ একটি reverse proxy না বসানো পর্যন্ত বাইরে থেকে অ্যাপটিতে কিছুই পৌঁছাবে না, যা একাধিক compose অ্যাপের সামনে Traefik চালানো অংশে কভার করা হয়েছে। .env-কে মোড 600-এ রাখুন এবং git থেকে দূরে রাখুন, যেমনটি compose env ফাইলে সিক্রেট হ্যান্ডেল করা অংশে বলা হয়েছে।

যে ব্যাকআপের কথা প্রতিটি গাইড এড়িয়ে যায়

এই টুলগুলোর প্রতিটিই সংরক্ষিত ক্রেডেনশিয়াল এনক্রিপ্ট করে রাখে, তাই শুধুমাত্র একটি ডাটাবেস ডাম্প কোনো পূর্ণাঙ্গ ব্যাকআপ নয়। আপনার ডাম্প ফাইল এবং এটি ডিক্রিপ্ট করার কি (key)—উভয়ই প্রয়োজন। সমস্যা হলো, এই টুলগুলোর বেশিরভাগই আপনার অজান্তে একটি কি তৈরি করে এবং এমন জায়গায় সংরক্ষণ করে যা আপনি ব্যাকআপের অন্তর্ভুক্ত করছেন না।

n8n এক্ষেত্রে সবচেয়ে স্পষ্ট উদাহরণ। আপনি যদি N8N_ENCRYPTION_KEY সেট না করেন, তবে n8n "প্রথমবার চালু হওয়ার সময় স্বয়ংক্রিয়ভাবে একটি র‍্যান্ডম এনক্রিপশন কি তৈরি করে এবং তা ~/.n8n ফোল্ডারে সংরক্ষণ করে"। এরপর ডাটাবেসে পাঠানোর আগে ক্রেডেনশিয়ালগুলো এনক্রিপ্ট করতে এই কি ব্যবহার করা হয়। আপনি যদি Postgres ডাম্প করেন এবং নতুন ভলিউমসহ একটি ফ্রেশ কন্টেইনারে রিস্টোর করেন, তবে ওয়ার্কফ্লো ফিরে আসবে কিন্তু প্রতিটি ক্রেডেনশিয়াল এমন সাইফারটেক্সট হয়ে থাকবে যা কেউ পড়তে পারবে না। তাই ভেরিয়েবলটি স্পষ্টভাবে সেট করুন এবং কিউ মোডে চালানোর সময় প্রতিটি ওয়ার্কারে একই ভ্যালু ব্যবহার করুন।

Node-RED-এর ক্ষেত্রেও একই নিয়ম প্রযোজ্য। ক্রেডেনশিয়ালগুলো তাদের নিজস্ব এনক্রিপ্ট করা ফাইলে থাকে এবং কি (key) হলো credentialSecret, যা settings.js-এ থাকে। আপনি যদি এটি সেট না করেন, তবে রানটাইম একটি র‍্যান্ডম কি তৈরি করে এবং তা /data-এর ভেতরে নিজস্ব সেটিংস স্টোরে _credentialSecret নামে সংরক্ষণ করে। স্টক সেটিংস ফাইলে এর পরিণাম স্পষ্টভাবে বলা আছে: "একবার এই প্রপার্টি সেট করলে তা পরিবর্তন করবেন না - অন্যথায় Node-RED আপনার বিদ্যমান ক্রেডেনশিয়ালগুলো ডিক্রিপ্ট করতে পারবে না এবং সেগুলো হারিয়ে যাবে।" তাই শুধু ফ্লো ফাইল নয়, পুরো /data ভলিউম ব্যাকআপ নিন।

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

এরপর ব্যাকআপটি কাজ করছে কি না তা যাচাই করুন, কারণ পরীক্ষিত নয় এমন ব্যাকআপ কেবল একটি অনুমান। একটি স্ক্র্যাচ কম্পোজ প্রজেক্টে ডাম্পটি রিস্টোর করুন যা ইচ্ছাকৃতভাবে ভিন্ন একটি AP_ENCRYPTION_KEY ব্যবহার করে, তারপর এমন একটি ফ্লো চালান যা একটি সংরক্ষিত কানেকশন ব্যবহার করে। এটি ব্যর্থ হবে, কারণ ডাটাবেসের সাইফারটেক্সট অন্য কি দিয়ে তৈরি করা হয়েছিল। এবার .env থেকে আসল কি ব্যবহার করে পুনরায় রিস্টোর করুন, দেখবেন একই ফ্লো সফলভাবে চলছে। এই দুটি রানই একমাত্র প্রমাণ যে আপনার ব্যাকআপটি কার্যকর। একটি নির্দিষ্ট সময়সূচী মেনে ফাইল দুটি সার্ভারের বাইরে পাঠিয়ে দিন, যেমন VPS থেকে restic ব্যাকআপ, কারণ একই ডিস্কে রাখা ব্যাকআপ ডিস্ক নষ্ট হওয়ার সাথে সাথেই হারিয়ে যায়।

কখন n8n ব্যবহার চালিয়ে যাবেন

যদি আপনার কাজ আপনার নিজস্ব কোম্পানির অভ্যন্তরীণ হয়, তবে n8n ব্যবহার চালিয়ে যান, কারণ Sustainable Use License ঠিক এই কাজের জন্যই অনুমতি দেয়। যদি আপনি বিস্তৃত ইন্টিগ্রেশনের ওপর নির্ভর করেন, তবে এটি ব্যবহার করুন, কারণ n8n 1500-এর বেশি ইন্টিগ্রেশনের দাবি করে। এছাড়া LangChain-এর ওপর ভিত্তি করে তৈরি এর AI Agent node-এর মতো রেডিমেড এজেন্ট স্টেপ অন্য কোনো প্ল্যাটফর্মে নেই। Driving n8n workflows with Claude-এ বাস্তবে এটি কেমন কাজ করে তা দেখানো হয়েছে।

যদি আপনি অটোমেশন কোরের জন্য একটি পারমিসিভ লাইসেন্স এবং এমন একটি স্ট্যাক চান যা আপনি শুরু থেকে শেষ পর্যন্ত পড়তে পারেন, তবে Activepieces-এ চলে যান। যদি আপনার ফ্লোগুলো মূলত ইউজার ইন্টারফেসযুক্ত কোড হয়, তবে Windmill বেছে নিন। যদি আপনার সার্ভার ছোট হয় এবং কাজের ধরন ইভেন্ট-ভিত্তিক হয়, তবে Node-RED ব্যবহার করুন। কোনো বেঞ্চমার্ক রিপোর্ট দেখে n8n ভারী মনে করে এটি পরিবর্তন করবেন না। প্রথমে আপনার নিজস্ব ইনস্ট্যান্সের পারফরম্যান্স পরিমাপ করুন, তারপর what is worth self-hosting in 2026 পড়ুন এবং একবারই সিদ্ধান্ত নিন, কারণ দ্বিতীয়বার মাইগ্রেশনের খরচ প্রথমবারের মতোই বেশি।

FAQ

n8n-এর বিকল্প হিসেবে কোনটি n8n-এর সবচেয়ে কাছাকাছি?

Activepieces। এটি একই ধারণার ওপর ভিত্তি করে তৈরি: একটি ভিজ্যুয়াল বিল্ডার যেখানে একটি ট্রিগার ফ্লো শুরু করে এবং প্রতিটি ধাপ একটি সার্ভিসকে কল করে, যার সাথে কানেক্টরদের একটি বিশাল ক্যাটালগ থাকে। এর কোর অংশটি MIT লাইসেন্সভুক্ত, এটি Docker-এর অধীনে Postgres এবং Redis-এ চলে এবং এর পিসগুলো LLM ক্লায়েন্টদের জন্য MCP সার্ভার হিসেবেও কাজ করতে পারে। যে বিষয়টি খেয়াল রাখতে হবে তা হলো, API অ্যাক্সেস এবং এজেন্ট ফিচারগুলো বাণিজ্যিক এন্টারপ্রাইজ ডিরেক্টরিতে থাকে, তাই Community Edition ইনস্ট্যান্সটি প্রোগ্রাম্যাটিক্যালি ব্যবহারের পরিবর্তে এর ওয়েব ইন্টারফেসের মাধ্যমে পরিচালনা করতে হয়।

Activepieces কি সত্যিই ওপেন সোর্স?

এর কোর অংশটি MIT লাইসেন্সের অধীনে ওপেন সোর্স। দুটি ডিরেক্টরি, packages/ee/ এবং packages/server/api/src/app/ee, বাণিজ্যিকভাবে লাইসেন্সপ্রাপ্ত এবং আপনার নিজস্ব সার্ভারে সেই ফিচারগুলো ব্যবহার করতে হলে পেইড লাইসেন্সের প্রয়োজন হয়। ভেন্ডরের প্রাইসিং পেজ অনুযায়ী Agents and Chat, Projects, API access, single sign-on, user roles, audit logs, secret managers, branding এবং Git sync ফিচারগুলো Community Edition-এর বাইরে রাখা হয়েছে, তবে রান, ইউজার এবং ফ্লো-এর সংখ্যায় কোনো সীমাবদ্ধতা নেই। সুতরাং, অটোমেশন তৈরি এবং চালানোর জন্য এটি পুরোপুরি ওপেন সোর্স, কিন্তু টিম এবং গভর্নেন্স লেয়ারের জন্য এটি ওপেন সোর্স নয়।

একটি VPS-এ Activepieces চালানোর জন্য কতটুকু RAM প্রয়োজন?

Activepieces-এর ডকুমেন্টেশন অনুযায়ী প্রতিটি ওয়ার্কারের জন্য 0.5 vCPU এবং 1 GB RAM, অ্যাপ কন্টেইনারের জন্য 1 vCPU এবং 1 GB RAM, Postgres-এর জন্য 4 GB এবং Redis-এর জন্য 1 GB RAM প্রয়োজন। একটি ওয়ার্কার একটি ফ্লো চলাকালীন পুরো সময় সেটি হ্যান্ডেল করে, তাই আপনার সার্ভারের সাইজ নির্ধারণ করতে হবে সর্বোচ্চ কনকারেন্ট ফ্লো-এর ওপর ভিত্তি করে, ট্রিগার কত ঘন ঘন কাজ করছে তার ওপর নয়। রিপোজিটরিতে থাকা compose ফাইলে পাঁচটি ওয়ার্কার থাকে, যার জন্য প্রায় 11 GB RAM প্রয়োজন। একটি 4 GB VPS-এ দুটি ওয়ার্কার দিয়ে শুরু করা যুক্তিসঙ্গত এবং docker stats --no-stream আপনার ফ্লো চলার সময় প্রকৃত ব্যবহারের পরিমাণ নিশ্চিত করবে।

রিস্টোর সফল হওয়ার জন্য কী কী ব্যাকআপ রাখা জরুরি?

ডাটাবেস ডাম্প এবং এনক্রিপশন কি (key) উভয়ই ব্যাকআপ রাখতে হবে। Activepieces-এর ক্ষেত্রে এটি হলো activepieces ডাটাবেসের একটি pg_dump এবং AP_ENCRYPTION_KEY ধারণকারী .env ফাইল। n8n-এর ক্ষেত্রে এটি হলো ডাটাবেস এবং N8N_ENCRYPTION_KEY, যা আপনি যদি আগে সেট না করে থাকেন তবে n8n নিজেই ~/.n8n ফোল্ডারের ভেতরে তৈরি করে নিয়েছে। Node-RED-এর জন্য পুরো /data ভলিউম ব্যাকআপ রাখুন, কারণ ক্রেডেনশিয়াল ফাইল এবং সেটি ডিক্রিপ্ট করার কি (key) উভয়ই সেখানে থাকে। Windmill এক্ষেত্রে ব্যতিক্রম: এর ওয়ার্কস্পেস কি (key) এর নিজস্ব Postgres ডাটাবেসের ভেতরে থাকে, তাই ডাটাবেস ডাম্পেই সবকিছু থাকে এবং সেটিকে সিক্রেট ফাইলের মতোই সুরক্ষিত রাখতে হবে।

আমি কি আমার n8n ওয়ার্কফ্লো অন্য কোনো টুলে ইম্পোর্ট করতে পারব?

না। এই প্রজেক্টগুলো তাদের নিজস্ব ফ্লো ফরম্যাট ইম্পোর্ট এবং এক্সপোর্ট করে, n8n-এর ফরম্যাট নয়। মাইগ্রেশনের অর্থ হলো নতুন বিল্ডারে প্রতিটি ফ্লো নতুন করে তৈরি করা এবং মূল সার্ভিস থেকে প্রতিটি ক্রেডেনশিয়াল পুনরায় তৈরি করা। এই কাজটিই মূলত পরিবর্তনের আসল খরচ, তাই সিদ্ধান্ত নেওয়ার আগে আপনার ফ্লো-এর সংখ্যা গণনা করুন। বারোটি ফ্লো তৈরি করতে এক বিকেল সময় লাগতে পারে। দুইশ ফ্লো একটি বড় প্রজেক্ট, এবং সেগুলোর সব নতুন করে তৈরি করার চেয়ে queue mode এবং Postgres ব্যবহার করে n8n-এর মেমোরি ব্যবহার অপ্টিমাইজ করা সাধারণত সাশ্রয়ী।