n8n के बेहतरीन self-hosted विकल्प: एक तुलनात्मक विश्लेषण

n8n के स्थान पर क्या उपयोग करें

VPS (virtual private server) पर n8n के जो self-hosted विकल्प विचार करने योग्य हैं, वे हैं Activepieces, Windmill, Node-RED, Automatisch और Huginn। Activepieces उस तरीके के लिए सबसे करीबी विकल्प है जिस तरह से अधिकांश लोग n8n का उपयोग करते हैं, और इसका कोर MIT लाइसेंस प्राप्त है। Windmill उन टीमों के लिए उपयुक्त है जो canvas पर बॉक्स खींचने के बजाय Python या TypeScript लिखना पसंद करती हैं। Node-RED एक छोटा विकल्प है, और इसे किसी भी database की आवश्यकता नहीं होती है।

बहुत से उपयोगकर्ताओं को वहीं बने रहना चाहिए जहाँ वे अभी हैं। n8n का लाइसेंस आंतरिक व्यावसायिक उपयोग की अनुमति देता है, इसलिए यदि आप अपनी कंपनी के लिए flows चलाते हैं, तो लाइसेंस आपके लिए कोई समस्या नहीं है। माइग्रेशन भी मुफ्त नहीं है। इस सूची में कोई भी विकल्प n8n export को नहीं पढ़ सकता है, इसलिए आपको हर flow को मैन्युअल रूप से फिर से बनाना होगा और हर credential को फिर से दर्ज करना होगा। n8n को स्वयं install करना एक अलग कार्य है, जो Docker और HTTPS के साथ VPS पर n8n install करने में कवर किया गया है, और n8n बनाम Zapier और Make में यह बताया गया है कि यह पूरी श्रेणी hosted सेवाओं की तुलना में कैसी है।

लोग self-hosted n8n के विकल्प क्यों तलाशते हैं

दो कारण बार-बार सामने आते हैं।

पहला कारण लाइसेंस है। n8n, Sustainable Use License v1.0 के तहत आता है, जिसे प्रोजेक्ट open source के बजाय fair-code कहता है। यह लाइसेंस "सॉफ्टवेयर का उपयोग या संशोधन केवल अपने आंतरिक व्यावसायिक उद्देश्यों के लिए या गैर-व्यावसायिक या व्यक्तिगत उपयोग के लिए" करने का अधिकार देता है, और यह सॉफ्टवेयर को व्यावसायिक रूप से अन्य लोगों को प्रदान करने पर रोक लगाता है। जिन फाइलों और फोल्डर्स के नाम में .ee होता है, वे एक अलग n8n Enterprise License के अंतर्गत आते हैं। यदि आप भुगतान करने वाले ग्राहकों की ओर से ऑटोमेशन चलाना चाहते हैं, तो यह एक बड़ी बाधा है। यदि आप एक आंतरिक ऑपरेशंस टीम हैं, तो यह आपके दैनिक कार्यों में कोई बदलाव नहीं लाता है।

दूसरा कारण मेमोरी है। n8n एक Node.js प्रोसेस है, और रन के दौरान वर्कफ़्लो डेटा मेमोरी में रहता है। n8n का डॉक्यूमेंटेशन इसके कारणों को स्पष्ट करता है: JSON डेटा की मात्रा, बाइनरी डेटा का आकार, वर्कफ़्लो में नोड्स की संख्या, Code नोड, मैन्युअल निष्पादन (जो एडिटर के लिए डेटा को फिर से कॉपी करते हैं), और एक ही समय में चल रहे अन्य वर्कफ़्लो। डॉक्यूमेंटेशन में सुझाया गया समाधान कोई अलग प्रोडक्ट नहीं है। यह queue mode है जिसमें अलग वर्कर प्रोसेस होते हैं, साथ ही ~/.n8n/database.sqlite पर डिफ़ॉल्ट SQLite के बजाय Postgres का उपयोग करना है। बड़े जॉब्स के लिए बैचिंग भी आवश्यक है, क्योंकि Loop Over Items नोड जो सब-वर्कफ़्लो को डेटा देता है, वह एक समय में डेटा का केवल एक हिस्सा ही मेमोरी में रखता है। कहीं और साठ फ्लो को फिर से बनाने से पहले इसे आज़माएँ।

