n8n-க்கு சிறந்த மாற்றுகள் எவை? முழுமையான ஒப்பீடு

n8n-க்கு மாற்றாக எதைப் பயன்படுத்தலாம்

VPS (virtual private server)-ல் n8n-க்கு மாற்றாக நீங்கள் பயன்படுத்தக்கூடிய தகுதியான கருவிகள் Activepieces, Windmill, Node-RED, Automatisch மற்றும் Huginn ஆகும். பெரும்பாலான பயனர்கள் n8n-ஐ பயன்படுத்தும் முறைக்கு Activepieces மிகச்சிறந்த மாற்றாகும், மேலும் இதன் மையப்பகுதி MIT உரிமம் பெற்றது. Canvas-ல் பெட்டிகளை இழுத்து வைப்பதை விட, Python அல்லது TypeScript மூலம் நிரல் எழுத விரும்பும் குழுக்களுக்கு Windmill பொருத்தமானது. Node-RED ஒரு சிறிய கருவி, இதற்கு எந்தவிதமான database-ம் தேவையில்லை.

பல வாசகர்கள் தற்போதுள்ள கருவியிலேயே தொடர்வது நல்லது. n8n உரிமம் உள்நாட்டு வணிகப் பயன்பாட்டிற்கு அனுமதி அளிக்கிறது, எனவே உங்கள் நிறுவனத்திற்காக நீங்கள் flows-களை இயக்கினால், உரிமம் உங்களுக்கு ஒரு சிக்கலாக இருக்காது. இடம்பெயர்வு (migration) இலவசமானது அல்ல. இந்த பட்டியலில் உள்ள எந்தவொரு கருவியும் n8n export கோப்புகளைப் படிப்பதில்லை, எனவே ஒவ்வொரு flow-வையும் நீங்கள் கைமுறையாக மீண்டும் உருவாக்க வேண்டும் மற்றும் அனைத்து credential-களையும் மீண்டும் உள்ளிட வேண்டும். n8n-ஐ நிறுவுவது ஒரு தனிப்பணியாகும், இது Docker மற்றும் HTTPS மூலம் VPS-ல் n8n நிறுவுதல் பகுதியில் விவரிக்கப்பட்டுள்ளது, மேலும் Zapier மற்றும் Make உடன் n8n ஒப்பீடு பகுதியில் இந்த வகை கருவிகள் எவ்வாறு hosted சேவைகளுடன் ஒப்பிடப்படுகின்றன என்பது விளக்கப்பட்டுள்ளது.

மக்கள் ஏன் self-hosted n8n-க்கு மாற்றுகளைத் தேடுகிறார்கள்

இரண்டு காரணங்கள் மீண்டும் மீண்டும் முன்வைக்கப்படுகின்றன.

முதலாவது உரிமம் (licence). n8n, Sustainable Use License v1.0-ன் கீழ் வெளியிடப்படுகிறது. இதை அந்தத் திட்டம் open source என்பதற்குப் பதிலாக fair-code என்று அழைக்கிறது. இந்த உரிமம், "மென்பொருளை உங்கள் சொந்த உள் வணிக நோக்கங்களுக்காக அல்லது வணிகம் சாராத அல்லது தனிப்பட்ட பயன்பாட்டிற்காக மட்டுமே பயன்படுத்த அல்லது மாற்றியமைக்க" உரிமையை வழங்குகிறது. மேலும், இந்த மென்பொருளை வணிக ரீதியாக மற்றவர்களுக்கு வழங்குவதைத் தடை செய்கிறது. .ee என்று பெயரில் உள்ள கோப்புகள் மற்றும் கோப்புறைகள் தனித்தனி n8n Enterprise License-ன் கீழ் வருகின்றன. நீங்கள் பணம் செலுத்தும் வாடிக்கையாளர்களுக்காக automations-ஐ இயக்க விரும்பினால், இது ஒரு தடையாகும். நீங்கள் ஒரு உள் செயல்பாட்டுக் குழுவாக (internal operations team) இருந்தால், இது உங்கள் அன்றாடப் பணிகளில் எந்த மாற்றத்தையும் ஏற்படுத்தாது.

