NordBastion का polar-bear mascot एक अंधेरे Nordic vault में एक तराशे हुए पत्थर की बेंच पर बैठा है, उसकी गोद में एक laptop है और उसके ऊपर एक बड़ा cyan holographic automation workflow तैर रहा है — छह गोल nodes चमकती हुई घुमावदार तारों से जुड़े हुए — बेंच के सहारे टिकी cyan N-shield और उसके बगल में एक server rack के साथ
How-to · Self-host·13 मिनट रीड · 30 मिनट hands-on

एक VPS पर n8n को Self-host करें।
आपका automation engine, आपके credentials, आपका metal।

एक खाली Nordic VPS से लेकर अपने ही domain पर एक TLS-terminated n8n तक के छह चरण — Docker Compose, Caddy, PostgreSQL, webhooks जो असल में fire होते हैं। Executions आपके CPU से बंधे हैं, किसी plan tier से नहीं, एक ऐसे box पर जिसकी कीमत $3.90 महीना है। Debian 12 पर n8n 2.x के साथ tested।

छह चरण
  1. 01

    Provision

    VPS + एक A record

  2. 02

    Install करें

    get.docker.com

  3. 03

    Compose

    n8n + Caddy + Postgres

  4. 04

    पहला Boot

    Owner account और 2FA

  5. 05

    Webhooks

    WEBHOOK_URL

  6. 06

    Harden करें

    Prune करें, silence करें, back up करें

शुरू करने से पहले · Licence और cost

आप असल में क्या install कर रहे हैं। और licence आपको इसके साथ क्या करने देती है।

n8n एक workflow automation engine है: एक visual canvas जहाँ आप किसी trigger को — एक webhook, एक schedule, database में एक नई row, queue में एक message — nodes की एक chain से जोड़ते हैं जो APIs को call करते हैं, data को transform करते हैं, conditions पर branch करते हैं, मनमाना JavaScript या Python चलाते हैं, और नतीजा आगे जो भी हो उसे सौंप देते हैं। box में कई सौ integration nodes पहले से मौजूद हैं, साथ ही एक generic HTTP Request node जो बाकी सब कुछ cover कर लेता है। 1.x line से यह AI Agent और LLM nodes भी रखता है, यही वजह है कि 2026 में इसे install करने वाले ज़्यादातर लोग classic ETL plumbing की बजाय agents बना रहे हैं।

एक भी command टाइप करने से पहले जो हिस्सा मायने रखता है वह licence है, क्योंकि n8n OSI के अर्थ में open source नहीं है और यह फ़र्क़ सैद्धांतिक नहीं है। core Sustainable Use License के तहत आता है: software को internal business उद्देश्यों के लिए और personal या non-commercial उपयोग के लिए use, copy, modify और distribute करने का एक non-exclusive, royalty-free, worldwide grant। यह जो रोकता है वह है n8n या उसके किसी derivative के लिए दूसरों से पैसे लेने का अधिकार — यही वह clause है जो उसके ऊपर एक paid "managed n8n" product बनाने को खारिज करता है। अलग से, जिस भी file के नाम में .ee. या उसके path में .ee हो, वह उस licence से पूरी तरह बाहर है और एक paid n8n Enterprise License माँगती है।

साफ़ शब्दों में: अपनी कंपनी को automate करने के लिए, अपने clients के काम को एक service के रूप में देने के लिए, या अपनी निजी ज़िंदगी के लिए किसी VPS पर n8n चलाना free grant के भीतर है और हमेशा से रहा है। n8n-as-a-hosting-product बेचना नहीं है। internet पर लगभग हर "क्या n8n सच में free है?" वाली बहस दो लोगों की उसी रेखा के आर-पार एक-दूसरे से बिना सुने बात करने जैसी है।

Cost वाला पहलू। n8n Cloud का price per execution तय होता है: Starter plan 2,500 executions के लिए €20 महीना है, annually billed, Pro 10,000 के लिए €50 महीना है, Business 40,000 के लिए €667 महीना है। Self-hosted में, execution count कोई line item ही नहीं है — यह इस पर बंधा है कि box के पास कितना CPU और memory है। एक workflow जो हर पाँच मिनट में एक API poll करता है वह अकेले ही महीने में 8,640 executions burn कर देता है; Cloud पर वह अकेला workflow पहले ही Pro tier मजबूर कर देता है, और $3.90 वाले VPS पर यह idle CPU के मुकाबले एक rounding error है।

विकल्प मासिक Executions शामिल इसे कौन चलाता है
n8n Cloud · Starter€202 500n8n GmbH
n8n Cloud · Pro€5010 000n8n GmbH
n8n Cloud · Business€66740 000n8n GmbH
स्व-होस्टेड · Sentinel VPS$3.90CPU-bound, metered नहींआप

