SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor

VPS पर n8n को Docker और HTTPS के साथ कैसे सेटअप करें

Docker Compose और Postgres का उपयोग करके n8n को VPS पर होस्ट करने का पूरा तरीका जानें। WEBHOOK_URL सेटिंग्स, encryption-key की गलतियों और SSL सेटअप की समस्याओं का समाधान यहाँ उपलब्ध है।

आप क्या बना रहे हैं

n8n एक वर्कफ़्लो ऑटोमेशन टूल है: यह एक विज़ुअल एडिटर है जहाँ एक ट्रिगर, वेबहुक, शेड्यूल या फ़ॉर्म सबमिशन नोड्स की एक श्रृंखला को सक्रिय करता है, जो API को कॉल करते हैं, डेटा को रीशेप करते हैं और अन्य सिस्टम में लिखते हैं। यह AI-agent वर्कफ़्लो के लिए डिफ़ॉल्ट ग्लू (glue) बन गया है क्योंकि यह बिना किसी सर्विस को कोड किए हर मॉडल प्रदाता और डेटाबेस से जुड़ सकता है। एक docker run दो मिनट में एक वर्किंग एडिटर तैयार कर देता है। यह गाइड बाकी नब्बे प्रतिशत काम के बारे में है: डिफ़ॉल्ट SQLite फ़ाइल के बजाय Postgres का उपयोग करके इसे टिकाऊ बनाना, HTTPS के माध्यम से इसे एक्सेस योग्य बनाना, और वह हिस्सा जिसे लगभग हर कोई गलत करता है, यानी वेबहुक को ऐसा URL देना जिसे बाहरी दुनिया वास्तव में एक्सेस कर सके।

तैयार स्टैक एक Docker नेटवर्क पर दो कंटेनरों से बना है: स्वयं n8n, और एक Postgres डेटाबेस जो इसके वर्कफ़्लो और क्रेडेंशियल्स को सुरक्षित रखता है। होस्ट पर एक reverse proxy TLS termination करता है और traffic को localhost पर n8n तक फॉरवर्ड करता है, इसलिए proxy के अलावा कुछ भी सीधे इंटरनेट के सामने नहीं होता है। यह 2026 self-hosting shortlist पर मौजूद अन्य सेवाओं के साथ चलता है।

आवश्यकताएँ और वास्तविक सीमाएँ

आपको कम से कम 1 GB RAM वाला VPS चाहिए। जब workflows वास्तविक काम करने लगें, तो 2 GB RAM की योजना बनाएँ। Executions और Node.js runtime memory का उपयोग करते हैं, और run के बीच container को out-of-memory killer द्वारा रोक दिया जाना यह पता लगाने का बहुत खराब तरीका है कि memory कम है। शुरुआत के लिए एक vCPU पर्याप्त है।

यदि यह box कोई अधिक resource-intensive service भी चलाएगा, तो sizing पहले उसी service के अनुसार करें। आम तौर पर photo library इसका कारण बनती है। PhotoPrism और Immich के लिए वास्तविक RAM requirements n8n की जरूरत से बहुत अधिक होती हैं। यही बात media box पर भी लागू होती है। Jellyfin server और उसके लिए browsable front end, जैसे Halcyon, जो library को 90s की rental shop के रूप में फिर से बनाता है, n8n के memory उपयोग पर ध्यान जाने से बहुत पहले RAM और transcoding headroom का अधिकांश भाग ले लेंगे।

आपको एक domain या subdomain की आवश्यकता है, जैसे n8n.example.com, जिसका A record VPS के public IP पर point कर रहा हो और certificate का अनुरोध करने से पहले वह resolve होना चाहिए। Ports 80 और 443 को proxy के लिए खुला होना चाहिए; n8n का अपना port 5678 इंटरनेट के सामने नहीं होना चाहिए। आपके पास Docker Engine और Compose plugin होना चाहिए; यदि docker compose version चलाने पर docker: 'compose' is not a docker command त्रुटि आती है, तो आपके पास पुराना standalone binary है, और plugin का उपयोग sudo apt install docker-compose-plugin है।