இரண்டாவது நினைவகம் (memory). n8n என்பது ஒரு Node.js process ஆகும். workflow இயங்கும்போது அதன் தரவுகள் நினைவகத்தில் இருக்கும். n8n ஆவணங்கள் இதற்கான காரணங்களைக் குறிப்பிடுகின்றன: JSON தரவுகளின் அளவு, binary தரவுகளின் அளவு, workflow-ல் உள்ள nodes-ன் எண்ணிக்கை, Code node, manual executions (இவை editor-க்காக தரவை மீண்டும் நகலெடுக்கும்), மற்றும் ஒரே நேரத்தில் இயங்கும் பிற workflows. ஆவணப்படுத்தப்பட்ட தீர்வு வேறொரு தயாரிப்பிற்கு மாறுவதல்ல. அது queue mode-ஐப் பயன்படுத்தி தனித்தனி worker processes-ஐ இயக்குவது மற்றும் ~/.n8n/database.sqlite-ல் உள்ள இயல்புநிலை SQLite கோப்பிற்குப் பதிலாக Postgres-ஐப் பயன்படுத்துவது ஆகும். பெரிய பணிகளுக்கு batching முறையும் தேவைப்படுகிறது, ஏனெனில் sub-workflow-க்கு தரவை அனுப்பும் Loop Over Items node, ஒரு நேரத்தில் தரவின் ஒரு பகுதியை மட்டுமே நினைவகத்தில் வைத்திருக்கும். வேறொரு இடத்தில் அறுபது flows-ஐ மீண்டும் உருவாக்குவதற்கு முன்பு இதை முயற்சி செய்து பாருங்கள்.

n8n-க்கு மாற்றாக தற்போது பராமரிக்கப்படும் self-hosted கருவிகள் எவை

License உரையை வாசிப்பது எளிது, எனவே அனைவரும் உரிமங்களை ஒப்பிடுகிறார்கள். ஆனால் திட்டத்தின் ஆரோக்கியத்தை (project health) கவனிப்பது எளிதல்ல. இந்த ஒப்பீட்டில் உள்ள 6 திட்டங்கள் மற்றும் 4 August 2026 அன்று அவை ஒவ்வொன்றிற்கும் கடைசியாக வெளியிடப்பட்ட 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 நாட்களுக்கு முந்தையது. மேலும், அதன் default branch-ல் 15 January 2026 முதல் எந்த commit-ம் செய்யப்படவில்லை. Huginn கடைசியாக 1447 நாட்களுக்கு முன்பு ஒரு release-ஐ வெளியிட்டது, ஆனால் அதன் commit log இந்த மாதம் வரை செயலில் உள்ளது. இது நேர்மாறான ஒரு சூழல்: குறியீடு (code) தொடர்ந்து மாறுகிறது, ஆனால் release-கள் வெளியிடப்படவில்லை. எனவே, இதை இயக்குவது என்பது tag செய்யப்படாத ஒரு image-ஐ இயக்குவதாகும்.

எந்தவொரு ஒப்பீட்டையும் நம்புவதற்கு முன், இதையும் சேர்த்து, நீங்களே சரிபார்க்கவும். GitHub-ல் அந்தத் திட்டத்தின் releases பக்கத்தைத் திறந்து, அதன் default branch-க்கான commit பட்டியலைப் பார்க்கவும். புதிய release இருந்து, commit log அமைதியாக இருந்தால், அந்தத் திட்டம் தேக்க நிலையில் உள்ளது என்று அர்த்தம். புதிய commit-கள் இருந்து, பல ஆண்டுகளாக release இல்லை என்றால், அது யாரும் முறையாகப் பதிப்பு வெளியிடாத குறியீட்டை இயக்கச் சொல்கிறது என்று பொருள்.

Activepieces: மிக நெருக்கமான தேர்வு, மற்றும் மையத்தில் MIT உரிமம்

Activepieces என்பது நேரடியான மாற்றாக அமையும் ஒரு தேர்வாகும். இது triggers மற்றும் steps-களைக் கொண்ட ஒரு visual builder ஆகும்; இதில் steps-கள் pieces என்று அழைக்கப்படுகின்றன. இதன் README-ல் 280-க்கும் மேற்பட்ட pieces இருப்பதாகக் குறிப்பிடப்பட்டுள்ளது. ஒவ்வொரு piece-ம் ஒரு MCP (model context protocol) server-ஆகவும் செயல்படுகிறது, எனவே ஒரு LLM (large language model) client, இந்த connectors-களை tools-ஆகப் பயன்படுத்த முடியும். இதன் மையப்பகுதி MIT உரிமம் பெற்றது. packages/ee/ மற்றும் packages/server/api/src/app/ee ஆகிய இரண்டு directories வணிக ரீதியான உரிமத்தைக் கொண்டுள்ளன; இவற்றில் உள்ளவற்றை உங்கள் சொந்த server-ல் பயன்படுத்த கட்டண ஒப்பந்தம் தேவை.