Cloud prices जैसा कि n8n.io पर अगस्त 2026 में published हैं, annually billed; monthly billing की लागत ज़्यादा है। यह सौदा सिर्फ़ पैसे का नहीं है — self-hosting upgrades, backups, TLS renewal और uptime को आपके पाले में डाल देती है।

शुरू करने से पहले · Sizing

box की Sizing। चार gigabytes न्यूनतम हैं, disk छुपा हुआ खतरा है।

n8n का अपना Docker Compose documentation न्यूनतम 2 vCPU और 4 GB RAM बताता है। यह कोई marketing संख्या नहीं है: इससे नीचे editor front-end और एक मध्यम रूप से branched workflow memory के लिए आपस में लड़ेंगे, और पहला बड़ा JSON payload container को एक out-of-memory kill से बाहर कर देगा।

Sentinel · 2 vCPU, 4 GB, 120 GB NVMe, $3.90/mo. सही default। n8n, PostgreSQL और Caddy को साथ चलाता है और एक personal या small-team instance के लिए, जो रोज़ कुछ सौ executions करता है, गुंजाइश भी छोड़ता है। तीनों containers में idle memory लगभग 700 MB रहती है।

Garrison · 4 vCPU, 8 GB, 240 GB NVMe, $7.90/mo. एक कदम ऊपर जब आप Redis और एक या दो worker containers के साथ queue mode जोड़ते हैं, जब workflows अक्सर memory में multi-megabyte payloads रखते हैं, या जब आपको उन AI-agent workflows के लिए आरामदायक मार्जिन चाहिए जो कई parallel branches में फैलते हैं।

Ravelin · 8 vCPU, 16 GB, 480 GB NVMe, $16.90/mo. एक team instance जहाँ रोज़ हज़ारों executions होते हैं और binary-heavy काम होता है — PDF generation, image processing, audio transcription। यहाँ dedicated cores मायने रखते हैं क्योंकि ये workloads API-bound नहीं बल्कि CPU-bound हैं।

disk वह हिस्सा है जिसे लोग भूल जाते हैं। n8n हर execution के हर node का पूरा input और output store करता है। हर मिनट चलने वाला एक बातूनी workflow हफ़्ते में सैकड़ों megabytes लिख देता है। डिफ़ॉल्ट्स prune करते तो हैं — EXECUTIONS_DATA_PRUNE true है, EXECUTIONS_DATA_MAX_AGE 336 घंटे (चौदह दिन) है और EXECUTIONS_DATA_PRUNE_MAX_COUNT 10 000 है — लेकिन एक व्यस्त instance के चौदह दिन भी NVMe पर काफ़ी बोझ हैं। Step 06 इन्हें कड़ा करता है।

चरण 01 · Provision

एक Nordic VPS और एक DNS record। इसी क्रम में।

panel में: Order → VPS → Sentinel, image Debian 12। account खोलने के लिए किसी email address की ज़रूरत नहीं है, किसी भी बिंदु पर कोई identity document नहीं माँगा जाता, और invoice Monero, Bitcoin, Lightning या किसी अन्य supported asset में settle होता है। bastion को अपने से नहीं बल्कि उन services से latency के हिसाब से चुनें जिन्हें आप automate करते हैं — एक automation server आपसे बात करने से कहीं ज़्यादा APIs से बात करता है।

फिर server को छूने से पहले DNS record बनाएं: n8n.example.com के लिए एक A record जो VPS के IPv4 की ओर इशारा करे, और अगर आप IPv6 इस्तेमाल करते हैं तो एक AAAA record। यह पहले करना ज़रूरी है, क्योंकि stack शुरू होते ही Caddy Let's Encrypt से एक certificate माँगता है, और जो नाम resolve नहीं होता उसके लिए certificate request fail हो जाती है — फिर back off करती है, और आप बीस मिनट यह सोचते हुए बिता देते हैं कि site क्यों नहीं पहुँच रही।

DNS को propagate होने के लिए एक मिनट दें और आगे बढ़ने से पहले इसे अपनी मशीन से confirm करें:

dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else

किसी public port पर कुछ भी listen करे, उससे पहले first-hour hardening checklist चलाएं — key-only SSH, एक firewall जो सिर्फ 22, 80 और 443 की अनुमति दे, और unattended security upgrades। एक automation server एक credential vault है; यह पूरे एक घंटे का हकदार है।

चरण 02 · इंस्टॉल

Docker, और कुछ नहीं। एक command।

SSH से अंदर जाएं और Compose v2 plugin के साथ Docker Engine install करें:

apt update && apt install -y ca-certificates curl
curl -fsSL https://get.docker.com | sh
docker compose version

convenience script Docker के अपने repository से Engine, CLI, containerd और Compose plugin install करता है। आख़िरी line में Docker Compose version v2 या उससे ऊपर print होना चाहिए; अगर यह "docker: 'compose' is not a docker command" print करे तो आपके पास distribution का पुराना docker.io package installed है और पहले उसे remove करना चाहिए।