SQLite परीक्षण के लिए ठीक है, लेकिन जिस पर आप निर्भर हैं उसके लिए Postgres का उपयोग करें

n8n का डिफ़ॉल्ट डेटाबेस /home/node/.n8n/database.sqlite पर स्थित एक SQLite फ़ाइल है। शुरुआती परीक्षण के लिए यह ठीक है, लेकिन यदि आप कोई volume mount नहीं करते हैं, तो container को दोबारा बनाने पर आपका डेटा नष्ट हो जाएगा, जो अपने आप में एक सीख है। Postgres पर जाने का कारण केवल गति नहीं है; SQLite एक समय में केवल एक ही writer lock रखता है। इसलिए, यदि एक ही समय में कई workflows चल रहे हों, या आप बाद में queue mode का उपयोग करना चाहें, तो concurrency के कारण SQLITE_BUSY: database is locked त्रुटि आएगी। Postgres में ऐसी कोई सीमा नहीं है, यह pg_dump के साथ आसानी से बैकअप हो जाता है, और n8n के अपने दस्तावेज़ भी यही मानते हैं कि आप एक ऐसे सर्वर का उपयोग कर रहे हैं जिस पर आप निर्भर हैं। बाद में स्विच करने का अर्थ है डेटा को मैन्युअल रूप से माइग्रेट करना, इसलिए यदि यह सर्वर महत्वपूर्ण है, तो शुरुआत से ही Postgres का उपयोग करें।

DNS और firewall

सबसे पहले DNS record को point करें और ports खोलें, ताकि बाद में certificate step किसी ऐसे नाम पर विफल न हो जो resolve नहीं हो रहा है।

dig +short n8n.example.com
curl -s ifconfig.me
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw enable

port 5678 को न खोलें। compose file n8n को 127.0.0.1:5678 पर bind करती है ताकि केवल host का reverse proxy ही उस तक पहुँच सके, और ufw allow 5678 उस isolation को खत्म कर देगा।

Compose फ़ाइल

एक वर्किंग डायरेक्टरी बनाएँ और उसमें एक docker-compose.yml तैयार करें। यह पूरा स्टैक है, जिसमें दो सर्विसेज, एक प्राइवेट नेटवर्क और दो नेम्ड वॉल्यूम्स शामिल हैं।

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

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.29.10
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Europe/London
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - n8n_net
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres_data:
  n8n_data:

networks:
  n8n_net:

कुछ निर्णय जिन्हें स्पष्ट रूप से बताना आवश्यक है। DB_POSTGRESDB_HOST=postgres सर्विस का नाम है, जिसे Docker साझा नेटवर्क पर रिज़ॉल्व करता है, न कि localhost, जिसका अर्थ n8n कंटेनर के अंदर स्वयं n8n होता है। condition: service_healthy के साथ वाला depends_on बूट के समय n8n को Postgres के साथ रेस करने से रोकता है; इसके बिना n8n शुरू होता है, डेटाबेस न मिलने पर बंद हो जाता है। /home/node/.n8n पर स्थित नेम्ड वॉल्यूम n8n_data एन्क्रिप्शन की (encryption key) और SQLite के मामले में डेटाबेस को सुरक्षित रखता है, यह वह डायरेक्टरी है जिसे आपको कभी नहीं खोना चाहिए। इमेज को हमेशा एक सटीक वर्ज़न पर पिन करें, कभी भी latest का उपयोग न करें; इसके कारण नीचे अपग्रेड सेक्शन में दिए गए हैं।

Secrets file

Compose file में कभी भी passwords न रखें। इन्हें इसके बगल में स्थित एक .env file में रखें जिसे Compose अपने आप पढ़ ले, और इन्हें इस तरह generate करें कि ये वास्तव में random हों।