நீங்கள் migrate செய்வதற்கு முன் இந்த உரிமப் பிரிப்பைப் படித்துப் பார்க்கவும், ஏனெனில் இது பெரும்பாலான MIT திட்டங்களை விட விரிவானது. Activepieces-ன் pricing பக்கம், Community Edition-ஐ "open source, free forever, runs, users, அல்லது flows-க்கு வரம்புகள் இல்லை" என்று விவரிக்கிறது. மேலும், Agents and Chat, Projects, API access மற்றும் முழுமையான நிர்வாக அடுக்கு (single sign-on, user roles, audit logs, secret managers, branding, Git sync) ஆகியவற்றை இதிலிருந்து விலக்கி வைத்துள்ளது. எனவே, Community Edition என்பது வரம்பற்ற flows மற்றும் users-களைக் கொண்ட ஒரு முழுமையான automation engine ஆகும், ஆனால் இதை API மூலம் இயக்க முடியாது. நீங்கள் flows-களை நிரல் ரீதியாக (programmatically) உருவாக்கத் திட்டமிட்டிருந்தால், அதற்கு உரிமம் தேவைப்படும்.

இதன் runtime அமைப்பு ஒரு app container, ஒன்று அல்லது அதற்கு மேற்பட்ட worker containers, Postgres மற்றும் Redis ஆகியவற்றைக் கொண்டது. AP_DB_TYPE=POSTGRES மற்றும் AP_REDIS_TYPE=STANDALONE ஆகியவை இயல்புநிலைத் தேர்வுகள். இதில் embedded database மற்றும் in-process queue (AP_DB_TYPE=PGLITE உடன் AP_REDIS_TYPE=MEMORY) கொண்ட single-container mode உள்ளது. ஆனால், இது "தனிப்பட்ட பயன்பாட்டிற்கு அல்லது சோதனைக்கு மட்டுமே" என்று ஆவணங்கள் குறிப்பிடுகின்றன. இதை அப்படியே எடுத்துக்கொள்ளுங்கள். அந்த முறைகளில் ஒன்றுக்கு மேற்பட்ட instances-களை இயக்க முடியாது, எனவே இதிலிருந்து வளர்வது என்பது ஒரு migration ஆகும், வெறும் flag மாற்றம் அல்ல.

Windmill: code first, மற்றும் பார்ப்பதற்கு இருப்பதை விட அதிக எடையுடையது

Windmill ஆனது Python, TypeScript, Go, Bash மற்றும் SQL ஆகியவற்றில் scripts-ஐ இயக்கி, அவற்றை flows-ஆக ஒருங்கிணைக்கிறது. உங்கள் automations பெரும்பாலும் code-ஆகவும், அவற்றை இணைக்கும் சிறிய glue code-ஆகவும் இருந்தால், node canvas-ஐ விட இது சிறப்பாகப் பொருந்தும்.

இதன் உரிமத்தில் (licence) கவனம் தேவை. enterprise feature flag இல்லாமல் compile செய்யப்படும்போது, இதன் source AGPLv3 உரிமத்தில் உள்ளது. ghcr.io/windmill-labs/windmill-ல் வெளியிடப்படும் images, Community Edition ஆகும். இதில் open source அல்லாத code-கள் உள்ளன, இவை குறிப்பிட்ட ஒதுக்கீடுகளுக்குள் (quotas) பயன்படுத்த இலவசம். Windmill-ன் pricing பக்கத்தில் இந்த ஒதுக்கீடுகள் 50 பயனர்கள், 3 workspaces மற்றும் 10 GiB workspace object storage என நிர்ணயிக்கப்பட்டுள்ளன; executions-க்கு வரம்பு இல்லை. ஒரு தனிநபர் அல்லது சிறிய குழுவிற்கு இந்த வரம்பு மிக அதிகம், எனவே நடைமுறைச் சிக்கல் ஒதுக்கீடு பற்றியது அல்ல. நீங்கள் இயக்கும் binary, AGPL build கிடையாது என்பதே முக்கியமானது.

எடை (weight) என்பது கவனிக்க வேண்டிய மற்றொரு காரணி. Windmill-ன் சொந்த docker-compose.yml-ல் ஒரு Postgres 16 database, ஒரு server, தலா 2048M memory வரம்பு கொண்ட மூன்று default workers, ஒரு native worker மற்றும் ஒரு Caddy proxy ஆகியவை உள்ளன. ஆவணப்படுத்தப்பட்ட பொதுவான விதி "1 vCPU-க்கு 1 worker மற்றும் 1-2 GB RAM" என்பதாகும். சிறிய server-ல் நீங்கள் replica எண்ணிக்கையைக் குறைக்கலாம். ஆனால், நீங்கள் எதைக் குறைக்கிறீர்கள் என்பதை அறிந்திருக்க வேண்டும், ஏனெனில் உங்கள் jobs-ஐ இயக்குபவை இந்த workers தான்.