n8n के कौन से self-hosted विकल्प अभी भी maintained हैं

Licence का टेक्स्ट पढ़ना आसान होता है, इसलिए हर कोई licence की तुलना करता है। Project की स्थिति (health) को नजरअंदाज करना आसान है। इस तुलना में 6 projects शामिल हैं, जिनमें से प्रत्येक का नवीनतम tagged release 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 का अंतिम tag v0.15.0 था, जो 361 दिन पुराना है, और इसकी default branch में 15 January 2026 के बाद से कोई commit नहीं हुआ है। Huginn का अंतिम release 1447 दिन पहले आया था, फिर भी इसका commit log इस महीने सक्रिय है। यह बिल्कुल विपरीत पैटर्न है: कोड में बदलाव हो रहे हैं लेकिन releases नहीं आ रहे हैं, इसलिए इसे चलाने का मतलब है एक untagged image का उपयोग करना।

किसी भी तुलना पर भरोसा करने से पहले, इसे स्वयं जाँचें, जिसमें यह तुलना भी शामिल है। GitHub पर project का releases पेज खोलें, और फिर उसकी default branch के लिए commits की सूची देखें। एक ऐसा project जिसमें नया release हो लेकिन commit log शांत हो, वह केवल पुराने काम पर चल रहा है। एक ऐसा project जिसमें नए commits हों लेकिन वर्षों से कोई release न आया हो, वह आपसे ऐसा कोड चलाने के लिए कह रहा है जिसके लिए किसी ने भी version तैयार नहीं किया है।

Activepieces: सबसे सटीक विकल्प, और मूल में MIT

Activepieces एक समान (like-for-like) विकल्प है। यह triggers और steps वाला एक visual builder है, जिन्हें यह pieces कहता है, और README के अनुसार इनकी संख्या 280 से अधिक है। प्रत्येक piece को एक MCP (model context protocol) server के रूप में भी expose किया जाता है, ताकि एक LLM (large language model) client उन्हीं connectors को tools के रूप में call कर सके। इसका core MIT licensed है। दो directories, packages/ee/ और packages/server/api/src/app/ee, commercial licence के अंतर्गत आती हैं, और इनके भीतर मौजूद चीजों को अपने सर्वर पर उपयोग करने के लिए एक सशुल्क समझौते (paid agreement) की आवश्यकता होती है।

माइग्रेट करने से पहले इस विभाजन को समझ लें, क्योंकि यह अधिकांश MIT projects की तुलना में अधिक व्यापक है। Activepieces का pricing page Community Edition को "open source, free forever, with no cap on runs, users, or flows" के रूप में वर्णित करता है, और Agents and Chat, Projects, API access, तथा संपूर्ण administration layer (single sign-on, user roles, audit logs, secret managers, branding, Git sync) को इससे बाहर रखता है। इसलिए, Community Edition असीमित flows और users के साथ एक पूर्ण automation engine है, लेकिन यह ऐसा platform नहीं है जिसे आप API के माध्यम से संचालित कर सकें। यदि आपकी योजना programmatically flows generate करने की थी, तो उस योजना के लिए licence की आवश्यकता होगी।

Runtime का ढांचा एक app container, एक या अधिक worker containers, Postgres और Redis है। AP_DB_TYPE=POSTGRES और AP_REDIS_TYPE=STANDALONE इसके defaults हैं। इसमें एक embedded database और in-process queue (AP_DB_TYPE=PGLITE के साथ AP_REDIS_TYPE=MEMORY) वाला single-container mode भी है, और documentation के अनुसार यह "केवल व्यक्तिगत उपयोग या परीक्षण के लिए है"। इसे उसी रूप में लें। ये modes एक से अधिक instance नहीं चला सकते, इसलिए इनसे बाहर निकलकर scale करना एक migration है, न कि केवल कोई flag बदलना।