एक one-line n8n installer मौजूद है जो यह सब wrap कर देता है, और वह काम भी करता है। यह गाइड इसके बजाय Compose file को हाथ से लिखती है, क्योंकि वह सब कुछ जो आपको बाद में बदलना पड़ेगा — encryption key, database, webhook URL, retention policy, worker count — उसी file में रहता है, और जो stack आप पढ़ नहीं सकते उसे आप रात 3 बजे fix भी नहीं कर सकते।

चरण 03 · Compose

/opt/n8n में तीन files। n8n, PostgreSQL, Caddy।

पहले directory बनाएं और दो secrets generate करें। इन्हें अभी, इसी क्रम में generate करें, और जैसे-जैसे करते जाएं .env में paste करते जाएं — खासकर encryption key का n8n के पहले boot से पहले मौजूद होना ज़रूरी है, बाद में नहीं।

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32   # → N8N_ENCRYPTION_KEY
openssl rand -hex 24   # → POSTGRES_PASSWORD

/opt/n8n/.env

DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm

N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here

इस file को तुरंत lock करें — इसमें वह key है जो instance द्वारा भविष्य में store किए जाने वाले हर credential तक पहुंच देती है:

chmod 600 /opt/n8n/.env

/opt/n8n/docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://${DOMAIN}
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_VERSION_NOTIFICATIONS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  caddy_config:
  pg_data:
  n8n_data:

/opt/n8n/Caddyfile

{$DOMAIN} {
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    reverse_proxy n8n:5678
}

दो design decisions जिनका नाम लेना ज़रूरी है। पहली बात, n8n कोई port publish नहीं करता। सिर्फ़ Caddy 80 और 443 को bind करता है; n8n Compose network के अंदर 5678 पर listen करता है जहाँ host के बाहर से कुछ भी उस तक नहीं पहुँच सकता। हैरानी की बात है कि कई self-hosted n8n instances बिना आगे TLS के public internet पर port 5678 पर मौजूद हैं, और exposed services के लिए search engines उन्हें index कर लेते हैं। दूसरी बात, n8n data volume mounted रहता है भले ही अब workflows PostgreSQL में हों — उस directory में अब भी instance settings, log files और source-control assets मौजूद रहते हैं।

इसे up करें:

cd /opt/n8n
docker compose up -d
docker compose logs -f caddy   # watch the certificate being issued
Step 04 · पहला Boot

Owner account, और वह key जो आपको कभी नहीं खोनी चाहिए। इसे दो बार पढ़ें।

https://n8n.example.com खोलें। पहली screen owner-account setup की है — email, password, name। अब configure करने के लिए कोई HTTP basic-auth environment variable नहीं है; 1.x line से user management n8n में ही built-in है, और यहाँ आप जो account बनाते हैं वह instance का owner होता है। अपने password manager से एक password इस्तेमाल करें, फिर सीधे Settings → Personal → Two-factor authentication पर जाकर इसे चालू करें। यह login उस हर API key का मुख्य दरवाज़ा है जिसे आप कभी किसी node में paste करेंगे।

वह एक irreversible गलती

n8n हर stored credential को N8N_ENCRYPTION_KEY से encrypt करता है। अगर आप इसे सेट नहीं करते, तो n8n पहले boot पर एक generate कर लेता है और उसे data volume के अंदर लिख देता है। उस volume को दोबारा बनाइए — एक docker compose down -v, किसी नए server पर migration, एक बिगड़ा हुआ restore — और नया instance एक अलग key generate करता है, database में हर credential undecryptable हो जाता है, और कोई recovery रास्ता बिलकुल नहीं बचता। आपको हर API key, OAuth token और password हाथ से दोबारा enter करना पड़ता है। जैसा यह गाइड करती है वैसे ही key explicitly सेट करें, और एक copy server से बाहर रखें।

उस copy का सही ठिकाना एक password manager है जिसे आप खुद control करते हैं — self-hosted Vaultwarden गाइड एक को cover करती है, और जान-बूझकर यह बात है कि यह उसी box पर नहीं होना चाहिए जिसे यह unlock करता है।

verify करें कि database असल में PostgreSQL है, SQLite fallback नहीं — अगर DB_ variables में कोई typo हो, तो n8n चुपचाप SQLite पर शुरू हो जाता है और आपको इसका पता तीन महीने बाद चलता है:

docker compose exec postgres psql -U n8n -d n8n -c '\dt' | head
# → a list of n8n tables (workflow_entity, credentials_entity, execution_entity…)
चरण 05 · Webhooks

वह आधा हिस्सा जो चुपचाप काम नहीं करता। एक proxy के पीछे Webhooks।

एक n8n जो boot होकर editor दिखाए और manual test चला दे, अभी तक एक working n8n नहीं है। जो हिस्सा चुपचाप टूटता है वह inbound webhooks हैं, और यह इस तरह टूटता है कि लगे जैसे गलती third-party service की है।