Windmill-ன் AI அம்சங்கள் build-time உதவியாக ஆவணப்படுத்தப்பட்டுள்ளன: code generation, flow building, chat மற்றும் form filling. இதற்கு முதலில் workspace settings-ல் ஒரு model provider resource-ஐச் சேர்க்க வேண்டும். உங்களுக்குத் தேவை ஒரு schedule-ல் இயங்கி tools-ஐ அழைக்கும் agent step என்றால், n8n-ன் AI Agent node இன்னும் நேரடியான வழியாகும், மேலும் n8n-ல் AI agent உருவாக்குதல் அந்த முறையை விளக்குகிறது.

Node-RED: தரவுத்தளம் இல்லாத மிகச்சிறிய அமைப்பு

Node-RED என்பது Apache 2.0 உரிமம் கொண்டது, இது இந்த ஒப்பீட்டில் மிகவும் தாராளமான உரிமமாகும். இது /data volume-ஐக் கொண்ட ஒரே ஒரு Node.js process ஆகும். இதில் Postgres கிடையாது. Redis கிடையாது. இதை nodered/node-red:5.0.4 பதிப்பில் நிலைநிறுத்தவும், இதுவே தற்போதைய release ஆகும்.

இது IoT (internet of things) இணைப்புகளிலிருந்து உருவானது, எனவே இது connector-ஐ விட event-அடிப்படையிலான அமைப்பைக் கொண்டது. மூன்றாம் தரப்பு சேவைகளுக்கான nodes சமூக நூலகத்திலிருந்து (community library) கிடைக்கின்றன, அவற்றின் தரம் மாறுபடும்; சிறிய footprint-க்காக நீங்கள் செய்யும் சமரசம் இதுவாகும். இதில் உயர்தர AI agent படிநிலை எதுவும் இல்லை. Webhooks மற்றும் message-queue traffic-ஐக் கையாளும் ஒரு சிறிய VPS-க்கு, இதுவே மிகக் குறைந்த எடையுள்ள மற்றும் விரைவாகச் செயல்படும் கருவியாகும், இது சில நொடிகளில் தொடங்கிவிடும்.

Huginn மற்றும் Automatisch: முதலில் commit log-ஐ சரிபார்க்கவும்

Huginn என்பது MIT உரிமம் பெற்றது, Ruby on Rails-ல் எழுதப்பட்டது, இதற்கு MySQL அல்லது PostgreSQL தேவை. இது ஒரு மூலத்தை கண்காணித்து நிகழ்வுகளை (events) வெளியிடும் முகவர்களை (agents) அடிப்படையாகக் கொண்டது. இது flow canvas மாதிரியிலிருந்து மாறுபட்டது மற்றும் இதில் LLM வசதி இல்லை. இதன் குறியீட்டில் இன்னும் மாற்றங்கள் (commits) செய்யப்படுகின்றன, ஆனால் கடைசியாக வெளியிடப்பட்ட பதிப்பு (tagged release) August 2022-ல் வந்தது. எனவே, இதை இயக்குவது என்பது default branch-லிருந்து உருவாக்கப்பட்ட ghcr.io/huginn/huginn image-ஐப் பயன்படுத்துவதாகும். உங்கள் தேவைக்கு agent மாதிரி பொருத்தமாக இருந்தால் மட்டும் இதைத் தேர்ந்தெடுக்கவும்; n8n-க்கு மாற்றாக இதைப் பயன்படுத்த வேண்டாம்.

Automatisch என்பது அதன் .ee கோப்புகளைத் தவிர்த்து AGPL-3.0 உரிமம் கொண்டது. இது n8n-ன் எளிமையான வடிவம் போலத் தோன்றுகிறது: இதற்கு Postgres, Redis மற்றும் சிறிய அளவிலான பயன்பாடுகள் தேவை. இதுவே single-deploy பயிற்சிகளில் அடிக்கடி பரிந்துரைக்கப்படும் கருவியாகும். இதன் வெளியீட்டு வரலாற்றைப் பார்க்கும்போது, காத்திருப்பது நல்லது. ஒரு வருடமாக புதிய வெளியீடு இல்லாமலும், அரை வருடமாக எந்த மாற்றமும் (commit) இல்லாமலும் இருப்பது, நீங்கள் ஏற்கனவே இதைப் பயன்படுத்திக் கொண்டிருந்தால் கவலைப்பட வேண்டிய விஷயமல்ல. ஆனால், புதிய production deployment-ஐத் தொடங்க இது சரியான காரணமல்ல.

Activepieces stack-ன் உண்மையான RAM செலவு