Windmill: कोड-फर्स्ट, और दिखने से कहीं अधिक भारी

Windmill Python, TypeScript, Go, Bash और SQL में स्क्रिप्ट चलाता है, और फिर उन्हें flows में संयोजित करता है। यदि आपके automations मुख्य रूप से कोड हैं और उनके चारों ओर थोड़ा सा glue है, तो यह किसी भी node canvas से बेहतर काम करता है।

इसके licence पर ध्यान देना आवश्यक है। जब इसे enterprise feature flag के बिना compile किया जाता है, तो source AGPLv3 होता है। ghcr.io/windmill-labs/windmill पर प्रकाशित images Community Edition हैं, जिसमें ऐसा कोड शामिल है जो open source नहीं है और quotas के भीतर उपयोग के लिए निःशुल्क है। Windmill का pricing page उन quotas को 50 users, 3 workspaces और 10 GiB workspace object storage पर निर्धारित करता है, जिसमें executions की कोई सीमा नहीं है। एक व्यक्ति या एक छोटी टीम के लिए यह सीमा बहुत दूर है, इसलिए व्यावहारिक प्रश्न quota का नहीं है। प्रश्न यह है कि जो binary आप चलाते हैं वह AGPL build नहीं है।

वजन (weight) दूसरा विचारणीय पहलू है। Windmill का अपना docker-compose.yml एक Postgres 16 database, एक server, तीन default workers (प्रत्येक 2048M memory limit के साथ), एक native worker और एक Caddy proxy के साथ आता है। प्रलेखित नियम (rule of thumb) यह है कि "प्रति 1vCPU और 1-2 GB RAM के लिए 1 worker"। आप एक छोटे box पर replica count को कम कर सकते हैं। आपको यह पता होना चाहिए कि आप इसे कम कर रहे हैं, क्योंकि workers ही वे हैं जो वास्तव में आपके jobs को चलाते हैं।

Windmill के AI features को build-time सहायता के रूप में प्रलेखित किया गया है: कोड जनरेशन, flow बिल्डिंग, चैट और फॉर्म भरना। इसके लिए आपको सबसे पहले workspace settings में एक model provider resource जोड़ना होगा। यदि आप एक ऐसा agent step चाहते हैं जो schedule पर चले और tools को call करे, तो n8n का AI Agent node अभी भी अधिक सीधा रास्ता है, और n8n में AI agent बनाना उस प्रारूप को कवर करता है।

Node-RED: सबसे छोटा, बिना किसी डेटाबेस के

Node-RED का लाइसेंस Apache 2.0 है, जो इस तुलना में सबसे उदार लाइसेंस है। यह एक Node.js प्रोसेस है जिसमें /data वॉल्यूम का उपयोग होता है। इसमें कोई Postgres नहीं है। कोई Redis नहीं है। इसे nodered/node-red:5.0.4 पर पिन करें, जो कि वर्तमान रिलीज है।

इसका विकास IoT (इंटरनेट ऑफ थिंग्स) वायरिंग से हुआ है, इसलिए यह कनेक्टर-आधारित होने के बजाय इवेंट-आधारित है। थर्ड-पार्टी सेवाओं के लिए नोड्स कम्युनिटी लाइब्रेरी से आते हैं और उनकी गुणवत्ता अलग-अलग होती है, जो कि छोटे फुटप्रिंट के लिए आपको समझौता करना पड़ता है। इसमें कोई फर्स्ट-क्लास AI एजेंट स्टेप नहीं है। वेबहुक और मैसेज-क्यू ट्रैफिक को संभालने वाले एक छोटे VPS के लिए, यह यहाँ मौजूद सबसे हल्का विकल्प है जो काम करता है, और यह कुछ ही सेकंड में स्टार्ट हो जाता है।

Huginn और Automatisch: पहले commit log की जाँच करें