WEBHOOK_URL. इसके बिना, n8n webhook URLs को N8N_HOST और N8N_PORT से बनाता है और आपको कुछ ऐसा देता है जैसे http://localhost:5678/webhook/abc — जिसे आप फिर Stripe या GitHub में paste करते हैं, जहाँ यह कभी नहीं पहुँच सकता। ऊपर की Compose file WEBHOOK_URL को public HTTPS root पर सेट करती है, जो editor दिखाएगा और जिसे बाहरी दुनिया असल में call कर सकती है।

N8N_EDITOR_BASE_URL. वह public URL जिसे n8n अपने भेजे emails के links के लिए इस्तेमाल करता है — password resets, user invitations। यहाँ गलती का मतलब है एक invitation link जो localhost की ओर इशारा करे, जो एक टूटी हुई integration की बजाय किसी सहकर्मी से आया एक support ticket बन जाता है।

N8N_PROXY_HOPS. n8n client IP को X-Forwarded-For से पढ़ता है, और यह सिर्फ़ उतने ही hops पर भरोसा करता है जितना यह संख्या बताती है। आगे एक reverse proxy होने पर — इस stack में Caddy — मान 1 होता है। Caddy के आगे Cloudflare रखें तो यह 2 हो जाता है। इसे डिफ़ॉल्ट 0 पर छोड़ दें तो हर request proxy से ही आती हुई दिखती है, जो चुपचाप rate limits और आपके workflows में किसी भी IP-based logic को तोड़ देती है।

N8N_SECURE_COOKIE. यह डिफ़ॉल्ट रूप से true होता है, यानी session cookie सिर्फ़ HTTPS पर भेजी जाती है। यही सही setting है और यह stack इसे पूरा करता है। इसे जानना ज़रूरी है क्योंकि यह plain http पर पहली कोशिश के क्लासिक लक्षण को समझाता है: login form password स्वीकार करता है और फिर आपको हमेशा के लिए login form पर वापस भेज देता है। इसका इलाज TLS है, flag को false करना नहीं।

इसे सही तरीके से test करें। एक Webhook node के साथ एक workflow बनाएं, workflow को activate करें, Production URL copy करें, फिर उसे किसी ऐसी मशीन से call करें जो server न हो:

curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor

वह फ़र्क़ जो हर किसी को एक बार ज़रूर उलझाता है: Test URL सिर्फ़ तब listen करता है जब आपका editor खुला हो और "Listen for test event" armed हो। Production URL सिर्फ़ तभी मौजूद होता है जब workflow को Active toggle किया गया हो। जो webhook editor में काम करता है और production में 404 देता है वह लगभग हमेशा एक inactive workflow होता है।

चरण 06 · सख्त करें

Prune, silence, back up। यही तीन तय करते हैं कि यह एक साल टिकेगा या नहीं।

Retention। डिफ़ॉल्ट्स चौदह दिन या 10 000 executions रखते हैं, जो भी पहले आए, हर node के पूरे input और output data के साथ। एक व्यस्त schedule trigger वाले छोटे NVMe पर यही चीज़ disk को भर देती है। इन्हें n8n environment block में जोड़ें और restart करें:

- EXECUTIONS_DATA_PRUNE=true
- EXECUTIONS_DATA_MAX_AGE=168          # hours — one week
- EXECUTIONS_DATA_PRUNE_MAX_COUNT=5000
- EXECUTIONS_DATA_SAVE_ON_SUCCESS=none # keep failures, drop the noise

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none एक high-frequency instance पर सबसे बड़ी जीत है: यह सफल runs के payloads लिखना बंद कर देता है, जबकि हर failed run को पूरी तरह store करता रहता है ताकि आप उसे debug कर सकें। जब तक आप workflow बना ही रहे हों तब तक इसे "all" पर रखें, फिर जब workflow उबाऊ यानी stable हो जाए तो इसे बदल दें।

Silence। Compose file पहले से diagnostics, version notifications और personalisation survey को बंद कर देती है। बचा हुआ outbound caller template gallery है, जो api.n8n.io से fetch करता है; अगर आप बिलकुल कोई third-party call नहीं चाहते तो N8N_TEMPLATES_ENABLED=false सेट करें। अगर आप version notifications बंद करते हैं, तो अपने calendar में एक monthly reminder रखें कि release notes पढ़ें — एक ऐसा self-hosted instance जिसे कोई update नहीं करता, उससे बुरा नतीजा है जो versions के लिए ping करता रहे।

Code node। N8N_BLOCK_ENV_ACCESS_IN_NODE=true, जो file में पहले से मौजूद है, expressions और Code nodes को process environment variables पढ़ने से रोकता है — जिसका मतलब इस box पर PostgreSQL password और encryption key है। अगर आप public REST API इस्तेमाल नहीं करते, तो N8N_PUBLIC_API_DISABLED=true जोड़ें और उस surface को भी बंद कर दें।

