n8n ला सर्वोत्तम पर्याय कोणते? तुलनात्मक विश्लेषण

n8n ऐवजी काय वापरावे

VPS (virtual private server) वर n8n ला पर्याय म्हणून Activepieces, Windmill, Node-RED, Automatisch आणि Huginn हे पर्याय विचारात घेण्यासारखे आहेत. बहुतेक लोक ज्या पद्धतीने n8n वापरतात, त्यासाठी Activepieces हा सर्वात जवळचा पर्याय आहे आणि त्याचा मुख्य भाग MIT परवान्याअंतर्गत येतो. ज्या टीमला कॅनव्हासवर बॉक्स ओढण्यापेक्षा Python किंवा TypeScript मध्ये कोड लिहिणे अधिक सोयीचे वाटते, त्यांच्यासाठी Windmill हा उत्तम पर्याय आहे. Node-RED हे आकाराने लहान असून त्याला कोणत्याही database ची गरज नसते.

अनेक वापरकर्त्यांनी सध्याच्या स्थितीतच राहणे योग्य ठरेल. n8n चा परवाना अंतर्गत व्यावसायिक वापरासाठी परवानगी देतो, त्यामुळे जर तुम्ही तुमच्या स्वतःच्या कंपनीसाठी flows चालवत असाल, तर परवाना ही तुमच्यासाठी समस्या नाही. तसेच, स्थलांतर (migration) मोफत नसते. या यादीतील कोणतेही साधन n8n export फाईल वाचू शकत नाही, त्यामुळे तुम्हाला प्रत्येक flow पुन्हा हाताने तयार करावा लागेल आणि सर्व credentials पुन्हा प्रविष्ट करावी लागतील. n8n इन्स्टॉल करणे हे एक स्वतंत्र काम आहे, ज्याची माहिती VPS वर Docker आणि HTTPS सह n8n इन्स्टॉल करणे यामध्ये दिली आहे, आणि Zapier आणि Make च्या तुलनेत n8n या लेखात या संपूर्ण श्रेणीची hosted सेवांशी तुलना कशी केली जाते, हे स्पष्ट केले आहे.

लोक n8n च्या self-hosted पर्यायांचा शोध का घेतात

दोन कारणे वारंवार समोर येतात.

पहिले कारण म्हणजे परवाना (licence). 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 पर्याय अजूनही सक्रिय आहेत

परवाना मजकूर वाचायला सोपा असतो, त्यामुळे प्रत्येकजण परवान्यांची तुलना करतो. प्रकल्पाचे आरोग्य (project health) तपासणे अनेकदा दुर्लक्षित केले जाते. या तुलनेत एकूण 6 प्रकल्प आहेत आणि 4 ऑगस्ट 2026 रोजी प्रत्येकाची सर्वात अलीकडील टॅग केलेली आवृत्ती (tagged release) खालीलप्रमाणे आहे.

