n8n उस तरह का टूल है जिसे आप हल्के से इस्तेमाल करना शुरू करते हैं और फिर चुपचाप अपने आधे ऑपरेशन उसके ज़रिए रूट कर देते हैं। जिस बिंदु पर "यह किसी की क्लाउड सीट पर चल रहा है, प्रति-निष्पादन मीटर किया, मेरी API कुंजियाँ उनके सर्वरों पर रहती हुई" कम बढ़िया लगने लगता है। स्व-होस्टिंग तीनों ठीक करती है — फ़्लैट लागत, कोई निष्पादन कैप नहीं, और आपकी कुंजियाँ एक ऐसे बॉक्स पर रहती हैं जिसके आप मालिक हैं। Docker के साथ यह एक पंद्रह-मिनट का काम है।
इसे असल में कितने सर्वर की ज़रूरत है
पहले ईमानदार आँकड़े, ताकि आप ज़्यादा या कम न ख़रीदें:
- ~2 GB RAM स्वीट स्पॉट है — n8n प्लस उसका Postgres डेटाबेस प्लस सामान्य वर्कफ़्लो यहाँ आराम से बैठते हैं।
- 1 GB काम करता है अगर आपके वर्कफ़्लो हल्के हों, पर बड़े रन पर आप इसे नोटिस करेंगे।
- 4 GB अगर आप भारी समांतर निष्पादन करते हैं या बड़े पेलोड धकेलते हैं।
n8n आराम में CPU-भूखा नहीं; यह रन के दौरान स्पाइक करता है। एक 2-कोर बॉक्स ज़्यादातर सेटअप के लिए ठीक है। (कार्यभार से स्पेक्स मिलाने पर और साइज़िंग गाइड में।)
Docker सेटअप
एक ताज़ा Ubuntu/Debian बॉक्स पर, Docker इंस्टॉल करें:
curl -fsSL https://get.docker.com | sudo sh
एक फ़ोल्डर और एक docker-compose.yml बनाएँ — एक स्थायी वॉल्यूम और Postgres वाला n8n:
services:
n8n:
image: docker.n8n.io/n8nio/n8n
restart: always
ports:
- "127.0.0.1:5678:5678"
environment:
- N8N_HOST=n8n.yourdomain.com
- N8N_PROTOCOL=https
- WEBHOOK_URL=https://n8n.yourdomain.com/
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=db
- DB_POSTGRESDB_PASSWORD=change-me
volumes:
- ./n8n-data:/home/node/.n8n
depends_on: [db]
db:
image: postgres:16
restart: always
environment:
- POSTGRES_PASSWORD=change-me
- POSTGRES_DB=n8n
volumes:
- ./db-data:/var/lib/postgresql/data
sudo docker compose up -d
दो चीज़ें इंगित करने लायक: वॉल्यूम (n8n-data, db-data) वे हैं जो आपके वर्कफ़्लो को रीस्टार्ट और अपग्रेड में ज़िंदा रखते हैं — इन्हें न छोड़ें। और n8n 127.0.0.1 से बँधा है, 0.0.0.0 से नहीं — यह इंटरनेट को सीधे उजागर नहीं है। यह जान-बूझकर है; अगला क़दम एक्सेस को सुरक्षित रूप से संभालता है।
एक्सेस: HTTPS या एक टनल
- सार्वजनिक URL (OAuth नोड्स और webhooks के लिए ज़रूरी): एक सबडोमेन को सर्वर की ओर इंगित करें और
127.0.0.1:5678के सामने एक रिवर्स प्रॉक्सी चलाएँ (Caddy सबसे कम-मेहनत है — स्वचालित HTTPS)। यहीं एक डेडिकेटेड-IP प्लान फ़िट बैठता है, क्योंकि आप पोर्ट और DNS नियंत्रित करते हैं। - बस अपने लिए, कोई डोमेन नहीं: प्रॉक्सी छोड़ें और इसे एक SSH टनल पर पहुँचें —
ssh -L 5678:127.0.0.1:5678 user@server, फिरlocalhost:5678खोलें। एक NAT VPS पर ठीक काम करता है।
इसे बंद करें और चालू रखें
n8n आपकी API कुंजियाँ और साख रखता है, तो बॉक्स कड़ा होना चाहिए: असली साख डालने से पहले सुरक्षा चेकलिस्ट करें (SSH कुंजियाँ, फ़ायरवॉल, कोई पासवर्ड लॉगिन नहीं)। compose फ़ाइल में restart: always पहले से मतलब Docker n8n को एक क्रैश या रीबूट के बाद वापस लाता है — वह आपका अपटाइम संभला।
क्या यह सार्थक है?
वॉल्यूम के बारे में ख़ुद से ईमानदार रहें। अगर आप लगातार ऑटोमेशन चलाते हैं, स्व-होस्टिंग लागत पर जीतती है (फ़्लैट बनाम प्रति-निष्पादन) और किसी वर्कफ़्लो/रन सीमा को हटाती है। अगर आप महीने के कुछ फ़्लो ट्रिगर करते हैं, एक होस्टेड सीट कम झंझट है। पर नियंत्रण तर्क बहरहाल क़ायम है: आपके वर्कफ़्लो, आपका डेटा, आपकी कुंजियाँ — आपके सर्वर पर, किराए पर नहीं। ज़्यादातर लोगों के लिए जो n8n के बारे में गंभीर हुए, वही निर्णायक कारक है।
एक 2 GB बॉक्स, एक compose फ़ाइल, एक डोमेन (या एक टनल), और आप अपना ख़ुद का ऑटोमेशन हब चला रहे हैं — बिना KYC क्रिप्टो में चुकाने योग्य, मिनटों में लाइव।
तैयार सेटअप: n8n के लिए VPS देखें — अनुशंसित प्लान और एक-मिनट क्रिप्टो डिप्लॉय।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।