Backups — तीनों हिस्से या कोई नहीं। अकेले database का backup, encryption key के बिना बेकार है, और अकेली key कुछ भी restore नहीं करती। PostgreSQL dump, n8n data volume और .env को एक साथ backup करें, और कम से कम एक copy server से बाहर रखें:

cd /opt/n8n
docker compose exec -T postgres pg_dump -U n8n n8n | gzip > backup-db-$(date +%F).sql.gz
docker run --rm -v n8n_n8n_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/backup-vol-$(date +%F).tar.gz -C /data .
cp .env backup-env-$(date +%F)

volume का नाम Compose project के नाम और volume के नाम को जोड़कर बनता है; अगर आपकी directory का नाम n8n नहीं है, तो docker volume ls चलाएं और जो दिखे उसे इस्तेमाल करें। तीनों lines को एक cron job में डालें, archives को कहीं और भेजें, और एक बार restore करके test करें — एक untested backup सिर्फ़ एक विश्वास है, backup नहीं।

Updates। docker compose pull, फिर उसके बाद docker compose up -d। पहले एक snapshot लें: n8n शुरू होने पर database migrations चलाता है, और migrations को roll back करने के लिए नहीं बनाया गया है। किसी major version के आर-पार — जैसे 1.x से 2.x की छलांग — pull करने से पहले release notes पढ़ें, बाद में नहीं, और :latest की बजाय एक स्पष्ट image tag pin करने पर विचार करें ताकि एक unattended restart आपको कभी अचानक upgrade न कर दे।

आगे बढ़ते हुए · Scaling

जब एक process काफ़ी नहीं होती। Queue mode, Redis और workers।

डिफ़ॉल्ट रूप से n8n regular mode में चलता है: जो process editor serve करता है और webhooks receive करता है वही workflows को execute भी करता है। यह सरल है और सही भी, जब तक कि एक लंबा workflow बाकी को इंतज़ार न कराने लगे। लक्षण साफ़ होता है — executions मिनटों तक "running" में अटके रहते हैं, editor सुस्त हो जाता है, और जो webhook 200 ms में जवाब देना चाहिए वह आठ seconds में जवाब देता है।

Queue mode काम को बाँट देता है। main instance editor, triggers और webhook endpoints को अपने पास रखता है; यह execution IDs को Redis में push करता है; अलग worker processes उन्हें pull करते हैं, PostgreSQL से workflow load करते हैं, उसे चलाते हैं, और Redis के ज़रिए वापस report करते हैं। इस architecture से तीन नियम निकलते हैं और जो इन्हें छोड़ते हैं उन सबको तीनों काटते हैं: हर instance को एक ही PostgreSQL database share करना ज़रूरी है, हर instance पर एक ही N8N_ENCRYPTION_KEY होना ज़रूरी है, और SQLite बिलकुल भी supported नहीं है।

Compose file में जोड़ी गई चीज़ें एक Redis service और एक worker service हैं, जो वही n8n image है जिसे worker command के साथ चलाया जाता है:

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker --concurrency=5
    depends_on:
      - redis
      - postgres
    environment:
      # the SAME encryption key and the SAME database as the main instance
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}

मुख्य n8n service में भी EXECUTIONS_MODE=queue और QUEUE_BULL_REDIS_HOST=redis जोड़ें — दोनों पक्षों को mode पर सहमत होना ज़रूरी है। पहले दिन से ही दो options सेट करना उचित है: OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true, ताकि editor में "Test workflow" दबाने से main process न रुके, और N8N_GRACEFUL_SHUTDOWN_TIMEOUT, जो डिफ़ॉल्ट रूप से 30 seconds का होता है और तय करता है कि redeploy के दौरान एक worker को अपना मौजूदा job पूरा करने के लिए कितना समय मिलेगा। अगर आपके workflows आमतौर पर आधे मिनट से ज़्यादा चलते हैं, तो इसे बढ़ाएं वरना हर deployment चल रहे काम को खत्म कर देगा।

यहाँ से शुरू न करें। Queue mode दो moving parts और एक ऐसी failure की श्रेणी जोड़ता है जो regular mode में सिरे से होती ही नहीं। तब तक regular mode में रहें जब तक आपको queue बढ़ती न दिखे या एक workflow दूसरे को block न करने लगे, फिर दूसरा box जोड़ने से पहले उसी box पर एक worker जोड़ें। यह क्रम — regular mode में Sentinel, एक worker के साथ Garrison, तीन के साथ Ravelin — एक सचमुच बड़े deployment को छोड़कर बाकी सब कुछ cover करता है।

application के नीचे वाली layer

मशीन असल में क्या रखती है। और क्यों इससे बदल जाता है कि इसका मालिक कौन होना चाहिए।