printf 'POSTGRES_PASSWORD=%s\n'  "$(openssl rand -hex 24)" >  .env
printf 'N8N_ENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" >> .env
chmod 600 .env

N8N_ENCRYPTION_KEY यहाँ सबसे महत्वपूर्ण string है, यह वह key है जिससे हर stored credential encrypt किया जाता है। इसे n8n द्वारा generate करने देने के बजाय स्वयं set करें, क्योंकि आपके द्वारा generate की गई value को आप लिख कर रख सकते हैं और restore कर सकते हैं। एक बार जब n8n ने इस key के साथ अपना पहला credential encrypt कर लिया, तो इसे बदलने से हर credential undecryptable हो जाएगा, इसलिए इसे एक बार, अभी set करें, और उस line को फिर कभी न छुएं।

वे env vars जो यह तय करते हैं कि webhooks काम करेंगे या नहीं

चार variables यह नियंत्रित करते हैं कि n8n बाहरी दुनिया के सामने खुद को कैसे प्रस्तुत करता है, और इन्हें गलत सेट करना n8n support का सबसे आम सवाल है।

  • N8N_HOST public hostname है, n8n.example.com। proxy के पीछे इसे default localhost पर छोड़ने से editor आपके browser में localhost से अपना API load करने की कोशिश करता है, जो विफल हो जाता है।
  • N8N_PROTOCOL=https n8n को बताता है कि इसे TLS पर serve किया जा रहा है, इसलिए यह session cookie को Secure के रूप में चिह्नित करता है और https:// URLs बनाता है।
  • N8N_PORT=5678 वह port है जिस पर n8n container के अंदर listen करता है। यह public port नहीं है; proxy 443 को संभालता है।
  • WEBHOOK_URL=https://n8n.example.com/ वह variable है जो सबसे अधिक समस्या पैदा करता है। n8n उन webhook addresses को बनाता है जिन्हें आप Stripe, GitHub या किसी भी external caller में paste करते हैं। यदि यह unset है या गलत है, तो n8n वापस N8N_HOST:N8N_PORT पर चला जाता है और आपको https://n8n.example.com:5678/webhook/... या, इससे भी बुरा, http://localhost:5678/webhook/... देता है। यह बिना किसी error के print होता है, देखने में सही लगता है, लेकिन internet से unreachable होता है, इसलिए caller की requests चुपचाप कभी नहीं पहुँचतीं। इसे trailing slash के साथ exact public base URL पर सेट करें, फिर पुष्टि करें कि webhook node बिना port वाला URL दिखाता है।

N8N_PROXY_HOPS=1 n8n के Express server को अपने सामने एक proxy पर भरोसा करने के लिए कहता है, ताकि rate-limiting और client IP पढ़ने वाली कोई भी सुविधा proxy के बजाय वास्तविक address देख सके। एक variable जिसे आप यहाँ जानबूझकर सेट नहीं करते हैं, वह है N8N_RUNNERS_ENABLED। Task runners, जो n8n के Code-node logic को main process से अलग एक process में चलाते हैं, 1.x line में opt-in थे, जहाँ variable default रूप से false था और आपको इसे true पर सेट करना पड़ता था। n8n 2.0 ने इन्हें default रूप से चालू कर दिया है, इसलिए 2.x line पर यह guide जिस variable को pin करती है, वह deprecated है और n8n के docs के अनुसार अब आपको इसे सेट करने की आवश्यकता नहीं है।

पहली बार start करना

docker compose up -d
docker compose ps
docker compose logs -f n8n

एक सफल पहला boot Editor is now accessible via: लाइन के साथ समाप्त होता है, जिसके ऊपर n8n ready on ..., port 5678 लाइन होती है। docker compose ps में दोनों containers Up दिखाई देने चाहिए, जिसमें postgres को (healthy) के रूप में चिह्नित किया गया हो। यदि n8n एक Restarting लूप में फंसा रहता है, तो logs पढ़ें; यह लगभग हमेशा database connection या नीचे बताए गए volume permissions के कारण होता है।