Huginn MIT लाइसेंस के अंतर्गत है, इसे Ruby on Rails में लिखा गया है, और इसके लिए MySQL या PostgreSQL की आवश्यकता होती है। यह उन agents के आधार पर काम करता है जो किसी source पर नज़र रखते हैं और events emit करते हैं। यह flow canvas से अलग मॉडल है और इसमें LLM का कोई समर्थन नहीं है। इसके code में अभी भी commits होते हैं, लेकिन अंतिम tagged release अगस्त 2022 की है, इसलिए इसे चलाने का अर्थ है default branch से build की गई ghcr.io/huginn/huginn image का उपयोग करना। इसे तब चुनें जब agent मॉडल आपकी समस्या के अनुकूल हो, न कि n8n के सामान्य विकल्प के रूप में।

Automatisch अपने .ee files को छोड़कर AGPL-3.0 लाइसेंस के अंतर्गत है, और यह n8n के सरल संस्करण जैसा दिखता है: इसमें Postgres, Redis और apps का एक छोटा catalogue है। यह वह tool है जिसे single-deploy tutorials बार-बार सुझाते हैं। release history कहती है कि अभी प्रतीक्षा करना बेहतर है। एक वर्ष तक कोई release न आना और आधे वर्ष तक कोई commit न होना, यदि आप इसे पहले से चला रहे हैं तो घबराने का कारण नहीं है, लेकिन यह एक नया production deployment शुरू न करने का पर्याप्त कारण है।

Activepieces stack के लिए वास्तविक RAM लागत

Idle और working memory की सटीक मात्रा कोई भी आपके लिए प्रकाशित नहीं कर सकता, क्योंकि यह आपके flows और उनमें मौजूद डेटा की मात्रा पर निर्भर करती है। आप केवल वह बजट देख सकते हैं जो प्रत्येक vendor आपको निर्धारित करने के लिए कहता है। Activepieces नीचे दिए गए आकार का दस्तावेजीकरण करता है, और संख्याओं से अधिक महत्वपूर्ण उसके बगल में लिखा वाक्य है: "एक concurrency-1 worker एक flow की पूरी अवधि (10 मिनट तक) के लिए व्यस्त रहता है, इसलिए आकार का निर्धारण concurrent flows के आधार पर करें, न कि trigger rate के आधार पर।"