ज़्यादातर self-hosting गाइड host के चुनाव को एक performance का सवाल मानते हैं। एक automation engine के लिए यह वैसा नहीं है। एक n8n instance दो ऐसी चीज़ें साथ रखता है जो लगभग कोई और self-host की गई चीज़ साथ नहीं रखती: एक ही encrypted table जिसमें आपके द्वारा automate की गई हर service की API keys, OAuth tokens और mail passwords हों, और — उसके ठीक बगल में — एक graph जो बताता है कि आपका organisation असल में कैसे काम करता है। कौन-सा CRM। कौन-सा bank feed। कौन-सा supplier। किस customer को किस trigger पर कौन-सा email जाता है। किसी कंपनी की workflow list पढ़ लीजिए, आपने कंपनी को पढ़ लिया।

Layer एक — host के अनुसार आप कौन हैं। यहाँ application layer वाकई अच्छी है: credentials encrypted at rest हैं, editor TLS और 2FA के पीछे है। जो layer leak करती है वह नीचे वाली है। एक hosted plan आपकी legal entity, आपका billing address और आपका card जानता है। एक hyperscaler भी वही जानता है और उसे सालों तक रखता है। यह कोई काल्पनिक exposure नहीं है; यह "एक encrypted vault मौजूद है" और "यह इस नामित कंपनी की है" के बीच का join key है। बिना email और बिना identity document वाला, Monero में settle किया गया signup, vault को नहीं बल्कि उस join key को हटा देता है।

Layer दो — disk। Encryption at rest सिर्फ़ उस व्यक्ति के खिलाफ़ मदद करता है जिसके पास key भी नहीं है, और एक default install में key उसी filesystem पर बैठी होती है जिस पर database होता है। .env को mode 600 पर रखें, key की एक copy मशीन से बाहर रखें, और ऐसे provider को तरजीह दें जिसका jurisdiction किसी datacentre को process serve करने के लिए सुविधाजनक जगह न बनाए — यही Nordic jurisdictions गाइड की पूरी दलील है।

Layer तीन — exit IP। हर HTTP Request node VPS address से निकलता है, और उस address की एक reputation होती है। Hyperscaler ranges internet पर सबसे ज़्यादा aggressively rate-limited और CAPTCHA-walled हैं, क्योंकि वहीं scrapers रहते हैं; जो workflow scrape या poll करता है वह किसी शांत Nordic range पर fail होने से बहुत पहले AWS या DigitalOcean के IP पर fail होने लगेगा। n8n standard HTTP_PROXY, HTTPS_PROXY, ALL_PROXY और NO_PROXY variables का भी सम्मान करता है, इसलिए जिन गिने-चुने workflows को अलग exit चाहिए उन्हें local SOCKS proxy या Tor से route किया जा सकता है जबकि बाकी सब direct जाते हैं।

एक और दरवाज़ा, 2.x line में नया: n8n एक instance-level MCP server expose कर सकता है ताकि एक AI agent आपके workflows को tools की तरह call कर सके। यह वाकई उपयोगी है और यह आपकी automation layer में एक public endpoint भी है, जो बाकी किसी की तरह ही ध्यान का हकदार है — TLS, OAuth और exposure तर्क के लिए remote MCP server गाइड देखें।

Field notes · छह traps

छह तरीके जिनसे यह गड़बड़ा सकता है। उसी क्रम में जिसमें लोग इनसे टकराते हैं।

Trap 01 · अपरिवर्तनीय

हर credential अचानक decrypt होने में fail हो जाता है

data volume दोबारा बनाया गया और n8n ने एक नई encryption key generate कर दी। पुराने credentials अब कुछ भी वापस नहीं ला सकता। हमेशा N8N_ENCRYPTION_KEY explicitly सेट करें और एक copy server से बाहर रखें।

Trap 02 · एकीकरण

webhook URL localhost बताता है

WEBHOOK_URL सेट नहीं है, इसलिए n8n URLs को N8N_HOST से बनाता है। WEBHOOK_URL और N8N_EDITOR_BASE_URL को public HTTPS address पर सेट करें और container को restart करें।

Trap 03 · पहुँच

login form हमेशा के लिए loop करता रहता है

आप editor तक plain http पर पहुँच रहे हैं और secure session cookie अस्वीकार हो जाती है। किसी public instance पर N8N_SECURE_COOKIE को false सेट करने की बजाय TLS setup पूरा करें।

Trap 04 · क्षमता

दो महीने बाद disk भर जाती है

एक minute-by-minute trigger से चौदह दिनों का पूरा execution data। EXECUTIONS_DATA_MAX_AGE और PRUNE_MAX_COUNT को कड़ा करें, और successful runs को save करना बंद करें।

Trap 05 · उन्नयन

एक unattended restart ने एक major version खींच लिया

:latest tag और database migrations जो roll back नहीं होतीं। एक स्पष्ट tag pin करें, हर pull से पहले snapshot लें, और major versions के बीच release notes पढ़ें।