रिवर्स प्रॉक्सी के साथ TLS

n8n स्वयं 5678 पोर्ट पर plain HTTP का उपयोग करता है; इसके आगे HTTPS termination की आवश्यकता होती है। इसके लिए दो सरल विकल्प हैं।

यदि आप पहले से ही कई containers चला रहे हैं, तो n8n को एक Traefik reverse proxy के पीछे रखें जो स्वचालित रूप से TLS certificates जारी करता है। कुछ labels के साथ, Traefik आपके लिए certificate का अनुरोध और नवीनीकरण (renewal) कर देता है।

यदि यह सर्वर पर एकमात्र app है, तो Let's Encrypt certificate के साथ एक nginx virtual host अधिक सरल है। certificate प्राप्त करने के लिए Ubuntu 24.04 के लिए Certbot और nginx TLS सेटअप का उपयोग करें, और फिर इस server block का उपयोग करें:

server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate     /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600;
        client_max_body_size 16m;
    }
}

Upgrade और Connection "upgrade" headers वैकल्पिक नहीं हैं। n8n WebSocket के माध्यम से editor पर live execution updates भेजता है, और इन दो पंक्तियों के बिना login page लोड तो होता है लेकिन 'lost-connection' banner के साथ अटक जाता है। proxy_read_timeout 3600 लंबी अवधि तक चलने वाले executions को nginx के डिफ़ॉल्ट 60 सेकंड के समय पर कटने से रोकता है। X-Forwarded-Proto $scheme header, N8N_PROXY_HOPS=1 का पूरक है: यह n8n को बताता है कि मूल अनुरोध HTTPS था, भले ही प्रॉक्सी उस तक plain HTTP के माध्यम से पहुँचता हो। इससे n8n यह नहीं मानता कि कनेक्शन असुरक्षित है और वह अपने स्वयं के cookie को अस्वीकार नहीं करता है।

आपका पहला वर्कफ़्लो, इसे हकीकत में बदलना

https://n8n.example.com/ खोलें, ओनर अकाउंट बनाएँ (अगला सेक्शन देखें), और सबसे छोटा वर्कफ़्लो बनाएँ जो यह साबित करे कि पाथ काम कर रहा है: एक वेबहुक इन, एक HTTP कॉल, और एक रिस्पॉन्स आउट।

  1. एक Webhook नोड जोड़ें। मेथड को POST पर सेट करें और hello जैसा पाथ दें। यह दो URL दिखाता है, एक Test URL और एक Production URL, जो "मेरा वेबहुक काम नहीं कर रहा है" वाली आधी रिपोर्टों का कारण होते हैं। Test URL केवल एक कॉल का जवाब देता है, और वह भी तब जब आपने Listen for test event पर क्लिक किया हो; उसके बाद यह एक्सपायर हो जाता है। Production URL तब रजिस्टर होता है जब आप वर्कफ़्लो को publish करते हैं और उसके बाद से यह हमेशा जवाब देता है।
  2. इसके बाद एक HTTP Request नोड जोड़ें, जिसे किसी भी पब्लिक JSON API पर पॉइंट करें। https://api.github.com/zen पर एक GET रिक्वेस्ट एक लाइन की स्ट्रिंग लौटाती है, जो पर्याप्त है।
  3. एक Respond to Webhook नोड जोड़ें, और वेबहुक नोड के Respond विकल्प को "Using Respond to Webhook node" पर सेट करें ताकि कॉलर को HTTP नोड का आउटपुट वापस मिल सके।
  4. Publish (ऊपर दाईं ओर) पर क्लिक करें और इसे कॉल करें: curl -X POST https://n8n.example.com/webhook/hello। आपको ज़ेन लाइन वापस मिलनी चाहिए। POST इन, API कॉल, रिस्पॉन्स आउट, यही अधिकांश वास्तविक ऑटोमेशन का स्वरूप है। पुरानी गाइड आपको यहाँ एक Active टॉगल को ऑन करने के लिए कहती हैं; n8n 2.0 ने उस टॉगल को Publish और Unpublish से बदल दिया है।