[
  {
    "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 जानेवारी 2026 पासून कोणताही कमिट झालेला नाही. Huginn ची शेवटची आवृत्ती 1447 दिवसांपूर्वी टॅग केली गेली होती, तरीही त्याचा कमिट लॉग या महिन्यात सक्रिय आहे. हे अगदी उलट चित्र आहे: कोडमध्ये बदल होत आहेत पण नवीन आवृत्त्या (releases) येत नाहीत, त्यामुळे ते वापरणे म्हणजे टॅग न केलेली इमेज चालवण्यासारखे आहे.

कोणत्याही तुलनेवर, अगदी या तुलनेवरही विश्वास ठेवण्यापूर्वी स्वतः खात्री करा. GitHub वर त्या प्रकल्पाचे releases पेज उघडा आणि त्यानंतर त्याच्या डीफॉल्ट ब्रँचची कमिट लिस्ट तपासा. ज्या प्रकल्पाची नवीन आवृत्ती आली आहे पण कमिट लॉग शांत आहे, तो प्रकल्प केवळ जुन्या गतीवर चालत आहे. ज्या प्रकल्पात नवीन कमिट्स आहेत पण अनेक वर्षांपासून कोणतीही आवृत्ती प्रसिद्ध झालेली नाही, तो प्रकल्प तुम्हाला असा कोड चालवण्यास सांगत आहे ज्यासाठी कोणीही अधिकृत आवृत्ती तयार केलेली नाही.

Activepieces: सर्वात जवळचा पर्याय आणि मूळतः MIT परवाना

Activepieces हा एक तंतोतंत पर्याय आहे. हा एक व्हिज्युअल बिल्डर आहे ज्यामध्ये ट्रिगर्स आणि स्टेप्स असतात, ज्यांना हे 'pieces' असे म्हणतात. README नुसार यामध्ये 280 पेक्षा जास्त pieces उपलब्ध आहेत. प्रत्येक piece हा MCP (model context protocol) सर्व्हर म्हणूनही उपलब्ध असतो, त्यामुळे LLM (large language model) क्लायंट हेच कनेक्टर्स टूल्स म्हणून वापरू शकतो. याचा मुख्य भाग MIT परवान्याअंतर्गत येतो. दोन डिरेक्टरीज, packages/ee/ आणि packages/server/api/src/app/ee, व्यावसायिक परवान्याअंतर्गत येतात आणि त्यातील घटकांचा स्वतःच्या सर्व्हरवर वापर करण्यासाठी सशुल्क कराराची आवश्यकता असते.

स्थलांतर करण्यापूर्वी हे विभाजन नीट समजून घ्या, कारण हे इतर अनेक MIT प्रकल्पांच्या तुलनेत अधिक व्यापक आहे. Activepieces च्या किंमतींच्या पेजवर 'Community Edition' चे वर्णन "ओपन सोर्स, कायमस्वरूपी मोफत, रन, युजर्स किंवा फ्लोवर कोणतीही मर्यादा नाही" असे केले आहे. यामध्ये एजंट्स आणि चॅट, प्रोजेक्ट्स, 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) असते, परंतु दस्तऐवजानुसार हे "केवळ वैयक्तिक वापरासाठी किंवा चाचणीसाठी आहे". हे गांभीर्याने घ्या. हे मोड एकापेक्षा जास्त इन्स्टन्स चालवू शकत नाहीत, त्यामुळे यातून बाहेर पडणे म्हणजे केवळ एखादा फ्लॅग बदलणे नसून ते एक पूर्ण स्थलांतर (migration) असेल.

Windmill: कोड-फर्स्ट आणि अपेक्षेपेक्षा अधिक जड

Windmill मध्ये Python, TypeScript, Go, Bash आणि SQL मधील स्क्रिप्ट्स चालवल्या जातात आणि त्यानंतर त्यांचे 'flows' तयार केले जातात. जर तुमची ऑटोमेशन मुख्यत्वे कोडवर आधारित असतील आणि त्यांना जोडण्यासाठी थोड्या प्रमाणात 'glue' कोडची गरज असेल, तर हे टूल कोणत्याही नोड-कॅनव्हासपेक्षा अधिक प्रभावी ठरते.

याचे लायसन्स काळजीपूर्वक समजून घेणे आवश्यक आहे. जेव्हा हे सॉफ्टवेअर enterprise feature flag शिवाय कंपाईल केले जाते, तेव्हा त्याचा सोर्स AGPLv3 असतो. ghcr.io/windmill-labs/windmill वर प्रकाशित केलेल्या इमेजेस या 'Community Edition' आहेत, ज्यामध्ये असा कोड समाविष्ट आहे जो ओपन सोर्स नाही, परंतु ठराविक मर्यादेपर्यंत (quotas) वापरण्यासाठी मोफत आहे. Windmill च्या किंमतींच्या पेजवर ही मर्यादा 50 युजर्स, 3 वर्कस्पेस आणि 10 GiB वर्कस्पेस ऑब्जेक्ट स्टोरेज अशी निश्चित केली आहे, ज्यामध्ये एक्झिक्युशन्सवर कोणतीही मर्यादा नाही. एका व्यक्तीसाठी किंवा लहान टीमसाठी ही मर्यादा गाठणे कठीण आहे, त्यामुळे प्रत्यक्ष प्रश्न कोट्याचा नाही. महत्त्वाचा मुद्दा हा आहे की, तुम्ही चालवत असलेली बायनरी ही AGPL बिल्ड नाही.

दुसरा महत्त्वाचा विचार म्हणजे याचे वजन (weight). Windmill चे स्वतःचे docker-compose.yml हे एक Postgres 16 डेटाबेस, एक सर्व्हर, तीन डीफॉल्ट वर्कर्स (प्रत्येकी 2048M मेमरी मर्यादेसह), एक नेटिव्ह वर्कर आणि एक Caddy प्रॉक्सी समाविष्ट करते. दस्तऐवजीकरणानुसार, "प्रत्येक 1vCPU साठी 1 वर्कर आणि 1-2 GB RAM" असा नियम आहे. तुम्ही लहान सर्व्हरवर रेप्लिकाची संख्या कमी करू शकता. मात्र, हे करताना तुम्हाला जाणीव असावी की तुम्ही हे करत आहात, कारण प्रत्यक्षात तुमचे जॉब्स हे वर्कर्सच चालवतात.

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 या आवृत्तीवर पिन करा, जी सध्याची अधिकृत आवृत्ती (release) आहे.

याची सुरुवात IoT (internet of things) वायरिंगमधून झाली आहे, त्यामुळे याची रचना कनेक्टर-आधारित नसून इव्हेंट-आधारित आहे. तृतीय-पक्ष सेवांसाठीचे नोड्स कम्युनिटी लायब्ररीतून येतात आणि त्यांची गुणवत्ता वेगवेगळी असते; कमी मेमरी वापरासाठी हा एक तडजोड म्हणून स्वीकारलेला पर्याय आहे. यात प्रथम श्रेणीतील (first-class) AI एजंट स्टेप उपलब्ध नाही. वेबहुक्स आणि मेसेज-क्यू ट्रॅफिक हाताळणाऱ्या लहान VPS साठी, हे यातील सर्वात हलके आणि कार्यक्षम साधन आहे, जे काही सेकंदात सुरू होते.

Huginn आणि Automatisch: प्रथम commit log तपासा

Huginn हे MIT परवान्याअंतर्गत असून ते Ruby on Rails मध्ये लिहिलेले आहे आणि त्यासाठी MySQL किंवा PostgreSQL ची आवश्यकता असते. हे साधन 'agents' च्या संकल्पनेवर काम करते, जे स्त्रोतावर लक्ष ठेवतात आणि इव्हेंट्स उत्सर्जित करतात. हे मॉडेल flow canvas पेक्षा वेगळे आहे आणि यात LLM साठी कोणतीही विशेष सोय नाही. याच्या कोडमध्ये अजूनही commits होत आहेत, परंतु शेवटची tagged release ऑगस्ट 2022 मधील आहे, त्यामुळे हे चालवण्यासाठी तुम्हाला default branch वरून तयार केलेली ghcr.io/huginn/huginn image वापरावी लागेल. जेव्हा agent मॉडेल तुमच्या समस्येशी जुळते तेव्हाच याची निवड करा, n8n ला पर्याय म्हणून याचा विचार करू नका.

Automatisch हे त्याच्या .ee फाइल्स वगळता AGPL-3.0 परवान्याअंतर्गत येते आणि ते n8n ची एक साधी आवृत्ती वाटते: यासाठी Postgres, Redis आणि ॲप्सची एक छोटी कॅटलॉग आवश्यक असते. हे असे साधन आहे ज्याची शिफारस single-deploy ट्युटोरियल्समध्ये वारंवार केली जाते. रिलीजचा इतिहास पाहता, सध्या वाट पाहणेच योग्य ठरेल. एक वर्ष रिलीज न येणे आणि अर्ध्या वर्षापासून कोणताही commit न होणे, हे जर तुम्ही आधीच हे साधन वापरत असाल तर घाबरण्याचे कारण नाही, परंतु नवीन production deployment सुरू करण्यासाठी हे योग्य नाही.

Activepieces स्टॅकसाठी प्रत्यक्ष RAM चा खर्च

आयडल (idle) आणि कार्यरत असताना लागणारी मेमरी कोणीही निश्चितपणे सांगू शकत नाही, कारण ती तुमच्या फ्लोवर आणि त्यातील डेटाच्या प्रमाणावर अवलंबून असते. तुम्ही फक्त प्रत्येक व्हेंडरने सुचवलेला बजेटचा अंदाज वाचू शकता. Activepieces ने खालीलप्रमाणे रचना दिली आहे, आणि त्यातील आकड्यांपेक्षा त्यासोबतचे वाक्य अधिक महत्त्वाचे आहे: "एक concurrency-1 वर्कर फ्लोच्या संपूर्ण कालावधीसाठी (10 मिनिटांपर्यंत) व्यस्त असतो, त्यामुळे ट्रिगर रेटनुसार नाही तर एकाच वेळी चालणाऱ्या (concurrent) फ्लोनुसार आकारमान ठरवा."

[
  {
    "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 RAM, जो एका वेळी फक्त एकच फ्लो चालवतो. Postgres साठी 4 GB चा आकार सुचवला आहे. प्रोजेक्टच्या मूळ compose फाईलमध्ये पाच वर्कर रेप्लिका असतात, त्यामुळे रिपॉझिटरीमधील स्टॅकनुसार, तुमचे फ्लो काहीही काम करण्यापूर्वीच साधारण 11 GB RAM लागते. अनेक ट्युटोरियल्स हीच फाईल कॉपी करतात आणि त्याला 'स्मॉल डिप्लॉयमेंट' म्हणतात.

4 GB च्या VPS वर दोन वर्कर चालवा, Postgres ला त्याच compose प्रोजेक्टमध्ये ठेवा आणि मोजमाप करा. docker stats --no-stream प्रत्येक कंटेनरसाठी त्याच्या प्रत्यक्ष रेसिडेंट मेमरीची एक ओळ प्रिंट करते, जी कोणत्याही व्हेंडरने किंवा ब्लॉगने दिलेल्या आकड्यांपेक्षा अधिक अचूक असते. जर एखादा कंटेनर मर्यादेशिवाय मेमरी वापरत असेल, तर त्यावर मर्यादा घाला; memory limits in Docker Compose मध्ये यासाठी लागणारी सिंटॅक्स दिली आहे.

एका VPS वर Activepieces साठी compose फाईल

टॅग पिन करा. latest चा अर्थ असा की पुढील docker compose pull कोणत्याही पूर्वसूचनेशिवाय डेटाबेस स्कीमा बदलू शकते. 4 ऑगस्ट 2026 रोजी, प्रोजेक्टने स्वतःच्या compose फाईलमध्ये 0.86.3 हे व्हर्जन पिन केले आहे.

प्रथम, डॉक्युमेंटेशनमध्ये नमूद केलेल्या लांबीनुसार दोन secrets तयार करा.

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 वेबहूक URL तयार करताना तुमच्या सार्वजनिक IP पत्त्याचा वापर करण्याचा प्रयत्न करते. तुम्ही थर्ड पार्टीला दिलेली प्रत्येक वेबहूक याच व्हॅल्यूवरून तयार होते, त्यामुळे जर ती अजूनही 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) असलेला रिव्हर्स प्रॉक्सी लावत नाही, तोपर्यंत बाहेरून ॲपपर्यंत काहीही पोहोचणार नाही, ज्याबद्दल running Traefik in front of several compose apps मध्ये माहिती दिली आहे. handling secrets in compose env files मध्ये सांगितल्याप्रमाणे, .env ला मोड 600 वर ठेवा आणि git पासून दूर ठेवा.

बॅकअप ज्याकडे प्रत्येक मार्गदर्शिका दुर्लक्ष करते

ही सर्व साधने साठवलेली क्रेडेन्शियल्स एनक्रिप्ट करतात, त्यामुळे केवळ डेटाबेस डंप हा पूर्ण बॅकअप नसतो. तुम्हाला डंप आणि तो डिक्रिप्ट करणारी की (key) दोन्हीची आवश्यकता असते. धोका असा आहे की, यातील बहुतेक साधने तुमच्या नकळत ती की तयार करतात आणि अशा ठिकाणी साठवतात जिथे तुम्ही बॅकअप घेत नाही.

n8n हे याचे सर्वात स्पष्ट उदाहरण आहे. जर तुम्ही N8N_ENCRYPTION_KEY सेट केले नाही, तर n8n "पहिल्यांदा सुरू झाल्यावर आपोआप एक रँडम एनक्रिप्शन की तयार करते आणि ती ~/.n8n फोल्डरमध्ये सेव्ह करते", आणि त्यानंतर डेटाबेसमध्ये जाण्यापूर्वी क्रेडेन्शियल्स एनक्रिप्ट करण्यासाठी ती की वापरते. जर तुम्ही Postgres डंप केला आणि तो नवीन व्हॉल्यूम असलेल्या फ्रेश कंटेनरवर रिस्टोर केला, तर वर्कफ्लो परत येतील पण सर्व क्रेडेन्शियल्स अशी सायफरटेक्स्ट असतील जी कोणीही वाचू शकणार नाही. व्हेरिएबल स्पष्टपणे सेट करा आणि जेव्हा तुम्ही queue मोड चालवता तेव्हा प्रत्येक वर्करवर तीच व्हॅल्यू सेट करा.

Node-RED ची स्थितीही अशीच आहे. क्रेडेन्शियल्स त्यांच्या स्वतःच्या एनक्रिप्टेड फाईलमध्ये असतात आणि की credentialSecret ही settings.js मध्ये असते. जेव्हा तुम्ही ती सेट करत नाही, तेव्हा रनटाइम एक रँडम की तयार करतो आणि ती /data मधील स्वतःच्या सेटिंग स्टोअरमध्ये _credentialSecret अंतर्गत सेव्ह करतो. स्टॉक सेटिंग फाईलमध्ये याचा परिणाम स्पष्ट केला आहे: "एकदा तुम्ही हा प्रॉपर्टी सेट केला की तो बदलू नका - असे केल्यास node-red ला तुमची विद्यमान क्रेडेन्शियल्स डिक्रिप्ट करता येणार नाहीत आणि ती कायमची नष्ट होतील." केवळ flows फाईलचा नाही, तर संपूर्ण /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

त्यानंतर बॅकअप काम करतो का याची खात्री करा, कारण न तपासलेला बॅकअप म्हणजे केवळ एक अंदाज असतो. डंप एका अशा स्क्रॅच compose प्रोजेक्टमध्ये रिस्टोर करा जो मुद्दाम वेगळा AP_ENCRYPTION_KEY वापरतो, त्यानंतर सेव्ह केलेले कनेक्शन वापरणारा एक फ्लो चालवा. तो अयशस्वी होईल, कारण डेटाबेसमधील सायफरटेक्स्ट दुसऱ्या की ने तयार केली होती. आता .env मधील खऱ्या की सह रिस्टोर पुन्हा करा आणि तोच फ्लो यशस्वीपणे चालेल. हे दोन प्रयोगच तुमचा बॅकअप खरा बॅकअप असल्याचा एकमेव पुरावा आहेत. दोन्ही फाईल्स एका ठराविक वेळापत्रकानुसार सर्व्हरच्या बाहेर restic backups from a VPS वापरून पाठवा, कारण एकाच डिस्कवर असलेला बॅकअप डिस्क खराब झाल्यावर नष्ट होतो.

n8n वर कधी राहावे

जर तुमचे काम तुमच्या स्वतःच्या कंपनीपुरते मर्यादित असेल, तर n8n वरच राहा, कारण Sustainable Use License नेमकी याचीच परवानगी देते. जर तुम्हाला विविधतेची गरज असेल तर n8n वर राहा, कारण 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 ला सर्वात जवळचा self-hosted पर्याय कोणता आहे?

Activepieces. ही संकल्पना n8n सारखीच आहे: एक व्हिज्युअल बिल्डर जिथे ट्रिगर फ्लो सुरू करतो आणि प्रत्येक पायरी एका सेवेला कॉल करते, ज्यामध्ये कनेक्टर्सची मोठी कॅटलॉग उपलब्ध असते. याचा मुख्य भाग MIT लायसन्स अंतर्गत आहे, तो Docker वर Postgres आणि Redis वापरून चालतो आणि त्याचे 'pieces' हे LLM क्लायंटसाठी MCP सर्व्हर म्हणूनही काम करतात. लक्षात घेण्यासारखी गोष्ट म्हणजे, API ॲक्सेस आणि एजंट फीचर्स हे कमर्शियल एंटरप्राइझ डिरेक्टरीजमध्ये आहेत, त्यामुळे Community Edition इन्स्टन्स प्रोग्रॅमॅटिकली चालवण्याऐवजी वेब इंटरफेसद्वारे चालवला जातो.

Activepieces खरोखर ओपन सोर्स आहे का?

याचा मुख्य भाग MIT लायसन्स अंतर्गत आहे. दोन डिरेक्टरीज, packages/ee/ आणि packages/server/api/src/app/ee, कमर्शियली लायसन्स आहेत आणि त्या फीचर्सचा तुमच्या सर्व्हरवर वापर करण्यासाठी सशुल्क लायसन्सची आवश्यकता असते. वेंडरच्या प्राइसिंग पेजनुसार Agents आणि Chat, Projects, API ॲक्सेस, single sign-on, user roles, audit logs, secret managers, branding आणि Git sync हे Community Edition च्या बाहेर आहेत, तर runs, users आणि flows वर कोणतीही मर्यादा नाही. त्यामुळे ऑटोमेशन तयार करण्यासाठी आणि चालवण्यासाठी हे खरोखर ओपन सोर्स आहे, परंतु टीम आणि गव्हर्नन्स लेयरसाठी ते ओपन सोर्स नाही.

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 साईझिंग लागते. 4 GB च्या VPS वर दोन वर्कर्ससह सुरुवात करणे योग्य ठरेल आणि docker stats --no-stream तुमच्या फ्लोच्या रनिंग दरम्यान प्रत्यक्ष वापर किती होतो हे स्पष्ट करते.

रिस्टोअर यशस्वी होण्यासाठी कशाचा बॅकअप घेणे आवश्यक आहे?

डेटाबेस डंप आणि एन्क्रिप्शन की, या दोन्हीचा एकत्र बॅकअप घ्या. Activepieces साठी, हे activepieces डेटाबेसचे pg_dump आणि AP_ENCRYPTION_KEY साठवणारी .env फाईल आहे. n8n साठी, हा डेटाबेस आणि N8N_ENCRYPTION_KEY आहे, जे तुम्ही सेट न केल्यास n8n ने ~/.n8n फोल्डरमध्ये तयार केलेले असते. Node-RED साठी, संपूर्ण /data व्हॉल्यूमचा बॅकअप घ्या, कारण क्रेडेंशियल्स फाईल आणि ती डिक्रिप्ट करणारी की दोन्ही तिथेच असतात. Windmill हा अपवाद आहे: त्याची वर्कस्पेस की त्याच्या स्वतःच्या Postgres डेटाबेसमध्ये असते, त्यामुळे डंपमध्ये सर्व काही समाविष्ट असते आणि त्या डंपला सिक्रेट्सप्रमाणेच सुरक्षित ठेवणे आवश्यक आहे.

मी माझे n8n वर्कफ्लो दुसऱ्या टूलमध्ये इम्पोर्ट करू शकतो का?

नाही. हे प्रोजेक्ट्स त्यांचे स्वतःचे फ्लो फॉरमॅट इम्पोर्ट आणि एक्सपोर्ट करतात, n8n चे नाही. मायग्रेशनचा अर्थ असा आहे की प्रत्येक फ्लो नवीन बिल्डरमध्ये पुन्हा तयार करणे आणि प्रत्येक क्रेडेंशियल मूळ सेवेवरून पुन्हा तयार करणे. हे काम म्हणजे स्विच करण्याचा खरा खर्च आहे, त्यामुळे निर्णय घेण्यापूर्वी तुमच्या फ्लोची संख्या मोजा. बारा फ्लो म्हणजे एका दुपारचे काम आहे. दोनशे फ्लो म्हणजे एक मोठा प्रोजेक्ट आहे आणि त्यांना पुन्हा तयार करण्यापेक्षा queue mode आणि Postgres वापरून n8n चा मेमरी वापर सुधारणे सहसा स्वस्त पडते.