Idle மற்றும் working memory அளவீடுகளை யாரும் உங்களுக்காக வெளியிட முடியாது, ஏனெனில் அது உங்கள் flows மற்றும் அவை கையாளும் தரவின் அளவைப் பொறுத்தது. ஒவ்வொரு vendor-ம் பரிந்துரைக்கும் பட்ஜெட் அளவை மட்டுமே நீங்கள் பார்க்க முடியும். Activepieces கீழே உள்ள கட்டமைப்பை ஆவணப்படுத்துகிறது, அதில் உள்ள எண்களை விட அதன் அருகிலுள்ள வாக்கியமே முக்கியமானது: "ஒரு concurrency-1 worker, ஒரு flow-ன் முழு காலத்திற்கும் (10 நிமிடம் வரை) பிஸியாக இருக்கும், எனவே trigger rate-ஐ வைத்து அல்ல, concurrent flows-ஐ வைத்து அளவை முடிவு செய்யுங்கள்."

[
  {
    "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 GB ஆகும், இது ஒரு நேரத்தில் ஒரே ஒரு flow-ஐ மட்டுமே இயக்கும். Postgres-க்கு 4 GB ஒதுக்க பரிந்துரைக்கப்படுகிறது. இந்த project-ன் compose file ஐந்து worker replicas-ஐக் கொண்டுள்ளது, எனவே repository-ல் உள்ள அந்த அளவீட்டின்படி, உங்கள் flows எதையும் செய்வதற்கு முன்பே இந்த stack சுமார் 11 GB-ஐக் கேட்கிறது. ஒற்றை கருவிக்கான பயிற்சிகள் (tutorials) அந்த file-ஐ அப்படியே நகலெடுத்து, அதை ஒரு சிறிய deployment என்று அழைக்கின்றன.

4 GB VPS-ல், இரண்டு worker-களை மட்டும் இயக்கவும், Postgres-ஐ அதே compose project-ல் வைத்து, அளவீடு செய்யவும். docker stats --no-stream ஒவ்வொரு container-க்கும் அதன் உண்மையான resident memory-ஐ ஒரு வரியில் அச்சிடும், இது எந்தவொரு vendor அல்லது blog வெளியிடும் எண்களை விடவும் துல்லியமானது. ஒரு container வரம்பின்றி வளர்ந்தால், அதற்கு வரம்பு விதிக்கவும், Docker Compose-ல் memory limits அதற்கான syntax-ஐக் காட்டுகிறது.

ஒரு VPS-ல் Activepieces-க்கான compose கோப்பு

Tag-ஐ pin செய்யவும். latest என்பது, எச்சரிக்கை இன்றி database schema-வை மாற்றும் திறன் கொண்டது என்பதால் docker compose pull-ஐ கவனமாக கையாளவும். ஆகஸ்ட் 4, 2026 நிலவரப்படி, இந்த project அதன் சொந்த compose கோப்பில் 0.86.3 என்ற version-ஐயே pin செய்துள்ளது.

ஆவணத்தில் குறிப்பிடப்பட்டுள்ள நீளத்தைப் பயன்படுத்தி, முதலில் இரண்டு 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 முகவரியாக இருக்க வேண்டும். இல்லையெனில், webhook URL-களை உருவாக்கும்போது Activepieces உங்கள் பொது IP முகவரியைப் பயன்படுத்த முயற்சிக்கும். நீங்கள் மூன்றாம் தரப்பினருக்கு வழங்கும் ஒவ்வொரு webhook-ம் அந்த மதிப்பிலிருந்தே உருவாக்கப்படுகிறது. எனவே, அது localhost-ஐக் குறிப்பிட்டால், நீங்கள் மற்றொரு சேவையில் பதிவிடும் URL உங்கள் server-ஐ ஒருபோதும் அடையாது.

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:

அந்தக் கோப்பு, project-ன் சொந்த compose கோப்பில் நான்கு மாற்றங்களைச் செய்த பதிப்பாகும்: worker எண்ணிக்கை ஐந்திலிருந்து இரண்டாகக் குறைக்கப்பட்டுள்ளது, published port அனைத்து interface-களுக்குப் பதிலாக 127.0.0.1-ல் மட்டும் பிணைக்கப்பட்டுள்ளது (bind), replicas கொண்ட service-ல் container பெயர்களை நிலையாக வைக்க முடியாது என்பதால் அவை நீக்கப்பட்டுள்ளன, மேலும் compose தானாகவே network-ஐ உருவாக்கும் என்பதால் explicit network block நீக்கப்பட்டுள்ளது.

docker compose up -d
docker compose ps

ஒவ்வொரு service-ம் Up நிலையைக் காட்ட வேண்டும், இதில் இரண்டு worker container-களும் அடங்கும். ஒரு container மீண்டும் மீண்டும் restart ஆகிறது என்றால், அதற்கான காரணத்தை docker compose logs worker-ல் பார்க்கலாம். எனவே, எதையும் மாற்றும் முன் அதை வாசிக்கவும். நீங்கள் TLS (transport layer security) கொண்ட reverse proxy-ஐ முன்னால் வைக்கும் வரை, port binding மூலம் வெளியிலிருந்து எந்தத் தொடர்பும் app-ஐ அடையாது. இது பல compose app-களுக்கு முன்னால் Traefik-ஐ இயக்குதல் பகுதியில் விளக்கப்பட்டுள்ளது. compose env கோப்புகளில் secrets-ஐக் கையாளுதல் பகுதியில் கூறியபடி, .env-ஐ mode 600-ல் வைத்திருக்கவும், அதை git-ல் சேர்க்க வேண்டாம்.

ஒவ்வொரு வழிகாட்டியும் தவிர்க்கும் backup

இந்தக் கருவிகள் அனைத்தும் சேமிக்கப்பட்ட credentials-ஐ encrypt செய்கின்றன, எனவே database dump மட்டும் முழுமையான backup ஆகாது. உங்களுக்கு dump-உம், அதை decrypt செய்யும் key-யும் தேவை. பெரும்பாலான கருவிகள் இந்த key-யை பின்னணியில் தானாகவே உருவாக்கி, நீங்கள் backup செய்யாத இடத்தில் சேமித்து வைப்பதே இதில் உள்ள சிக்கல்.

n8n இதற்கு மிகச்சிறந்த உதாரணம். நீங்கள் N8N_ENCRYPTION_KEY-ஐ அமைக்கவில்லை என்றால், n8n "முதல் முறை இயங்கும்போது தானாகவே ஒரு random encryption key-யை உருவாக்கி ~/.n8n கோப்புறையில் சேமிக்கும்", பின்னர் credentials database-க்கு செல்லும் முன்பே அதை encrypt செய்ய இந்த key-யைப் பயன்படுத்தும். நீங்கள் Postgres-ஐ dump செய்து, புதிய volume கொண்ட புதிய container-ல் restore செய்தால், workflows திரும்பி வரும், ஆனால் அனைத்து credentials-ம் யாராலும் படிக்க முடியாத ciphertext-ஆக இருக்கும். எனவே, இந்த variable-ஐ தெளிவாக அமைக்கவும்; queue mode-ல் இயக்கும்போது ஒவ்வொரு worker-லும் அதே மதிப்பை அமைக்கவும்.

Node-RED-லும் இதே நிலைதான். Credentials அதன் சொந்த encrypted கோப்பில் இருக்கும், அதற்கான key credentialSecret ஆகும், இது settings.js-ல் உள்ளது. நீங்கள் இதை அமைக்கவில்லை என்றால், runtime ஒரு random key-யை உருவாக்கி அதை /data-க்குள் உள்ள அதன் settings store-ல் _credentialSecret என்ற பெயரில் சேமிக்கும். அதன் இயல்புநிலை settings கோப்பு இதற்கான விளைவை விளக்குகிறது: "இந்த property-ஐ அமைத்த பிறகு, அதை மாற்ற வேண்டாம் - மாற்றினால் node-red-ஆல் உங்கள் தற்போதைய credentials-ஐ decrypt செய்ய முடியாது, அவை நிரந்தரமாக இழக்கப்படும்." எனவே, flows கோப்பை மட்டும் backup செய்யாமல், முழு /data volume-ஐயும் backup செய்யவும்.

Activepieces அதன் AP_ENCRYPTION_KEY-ஐ உங்கள் .env-ல் வைத்திருக்கும், இது "connections-ஐ encrypt செய்யப் பயன்படும் 32-character (16-byte) hexadecimal key" என்று ஆவணப்படுத்தப்பட்டுள்ளது. Huginn அதன் APP_SECRET_TOKEN-ஐ environment-ல் வைத்திருக்கும். Automatisch-ல் மூன்று உள்ளன: ENCRYPTION_KEY, WEBHOOK_SECRET_KEY மற்றும் APP_SECRET_KEY. ஒவ்வொரு முறையும் இந்த secret ஒரு environment கோப்பில் இருக்கும், அதாவது அந்த environment கோப்பும் backup-ன் ஒரு பகுதி.

Windmill இதில் விதிவிலக்கு. அதன் variables மற்றும் secrets ஒரு workspace-க்கு உரிய symmetric key மூலம் encrypt செய்யப்படுகின்றன. Windmill இந்த key-யை அதன் சொந்த database-லேயே சேமிப்பதால், ஒரு Postgres dump-ல் இரண்டுமே அடங்கிவிடும். இது restore செய்வதற்கு வசதியானது, ஆனால் அந்த dump கோப்பிலேயே அனைத்து secrets-ம் இருப்பதால், அந்த கோப்பை secrets-ஐப் போலவே பாதுகாப்பாக வைத்திருக்க வேண்டும்.

மேலே உள்ள Activepieces stack-க்கு, backup என்பது இரண்டு கோப்புகள்:

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

பின்பு, backup சரியாக வேலை செய்கிறதா என்று சோதிக்கவும், ஏனெனில் சோதிக்கப்படாத backup என்பது வெறும் ஊகம் மட்டுமே. வேண்டுமென்றே வேறு ஒரு AP_ENCRYPTION_KEY-ஐப் பயன்படுத்தும் ஒரு scratch compose project-ல் dump-ஐ restore செய்யவும், பின்னர் சேமிக்கப்பட்ட connection-ஐப் பயன்படுத்தும் ஒரு flow-வை இயக்கவும். அது தோல்வியடையும், ஏனெனில் database-ல் உள்ள ciphertext வேறொரு key-யால் உருவாக்கப்பட்டது. இப்போது .env-ல் உள்ள உண்மையான key-யைப் பயன்படுத்தி மீண்டும் restore செய்யவும், அப்போது அதே flow சரியாக இயங்கும். இந்த இரண்டு சோதனைகள் மட்டுமே உங்கள் backup உண்மையானது என்பதற்கான சான்று. restic backups from a VPS மூலம் இந்த இரண்டு கோப்புகளையும் அட்டவணைப்படி server-க்கு வெளியே அனுப்பவும், ஏனெனில் ஒரே disk-ல் இருக்கும் backup அந்த disk பழுதடைந்தால் அழிந்துவிடும்.

n8n-ல் எப்போது தொடர வேண்டும்

உங்கள் நிறுவனத்திற்குள்ளேயே பணி நடைபெறுகிறது என்றால், n8n-ல் தொடருங்கள். ஏனெனில், Sustainable Use License இதற்குத்தான் அனுமதி அளிக்கிறது. உங்களுக்குப் பல்வேறு வசதிகள் தேவைப்பட்டால், n8n-ல் தொடருங்கள்; ஏனெனில் இதில் 1500-க்கும் மேற்பட்ட integrations உள்ளன. மேலும், LangChain-ஐ அடிப்படையாகக் கொண்ட இதன் AI Agent node, தயாராக உள்ள agent steps-க்கு இணையற்றது. Claude மூலம் n8n workflows-ஐ இயக்குதல் இது நடைமுறையில் எப்படிச் செயல்படுகிறது என்பதைக் காட்டுகிறது.

automation core-க்கு தாராளமான உரிமம் (permissive licence) மற்றும் முழுமையாகப் புரிந்துகொள்ளக்கூடிய stack தேவைப்பட்டால், Activepieces-க்கு மாறுங்கள். உங்கள் workflows உண்மையில் user interface கொண்ட code-ஆக இருந்தால், Windmill-க்கு மாறுங்கள். உங்கள் server சிறியதாக இருந்து, பணிகள் event-வடிவில் இருந்தால், Node-RED-க்கு மாறுங்கள். n8n அதிக resource-ஐப் பயன்படுத்துகிறது என்று ஏதோ ஒரு benchmark கூறுகிறது என்பதற்காக மட்டும் மாறாதீர்கள். முதலில் உங்கள் instance-ன் செயல்பாட்டை நீங்களே அளவிடுங்கள். பிறகு 2026-ல் எவற்றை self-host செய்வது பயனுள்ளது என்பதைப் படித்துவிட்டு, ஒருமுறை மட்டும் முடிவெடுங்கள். ஏனெனில், இரண்டாவது முறை இடம்பெயர்வதற்கும் முதல் முறைக்கு ஆகும் அதே செலவுதான் ஆகும்.

FAQ

n8n-க்கு மாற்றாக உள்ளவற்றில் எது n8n-க்கு மிக நெருக்கமானது?

Activepieces. இதுவும் அதே போன்ற ஒரு கருத்தாக்கம் தான்: ஒரு trigger மூலம் flow-ஐத் தொடங்கி, ஒவ்வொரு படியிலும் ஒரு service-ஐ அழைக்கும் visual builder, இதில் ஏராளமான connectors உள்ளன. இதன் core பகுதி MIT உரிமம் பெற்றது; இது Docker-ல் Postgres மற்றும் Redis கொண்டு இயங்குகிறது. இதன் pieces, LLM clients-க்கான MCP servers ஆகவும் செயல்படுகின்றன. கவனிக்க வேண்டிய விஷயம் என்னவென்றால், API access மற்றும் agent அம்சங்கள் வணிக ரீதியான enterprise directories-ல் உள்ளன. எனவே, Community Edition-ஐ programmatically இயக்குவதை விட, அதன் web interface மூலமே இயக்க முடியும்.

Activepieces உண்மையிலேயே open source தானா?

இதன் core பகுதி MIT உரிமத்தின் கீழ் open source ஆகும். packages/ee/ மற்றும் packages/server/api/src/app/ee ஆகிய இரண்டு directories வணிக ரீதியான உரிமம் பெற்றவை. அந்த அம்சங்களை உங்கள் server-ல் பயன்படுத்த கட்டண உரிமம் தேவை. விற்பனையாளரின் pricing பக்கத்தின்படி, Agents and Chat, Projects, API access, single sign-on, user roles, audit logs, secret managers, branding மற்றும் Git sync ஆகியவை Community Edition-க்கு வெளியே உள்ளன. அதே சமயம், runs, users மற்றும் flows ஆகியவற்றிற்கு வரம்பு இல்லை. எனவே, automations-ஐ உருவாக்கவும் இயக்கவும் இது முழுமையாக open source, ஆனால் team மற்றும் governance அடுக்குக்கு இது open source அல்ல.

Activepieces-க்கு ஒரு VPS-ல் எவ்வளவு RAM தேவை?

Activepieces ஆவணங்களின்படி, ஒவ்வொரு worker-க்கும் 0.5 vCPU மற்றும் 1 GB RAM, app container-க்கு 1 vCPU மற்றும் 1 GB RAM, Postgres-க்கு 4 GB மற்றும் Redis-க்கு 1 GB RAM தேவைப்படுகிறது. ஒரு worker ஒரு நேரத்தில் ஒரு flow-ஐ மட்டுமே அதன் முழு காலத்திற்கும் கையாளும். எனவே, triggers எவ்வளவு அடிக்கடி இயங்குகின்றன என்பதை விட, ஒரே நேரத்தில் எத்தனை flows இயங்குகின்றன என்பதைப் பொறுத்தே நீங்கள் அளவை (sizing) தீர்மானிக்க வேண்டும். Repository-ல் உள்ள compose file ஐந்து workers-ஐக் கொண்டுள்ளது, இது சுமார் 11 GB அளவைக் குறிக்கிறது. 4 GB VPS-ல் இரண்டு workers-ஐக் கொண்டு தொடங்குவது சரியானதாக இருக்கும். உங்கள் flows இயங்கும்போது உண்மையான தேவையை docker stats --no-stream உறுதிப்படுத்தும்.

restore சரியாக வேலை செய்ய எவற்றை backup எடுக்க வேண்டும்?

Database dump மற்றும் encryption key ஆகிய இரண்டையும் சேர்த்து backup எடுக்க வேண்டும். Activepieces-க்கு, activepieces database-ன் ஒரு pg_dump மற்றும் AP_ENCRYPTION_KEY-ஐக் கொண்ட .env கோப்பை backup எடுக்க வேண்டும். n8n-க்கு, database மற்றும் N8N_ENCRYPTION_KEY-ஐ backup எடுக்க வேண்டும். நீங்கள் அதை அமைக்கவில்லை என்றால், n8n அதை ~/.n8n folder-க்குள் உருவாக்கியிருக்கும். Node-RED-க்கு, முழு /data volume-ஐயும் backup எடுக்கவும், ஏனெனில் credentials கோப்பும் அதை decrypt செய்யும் key-யும் அங்கேயே இருக்கும். Windmill இதற்கு விதிவிலக்கு: அதன் workspace key அதன் சொந்த Postgres database-க்குள்ளேயே இருக்கும், எனவே dump-லேயே அனைத்தும் வந்துவிடும். அந்த dump-ஐ secrets போலவே பாதுகாப்பாக வைத்திருக்க வேண்டும்.

எனது n8n workflows-ஐ மற்றொரு கருவிக்கு import செய்ய முடியுமா?

முடியாது. இந்தத் திட்டங்கள் ஒவ்வொன்றும் அதன் சொந்த flow format-ஐயே import/export செய்கின்றன, n8n-ன் format-ஐ அல்ல. ஒரு migration என்பது ஒவ்வொரு flow-ஐயும் புதிய builder-ல் மீண்டும் உருவாக்குவதையும், ஒவ்வொரு credential-ஐயும் மீண்டும் அமைப்பதையும் குறிக்கும். இந்த உழைப்பே மாறுவதற்கான உண்மையான செலவாகும், எனவே முடிவெடுக்கும் முன் உங்கள் flows-ன் எண்ணிக்கையைக் கணக்கிடுங்கள். பன்னிரண்டு flows என்றால் ஒரு மதிய நேரத்தில் முடித்துவிடலாம். இருநூறு flows என்பது ஒரு பெரிய project. அவற்றை மீண்டும் உருவாக்குவதை விட, queue mode மற்றும் Postgres பயன்படுத்தி n8n-ன் memory பயன்பாட்டைச் சரிசெய்வதே பொதுவாக மலிவானது.