एक शेड्यूल्ड वेरिएंट में वेबहुक नोड की जगह Schedule Trigger का उपयोग होता है और यह वेबहुक के बजाय एक मॉडल एंडपॉइंट को कॉल करता है। उसी VPS पर चल रहा Ollama एक नाइटली समराइज़र बनाने का एक बेहतरीन तरीका है।

User management, न कि basic auth

पुराने n8n guides में N8N_BASIC_AUTH_ACTIVE=true सेट करने के लिए कहा जाता था। n8n 1.0 में ये variables हटा दिए गए थे और अब इनका कोई प्रभाव नहीं है। आज authentication owner account से होती है: editor को पहली बार load करने पर n8n आपसे email-and-password owner बनाने को कहता है। यह gate अनिवार्य है और anonymous mode उपलब्ध नहीं है। पहली boot के तुरंत बाद, किसी को URL देने से पहले इसे बनाएं: docker compose up और उस first form submission के बीच instance को सबसे पहले पहुंचने वाला कोई भी व्यक्ति claim कर सकता है। इसके ऊपर reverse-proxy basic-auth layer लगाना एक उचित अतिरिक्त lock है, लेकिन यह second factor है, वास्तविक authentication नहीं। owner account और इस guide की बाकी सभी सुविधाएं free community edition में चलती हैं। यदि बाद में आपको granular roles वाले extra users या SSO चाहिए, तो किन n8n features के लिए paid licence चाहिए की जानकारी पढ़ लें, ताकि planning करते समय इन पर निर्भरता स्पष्ट रहे।

Backups: पहले encryption key, फिर database

दो चीजों का बैकअप लेना आवश्यक है, और दोनों की प्रतिस्थापन क्षमता (replaceability) समान नहीं है।

N8N_ENCRYPTION_KEY। n8n में आपके द्वारा स्टोर किए गए सभी क्रेडेंशियल्स, API टोकन, डेटाबेस पासवर्ड और OAuth सीक्रेट्स इसी की (key) से एन्क्रिप्ट किए जाते हैं। इसके बिना Postgres में मौजूद वर्कफ़्लो बेकार हैं: यदि आप डेटाबेस को किसी अलग की (key) वाले नए सर्वर पर रिस्टोर करते हैं, तो n8n किसी भी क्रेडेंशियल को डिक्रिप्ट नहीं कर पाएगा। इसका कोई रिकवरी या रीसेट विकल्प नहीं है। आपकी .env फ़ाइल में यह की (key) होती है; इसे सर्वर से बाहर किसी सुरक्षित स्थान पर कॉपी कर लें, पासवर्ड-मैनेजर एंट्री इसके लिए सबसे उपयुक्त है। इसे उसी दिन करें जिस दिन आप इसे बनाते हैं। यही वह बैकअप है जो वास्तव में मायने रखता है।

Postgres डेटाबेस, वर्कफ़्लो, निष्पादन इतिहास (execution history) और स्वयं एन्क्रिप्टेड क्रेडेंशियल्स के लिए:

docker compose exec -T postgres pg_dump -U n8n -d n8n \
  | gzip > n8n-db-$(date +%F).sql.gz

इसे एक शेड्यूल पर चलाएं और डंप को सर्वर से बाहर कॉपी कर लें। एक नए VPS पर रिस्टोर करने के लिए: स्टैक को एक बार स्टार्ट करें ताकि डेटाबेस बन जाए, n8n को रोकें, psql के साथ डंप को लोड करें, उसी N8N_ENCRYPTION_KEY को .env में डालें, और n8n को स्टार्ट करें। समान की (key) और डंप का मतलब है एक कार्यशील इंस्टेंस; नई की (key) का मतलब है ऐसे वर्कफ़्लो जो किसी भी क्रेडेंशियल का उपयोग नहीं कर पाएंगे।