Trap 06 · समय-निर्धारण

Schedule triggers गलत घंटे पर fire होते हैं

GENERIC_TIMEZONE डिफ़ॉल्ट रूप से America/New_York पर सेट होता है, जो शायद ही कभी किसी को चाहिए होता है। GENERIC_TIMEZONE और TZ को एक ही असली zone पर सेट करें और restart करें।

FAQ · n8n को Self-host करना

प्रश्न, उत्तरित।

दस सवाल जो एक n8n instance को अपने ही server पर ले जाने से पहले, दौरान और बाद में उठते हैं।

क्या n8n को self-host करना सच में free है?

अपने खुद के automations के लिए, हाँ। n8n Sustainable Use License के तहत आता है: आप इसे internal business उद्देश्यों के लिए और personal या non-commercial उपयोग के लिए, बिना किसी लागत के, use, copy, modify और distribute कर सकते हैं। यह licence जो मना करता है वह है n8n या उसके किसी derivative के लिए दूसरों से पैसे लेना — व्यवहार में, "n8n hosting" को एक product की तरह resell करना। filename में .ee. या directory path में .ee वाली files इस licence से बाहर हैं और एक paid n8n Enterprise License माँगती हैं। तो: अपनी किराए की VPS पर अपनी कंपनी को automate करना पूरी तरह free grant के भीतर है; उसके ऊपर एक hosted n8n business बनाना नहीं।

n8n चलाने के लिए मुझे कितना VPS चाहिए?

n8n का अपना Docker Compose documentation न्यूनतम 2 vCPU और 4 GB RAM बताता है। यह ठीक Sentinel tier है ($3.90/mo — 2 vCPU, 4 GB, 120 GB NVMe), जो एक personal या small-team instance के लिए n8n plus PostgreSQL plus Caddy को आराम से चला लेता है। जब आप queue-mode workers जोड़ें या ऐसे workflows चलाएं जो memory में बड़े payloads रखते हों, तो Garrison (4 vCPU, 8 GB, $7.90/mo) पर जाएं, और binary data — PDFs, images, audio — के साथ रोज़ हज़ारों executions करने वाले team instance के लिए Ravelin (8 vCPU, 16 GB, $16.90/mo) पर।

n8n के लिए SQLite या PostgreSQL?

SQLite डिफ़ॉल्ट है और गिने-चुने workflows वाले एक अकेले व्यक्ति के लिए यह वाकई ठीक है। PostgreSQL पर तब switch करें जब आपके पास concurrent executions हों, जब execution history कुछ लाख rows से आगे बढ़ जाए, या जब आप scale करने की योजना बनाएं — और ध्यान रहे कि queue mode SQLite को बिलकुल भी support नहीं करता। बाद में migrate करने का मतलब है workflows और credentials को export करना और उन्हें एक नए instance में फिर से import करना, जो एक ऐसी दोपहर है जिसका आप आनंद नहीं लेंगे। अगर growth की कोई भी संभावना है, तो PostgreSQL पर शुरू करें; इस गाइड की Compose file पहले से ऐसा ही करती है।

अगर मैं N8N_ENCRYPTION_KEY खो दूं तो क्या होता है?

database में हर credential permanently अपठनीय हो जाता है। n8n stored credentials — OAuth tokens, API keys, SMTP passwords — को उसी key से encrypt करता है, और न कोई recovery mechanism है और न कोई support ticket जो उन्हें वापस ला सके। आपको हर credential हाथ से दोबारा enter करना पड़ता है। एक self-hosted n8n instance के तबाह होने का यही सबसे आम तरीका है: कोई Docker volume को दोबारा बनाता है, n8n एक नई key generate करता है, और हर workflow एक साथ decryption error के साथ fail होने लगता है। पहले boot से पहले अपने .env में key explicitly सेट करें, और एक copy कहीं ऐसी जगह रखें जो server न हो।

मेरे n8n webhooks क्यों fire नहीं हो रहे?

चार कारण, आवृत्ति के क्रम में। (1) WEBHOOK_URL सेट नहीं है, इसलिए editor आपको एक ऐसा http://localhost:5678/webhook/… URL देता है जिस तक कोई external service नहीं पहुँच सकती — इसे अपने public HTTPS URL पर सेट करें। (2) workflow activated नहीं है; test URL सिर्फ़ तब listen करता है जब editor खुला हो, production URL सिर्फ़ तभी मौजूद होता है जब workflow active हो। (3) DNS या firewall: record resolve नहीं होता, या ports 80/443 बंद हैं। (4) आप एक अतिरिक्त proxy layer के पीछे हैं और आपने N8N_PROXY_HOPS सेट नहीं किया, इसलिए n8n गलत client IP पढ़ता है। server न होने वाली किसी मशीन से एक plain curl के साथ test करें।