[
  {
    "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 निर्धारित किया गया है। प्रोजेक्ट की अपनी compose file में पांच worker replicas होते हैं, इसलिए उस आकार के अनुसार, repository में मौजूद stack आपके flows के कुछ भी करने से पहले लगभग 11 GB RAM की मांग करता है। सिंगल-टूल ट्यूटोरियल उस फाइल को कॉपी करते हैं और इसे एक छोटा deployment कहते हैं।

4 GB के VPS पर, दो workers चलाएं, Postgres को उसी compose project में रखें, और मापें। docker stats --no-stream प्रत्येक container के लिए उसकी वास्तविक resident memory के साथ एक लाइन प्रिंट करता है, जो किसी भी vendor या ब्लॉग द्वारा प्रकाशित आंकड़ों से अधिक सटीक है। यदि कोई container बिना किसी सीमा के बढ़ता है, तो उसे सीमित करें, और Docker Compose में memory limits सिंटैक्स दिखाता है।

एक VPS पर Activepieces के लिए compose file

Tag को पिन करें। latest का अर्थ है कि अगला docker compose pull बिना किसी चेतावनी के database schema को बदल सकता है। 4 अगस्त 2026 तक, project अपनी compose file में 0.86.3 version को पिन करता है।

सबसे पहले documentation द्वारा निर्दिष्ट लंबाई का उपयोग करके दो secrets generate करें।

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

Compose file के बगल में .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 को public HTTPS address होना चाहिए, क्योंकि अन्यथा Activepieces webhook URLs बनाते समय आपके public IP address का उपयोग करने का प्रयास करता है। आपके द्वारा किसी तीसरे पक्ष (third party) को दिया गया प्रत्येक webhook इसी value से बनता है, इसलिए यदि यह अभी भी localhost पर point करता है, तो आप जो URL किसी अन्य service में paste करते हैं, वह कभी भी आपके 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:

वह file project की अपनी compose file है जिसमें चार बदलाव किए गए हैं: worker count को पाँच से घटाकर दो कर दिया गया है, published port को हर interface के बजाय 127.0.0.1 पर bind किया गया है, fixed container names हटा दिए गए हैं क्योंकि replicas वाली service उनका उपयोग नहीं कर सकती है, और explicit network block को हटा दिया गया है क्योंकि compose वैसे भी एक बना देता है।

docker compose up -d
docker compose ps

प्रत्येक service को Up दिखाना चाहिए, जिसमें दो worker containers भी शामिल हैं। जो container loop में restart होता है, वह अपना कारण docker compose logs worker में print करता है, इसलिए कुछ भी बदलने से पहले उसे पढ़ें। Port binding का अर्थ है कि जब तक आप सामने TLS (transport layer security) के साथ reverse proxy नहीं लगाते, तब तक बाहर से कुछ भी app तक नहीं पहुँचेगा, जिसे running Traefik in front of several compose apps में कवर किया गया है। .env को mode 600 पर रखें और git से बाहर रखें, जैसा कि handling secrets in compose env files में बताया गया है।

वह बैकअप जिसे हर गाइड नजरअंदाज कर देती है

ये सभी टूल्स स्टोर किए गए क्रेडेंशियल्स को एन्क्रिप्ट करते हैं, इसलिए केवल डेटाबेस डंप लेना ही बैकअप नहीं है। आपको डंप और उसे डिक्रिप्ट करने वाली की (key) दोनों की आवश्यकता होती है। समस्या यह है कि इनमें से अधिकांश टूल्स चुपचाप आपके लिए वह की जनरेट कर देते हैं और उसे ऐसी जगह स्टोर कर देते हैं जिसका आप बैकअप नहीं ले रहे होते हैं।

n8n इसका सबसे स्पष्ट उदाहरण है। यदि आप N8N_ENCRYPTION_KEY सेट नहीं करते हैं, तो n8n "पहली बार लॉन्च होने पर स्वचालित रूप से एक रैंडम एन्क्रिप्शन की बनाता है और उसे ~/.n8n फोल्डर में सेव कर देता है", और फिर डेटाबेस तक पहुँचने से पहले क्रेडेंशियल्स को एन्क्रिप्ट करने के लिए उसी की का उपयोग करता है। यदि आप Postgres का डंप लेते हैं और उसे एक नए वॉल्यूम वाले फ्रेश कंटेनर पर रिस्टोर करते हैं, तो वर्कफ़्लो तो वापस आ जाएंगे लेकिन सभी क्रेडेंशियल्स ऐसे साइट्रेटेक्स्ट (ciphertext) बन जाएंगे जिन्हें कोई नहीं पढ़ सकता। वेरिएबल को स्पष्ट रूप से सेट करें, और जब आप queue mode चलाएं तो हर वर्कर पर वही वैल्यू सेट करें।

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 पर कब बने रहें

यदि काम आपकी अपनी कंपनी के आंतरिक कार्यों से संबंधित है, तो बने रहें, क्योंकि Sustainable Use License ठीक इसी की अनुमति देता है। यदि आप व्यापकता (breadth) पर निर्भर हैं, तो बने रहें, क्योंकि n8n 1500 से अधिक integrations का दावा करता है। साथ ही, LangChain पर आधारित इसके AI Agent node का कोई मुकाबला नहीं है, जो तैयार agent steps प्रदान करता है। Claude के साथ n8n workflows को संचालित करना दिखाता है कि यह व्यवहार में कैसा दिखता है।

यदि आप automation core पर एक permissive license और एक ऐसा stack चाहते हैं जिसे आप शुरू से अंत तक पढ़ सकें, तो Activepieces पर जाएँ। यदि आपके flows वास्तव में code हैं जो user interface का उपयोग कर रहे हैं, तो Windmill पर जाएँ। यदि box छोटा है और काम event-आधारित है, तो Node-RED पर जाएँ। केवल इसलिए न जाएँ क्योंकि किसी benchmark ने आपको बताया है कि n8n भारी है। पहले अपने स्वयं के instance को मापें, फिर 2026 में क्या self-host करना सार्थक है पढ़ें और एक बार में ही चुनाव करें, क्योंकि दूसरी migration की लागत पहली जितनी ही होती है।

FAQ

n8n का कौन सा self-hosted विकल्प n8n के सबसे करीब है?

Activepieces। यह बिल्कुल उसी विचार पर आधारित है: एक visual builder जहाँ एक trigger flow को शुरू करता है और प्रत्येक step एक service को call करता है, जिसमें connectors का एक बड़ा catalogue उपलब्ध है। इसका core MIT licensed है, यह Docker के अंतर्गत Postgres और Redis पर चलता है, और इसके pieces LLM clients के लिए MCP servers के रूप में भी काम करते हैं। ध्यान देने वाली बात यह है कि API access और agent features इसके commercial enterprise directories में हैं, इसलिए Community Edition instance को programmatically चलाने के बजाय web interface के माध्यम से संचालित किया जाता है।

क्या Activepieces वास्तव में open source है?

इसका core, MIT licence के अंतर्गत open source है। दो directories, packages/ee/ और packages/server/api/src/app/ee, commercial रूप से licensed हैं, और अपने सर्वर पर उन features का उपयोग करने के लिए paid licence की आवश्यकता होती है। vendor का pricing page Agents और 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 layer के लिए यह open source नहीं है।

VPS पर Activepieces को कितनी RAM की आवश्यकता होती है?

Activepieces के documentation के अनुसार प्रत्येक worker के लिए 0.5 vCPU और 1 GB RAM, app container के लिए 1 vCPU और 1 GB RAM, Postgres के लिए 4 GB और Redis के लिए 1 GB RAM की आवश्यकता होती है। एक worker एक समय में एक flow को उसकी पूरी अवधि के लिए handle करता है, इसलिए आपको triggers के frequency के बजाय peak concurrent flows के आधार पर sizing करनी चाहिए। repository में मौजूद compose file में पांच workers होते हैं, जो लगभग 11 GB की published sizing है। 4 GB RAM वाले VPS पर दो workers के साथ शुरुआत करना उचित है, और docker stats --no-stream आपके flows के चलते समय उनके वास्तविक उपयोग की पुष्टि करता है।

restore सफल होने के लिए मुझे किसका backup लेना चाहिए?

database dump और encryption key, दोनों का एक साथ। Activepieces के लिए, यह activepieces database का एक pg_dump है, साथ ही वह .env file जिसमें AP_ENCRYPTION_KEY मौजूद है। n8n के लिए, यह database और N8N_ENCRYPTION_KEY है, जिसे n8n ने आपके लिए ~/.n8n folder के अंदर generate किया था यदि आपने इसे कभी set नहीं किया था। Node-RED के लिए, पूरे /data volume का backup लें, क्योंकि credentials file और उसे decrypt करने वाली key दोनों वहीं रहती हैं। Windmill एक अपवाद है: इसकी workspace key इसके अपने Postgres database के अंदर होती है, इसलिए dump में सब कुछ शामिल होता है और इसे secrets की तरह ही सुरक्षित रखना चाहिए।

क्या मैं अपने n8n workflows को किसी अन्य tool में import कर सकता हूँ?

नहीं। ये projects अपने स्वयं के flow formats को import और export करते हैं, n8n के formats को नहीं। migration का मतलब है प्रत्येक flow को नए builder में फिर से बनाना और मूल service से प्रत्येक credential को फिर से तैयार करना। यह मेहनत ही switch करने की वास्तविक लागत है, इसलिए निर्णय लेने से पहले अपने flows की गिनती कर लें। बारह flows को एक दोपहर में पूरा किया जा सकता है। दो सौ flows एक बड़ा project है, और आमतौर पर उन्हें फिर से बनाने के बजाय queue mode और Postgres के साथ n8n के memory उपयोग को ठीक करना अधिक सस्ता पड़ता है।