Upgrades: tag को pin करना

Compose file में जानबूझकर latest के बजाय n8nio/n8n:2.29.10 को pin किया गया है। n8n लगभग हर हफ्ते एक नया minor version release करता है और कभी-कभी इनके बीच database schema या node behaviour बदल देता है, इसलिए latest का अर्थ है कि एक unattended pull आपको ऐसा build दे सकता है जो start होते ही आपके database को migrate कर दे। एक version को pin करें, bump करने से पहले release notes पढ़ें, n8n वहाँ breaking changes के बारे में जानकारी देता है, और सोच-समझकर upgrade करें:

docker compose exec -T postgres pg_dump -U n8n -d n8n | gzip > pre-upgrade.sql.gz
# edit the image tag in docker-compose.yml, then:
docker compose pull n8n
docker compose up -d n8n
docker compose logs -f n8n

Major-version jumps के मामले में यह सबसे महत्वपूर्ण है। उदाहरण के लिए, 2.0 line ने डिफ़ॉल्ट रूप से N8N_BLOCK_ENV_ACCESS_IN_NODE को true में बदल दिया, इसलिए कोई भी Code node जो process.env को पढ़ता था, वह तब तक access खो देता है जब तक आप उसे वापस false पर सेट न करें; उसी release ने settings file पर सख्त permissions लागू करना शुरू किया, task runners को डिफ़ॉल्ट रूप से enable किया, और workflow Activate toggle को Publish से बदल दिया। किसी major boundary को पार करने से पहले 2.0 breaking-changes page पढ़ें। n8n start होने पर आवश्यक कोई भी database migration स्वचालित रूप से चलाता है, और यही कारण है कि pre-upgrade pg_dump वैकल्पिक नहीं है। चूंकि credentials .env में एक key के साथ encrypted रहते हैं और data Postgres में रहता है, इसलिए containers disposable होते हैं: आप उन्हें replace करके upgrade करते हैं, और पिछले tag को pin करके तथा dump restore करके roll back करते हैं।

विफलता के प्रकार और उनसे संबंधित त्रुटि संदेश

The requested webhook "POST hello" is not registered. किसी ऐसे webhook को कॉल करने पर 404 त्रुटि आना जिसका workflow पब्लिश नहीं है, या test path को कॉल करना जबकि कोई listener सक्रिय नहीं है। Test paths (/webhook-test/...) केवल तब प्रतिक्रिया देते हैं जब आपने "Listen for test event" पर क्लिक किया हो; production paths (/webhook/...) केवल तब काम करते हैं जब workflow पब्लिश हो चुका हो। इसी तरह This webhook is not registered for GET requests. Did you mean to make a POST request? का अर्थ है कि method गलत है; node को POST की अपेक्षा है और आपने GET भेजा है।

Webhook URL में :5678 या localhost दिखाई देना। Node में https://n8n.example.com:5678/webhook/... या http://localhost:5678/... प्रदर्शित होता है। WEBHOOK_URL सेट नहीं है या गलत है, इसलिए n8n ने आपके public base के बजाय N8N_HOST:N8N_PORT से पता बनाया है। WEBHOOK_URL=https://n8n.example.com/ को सेट करें, docker compose up -d के साथ container को फिर से बनाएँ, और port हट जाएगा।

ब्राउज़र में There was a problem loading init data। Editor लोड हो गया है लेकिन अपने backend API तक नहीं पहुँच पा रहा है। Proxy के पीछे ऐसा होने का मुख्य कारण गलत N8N_HOST या WEBHOOK_URL, proxy में WebSocket Upgrade headers का न होना, या N8N_PROTOCOL का आपके कनेक्शन के तरीके से मेल न खाना है। चारों public-facing variables की पुष्टि करें और सुनिश्चित करें कि proxy Upgrade और Connection को forward कर रहा है।