क्या मैं एक ही VPS पर n8n को दूसरी services के साथ चला सकता हूँ?

हाँ, और यही सामान्य पैटर्न है — आगे एक Caddy, एक Compose network, एक hostname पर n8n और बाकी पर Vaultwarden, Nextcloud या SearXNG। दो सावधानियाँ। Memory: n8n plus PostgreSQL लगभग 700 MB पर idle रहते हैं और एक भारी workflow इससे कहीं आगे spike कर सकता है, इसलिए गुंजाइश छोड़ें। Blast radius: n8n database box पर सबसे ज़्यादा credential-dense चीज़ है, इसलिए वह host share करने वाली कोई भी और चीज़ उसकी risk profile विरासत में पाती है। $3.90/month वाले tier पर automation engine को उसका अपना server देना उचित है।

क्या self-hosted n8n phone home करता है?

डिफ़ॉल्ट रूप से, तीन endpoints। Anonymous product telemetry (N8N_DIAGNOSTICS_ENABLED, default true), api.n8n.io के खिलाफ़ new-version और security-update check (N8N_VERSION_NOTIFICATIONS_ENABLED, default true), और workflow template browser, जो https://api.n8n.io से fetch करता है (N8N_TEMPLATES_ENABLED, default true)। इनमें से कोई भी आपके credentials या आपका workflow data नहीं भेजता, लेकिन तीनों यह ज़रूर बताते हैं कि आपके IP पर एक instance मौजूद है। अगर आप box को silent रखना चाहते हैं तो तीनों को false करें — आप template gallery और update banner खो देंगे, इसलिए releases पर खुद नज़र रखें।

n8n Cloud या self-hosted — break-even कहाँ है?

n8n Cloud Starter 2,500 executions के लिए €20/month है, annually billed; Pro 10,000 के लिए €50/month है। एक Sentinel VPS $3.90/month का है और execution count सिर्फ़ CPU और RAM से बंधा है, जिसका मतलब आम webhook-and-API workflows के लिए दसियों हज़ार है। पैसे का break-even तुरंत है; असली लागत operational है। Self-hosting का मतलब है कि upgrades, backups, TLS renewal और रात 3 बजे का disk-full incident आपके ज़िम्मे है। ईमानदार नियम: अगर आप किसी security release के एक महीने के भीतर खुद instance को upgrade नहीं करते, तो Cloud के लिए पैसे दें। अगर एक monthly docker compose pull पहले से आपकी ज़िंदगी का हिस्सा है, तो self-host करें।

एक automation server के लिए ख़ास तौर पर KYC-मुक्त host क्यों मायने रखता है?

इसलिए क्योंकि एक n8n instance के पास क्या होता है। credential table आपके द्वारा automate की गई हर service की API keys, OAuth tokens और mail passwords का एक ही encrypted store है, और उसके बगल में workflow graph एक पढ़ने-योग्य नक्शा है कि आपका business असल में कैसे चलता है — कौन-सा CRM, कौन-सा bank feed, कौन-सा supplier, कौन-से customers। एक static website इनमें से कुछ भी leak नहीं करती। application layer इसे अच्छी तरह protect करती है; leak metadata layer में होता है। अगर मशीन के signup में passport scan और card लगता है, तो आपने vault को encrypt करके दरवाज़े पर अपना नाम लिख दिया है। Monero में भुगतान किया गया एक no-KYC host इन दोनों layers को एक-दूसरे के अनुरूप रखता है।

क्या मैं इस VPS पर n8n में AI agents चला सकता हूँ?

आम रूप के लिए हाँ — एक AI Agent node जो किसी remote model API को call करता है। वह workload I/O-bound है, यह provider का इंतज़ार करता है, और एक Sentinel इसे संभाल लेता है। जो फिट नहीं बैठता वह है model को खुद चलाना: एक 7B local model को लगभग 8 GB RAM चाहिए और असली inference speed के लिए एक GPU चाहिए, जो ये tiers नहीं रखते। n8n को एक remote OpenAI-compatible endpoint पर point करें और VPS को हल्का रखें। एक AI agent को 24/7 चलाने वाली companion गाइड runtime पहलू को cover करती है — restart policies, secrets, spend caps और crash-loop trap।

metal प्राप्त करें

आपके automation engine के लिए एक Nordic VPS। KYC-मुक्त, crypto-भुगतान।

Sentinel (2 vCPU, 4 GB, 120 GB NVMe, $3.90/mo) n8n की न्यूनतम ज़रूरत को पूरा करता है और उसी box पर PostgreSQL और Caddy के लिए भी जगह छोड़ता है। signup पर कोई email नहीं, कोई identity document नहीं, unlimited executions।

अंतिम review · 2026-08-24 · स्रोत · n8n hosting documentation, n8n LICENSE.md (Sustainable Use License), n8n.io pricing page, Docker और Caddy upstream docs · आवृत्ति · वार्षिक