Logs में password authentication failed for user "n8n" और container का बार-बार restart होना। n8n द्वारा भेजा गया password उस password से मेल नहीं खाता जिससे database initialize हुआ था। समस्या यह है: Postgres केवल तब POSTGRES_PASSWORD को पढ़ता है जब वह एक खाली data directory को initialize करता है। Stack को एक बार start करें, फिर .env में POSTGRES_PASSWORD बदलें, तो मौजूदा postgres_data volume में पुराना password ही रहेगा। इसे वापस मूल password पर सेट करें, या यदि आपके पास सुरक्षित रखने योग्य कोई data नहीं है, तो docker compose down करें और postgres volume को docker volume rm करें, फिर इसे नए सिरे से start करें।

Start-up पर EACCES: permission denied, open '/home/node/.n8n/config'। n8n, node user (UID 1000) के रूप में चलता है और अपनी config directory में लिख नहीं पा रहा है। यह समस्या तब आती है जब आप root के स्वामित्व वाले host folder (./n8n_data:/home/node/.n8n) को bind-mount करते हैं। ऊपर दिखाए गए named volume का उपयोग करें, या यदि आप bind mount का ही उपयोग करना चाहते हैं, तो पहले sudo chown -R 1000:1000 ./n8n_data करें।

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. 2.x वर्ज़न से n8n डिफ़ॉल्ट रूप से उस settings file पर 0600 लागू करता है और boot के समय इसे स्वयं ठीक कर लेता है। यह log line दर्शाती है कि उसने mode को ठीक कर दिया है, जो अक्सर bind mount या restore के बाद फाइल की अनुमतियाँ (permissions) ढीली होने पर होता है। किसी कार्रवाई की आवश्यकता नहीं है; N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false को केवल तभी सेट करें यदि आपका filesystem वास्तव में अनुमतियों का समर्थन नहीं कर सकता है।

Mismatching encryption keys, पूरी लाइन यह बताती है कि settings file /home/node/.n8n/config में मौजूद encryption key आपके environment में मौजूद N8N_ENCRYPTION_KEY से मेल नहीं खाती है। आपके environment की key उस key से अलग है जिसे n8n ने पिछली बार data volume में लिखा था। ऐसा अक्सर तब होता है जब variable सेट न होने पर n8n ने boot के समय एक random key जनरेट की हो, और बाद में आपने एक अलग key सेट कर दी हो। मूल key को वापस .env में डालें, या यदि आपके पास सुरक्षित रखने योग्य कोई credentials नहीं हैं, तो n8n_data volume के अंदर की config फाइल को हटा दें और n8n को इसे फिर से जनरेट करने दें। ध्यान रखें कि ऐसा करने पर मौजूदा credentials अपठनीय हो जाएंगे।

Secure cookies के बारे में login banner: Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari. आपने N8N_PROTOCOL=https सेट किया है लेकिन n8n तक plain HTTP के माध्यम से पहुँच रहे हैं, आमतौर पर HTTPS proxy के बजाय सीधे IP और port का उपयोग करके। इसे https://n8n.example.com/ के माध्यम से एक्सेस करें। केवल तभी N8N_SECURE_COOKIE=false सेट करें यदि आप वास्तव में HTTPS का उपयोग नहीं कर सकते हैं, और इसे कभी भी इंटरनेट पर खुले सर्वर पर न करें।

उन workflows में language model जोड़ने के लिए, Claude और n8n के साथ AI workflows बनाना देखें।

FAQ

क्या मुझे n8n के लिए SQLite का उपयोग करना चाहिए या Postgres का?

SQLite (डिफ़ॉल्ट) n8n को आज़माने और एक समय में एक वर्कफ़्लो चलाने वाले व्यक्तिगत इंस्टेंस के लिए ठीक है। यदि आप किसी महत्वपूर्ण कार्य के लिए इसका उपयोग कर रहे हैं, तो Postgres पर स्विच करें: SQLite का सिंगल राइटर लॉक concurrency के दौरान database is locked एरर देता है, और Postgres का बैकअप pg_dump के साथ आसानी से लिया जा सकता है। बाद में माइग्रेट करना एक मैनुअल प्रक्रिया है, इसलिए यदि सर्वर महत्वपूर्ण है, तो शुरुआत से ही Postgres का उपयोग करें।

मेरे n8n वेबहुक कभी ट्रिगर क्यों नहीं होते?

इसका कारण लगभग हमेशा WEBHOOK_URL होता है। यदि यह सेट नहीं है या गलत है, तो n8n वेबहुक पते N8N_HOST:N8N_PORT से बनाता है, जिसमें अक्सर :5678 या localhost शामिल होते हैं। ये पते देखने में सही लगते हैं लेकिन इंटरनेट से उन तक नहीं पहुँचा जा सकता, इसलिए कॉलर के अनुरोध कभी नहीं पहुँचते। WEBHOOK_URL=https://n8n.example.com/ को सेट करें और सुनिश्चित करें कि नोड बिना पोर्ट वाला URL दिखा रहा है। दूसरा कारण किसी ऐसे वर्कफ़्लो के प्रोडक्शन URL को कॉल करना है जिसे आपने पब्लिश नहीं किया है, जो The requested webhook ... is not registered. लौटाता है।

मुझे n8n में किसका बैकअप लेना चाहिए?

दो चीजों का। अपनी .env फ़ाइल से N8N_ENCRYPTION_KEY, क्योंकि प्रत्येक स्टोर्ड क्रेडेंशियल इसी से एन्क्रिप्ट होता है और इसे खोने पर वे हमेशा के लिए डिक्रिप्ट नहीं हो पाएंगे; इसे बनाने के दिन ही सर्वर से बाहर कहीं कॉपी कर लें। और वर्कफ़्लो, हिस्ट्री और क्रेडेंशियल्स के लिए Postgres डेटाबेस का pg_dump। रिस्टोर करने के लिए दोनों की आवश्यकता होती है: वही की (key) और डंप।

मैं n8n को HTTPS के पीछे कैसे रखूँ?

n8n पोर्ट 5678 पर प्लेन HTTP सर्व करता है; इसके सामने एक रिवर्स प्रॉक्सी TLS टर्मिनेट करता है। n8n को 127.0.0.1:5678 पर बाइंड करें ताकि केवल प्रॉक्सी ही उस तक पहुँच सके, फिर ऑटोमैटिक सर्टिफिकेट के साथ Traefik या Let's Encrypt सर्टिफिकेट के साथ nginx का उपयोग करें। N8N_PROTOCOL=https और WEBHOOK_URL=https://your-host/ सेट करें, और सुनिश्चित करें कि प्रॉक्सी WebSocket Upgrade हेडर को फॉरवर्ड कर रहा है, अन्यथा एडिटर हैंग हो जाएगा।

मैं n8n को सुरक्षित रूप से अपग्रेड कैसे करूँ?

latest के बजाय एक विशिष्ट इमेज टैग पिन करें, पहले pg_dump लें क्योंकि n8n स्टार्ट होने पर अपने आप माइग्रेशन चलाता है, ब्रेकिंग बदलावों के लिए रिलीज़ नोट्स पढ़ें, फिर टैग को अपडेट करें और docker compose pull n8n && docker compose up -d n8n चलाएं। कंटेनर डिस्पोजेबल होता है, इसलिए पिछले टैग को पिन करके और अपग्रेड से पहले के डंप को रिस्टोर करके रोल बैक करें।

#n8n#automation#Docker#सेल्फ़-होस्टिंग#https