VPS वर n8n self-host: Docker आणि HTTPS सेटअप

तुम्ही काय तयार करणार आहात

n8n हे workflow automation tool आहे. त्यात visual editor असतो. Trigger, webhook, schedule किंवा form submission झाल्यावर nodes ची साखळी सुरू होते. हे nodes APIs ला call करतात, data चे रूपांतर करतात आणि इतर systems मध्ये लिहितात. तुम्ही स्वतंत्र service न लिहिता प्रत्येक model provider आणि database शी संवाद साधू शकत असल्यामुळे AI-agent workflows साठी n8n हे default glue बनले आहे. एक docker run वापरून दोन मिनिटांत कार्यरत editor मिळतो. या मार्गदर्शकाचा उर्वरित नव्वद टक्के भाग टिकाऊ रचना तयार करण्याबद्दल आहे: default SQLite file ऐवजी Postgres वापरणे, HTTPS द्वारे प्रवेश उपलब्ध करणे आणि, ज्यात जवळजवळ सर्वजण चूक करतात तो भाग, webhooks साठी बाहेरील जगातून प्रत्यक्ष पोहोचता येईल असा URL उपलब्ध करून देणे.

अंतिम stack मध्ये एका Docker network वर दोन containers असतील: n8n स्वतः आणि त्याच्या workflows व credentials साठवणारा Postgres database. Host वरील reverse proxy TLS termination करेल आणि localhost वरील n8n कडे requests forward करेल. त्यामुळे reverse proxy वगळता कोणतीही सेवा internet-facing राहणार नाही. हा stack इतर services च्या शेजारी 2026 मध्ये स्वतः host करण्यासाठीची निवडक यादी मध्ये राहतो.

पूर्वतयारी आणि प्रत्यक्ष मर्यादा

तुमच्याकडे किमान 1 GB RAM असलेला VPS असणे आवश्यक आहे. Workflow प्रत्यक्ष काम करू लागल्यावर 2 GB RAM ची तरतूद करा, कारण executions आणि Node.js runtime मेमरी वापरतात. Execution सुरू असताना out-of-memory killer ने container बंद करणे, ही बाब उशिरा समजण्याचा अत्यंत त्रासदायक मार्ग आहे. सुरुवातीस एक vCPU पुरेसा आहे.

या मशीनवर एखादी अधिक संसाधने वापरणारी सेवा देखील चालणार असल्यास, आधी त्या सेवेनुसार आकार निवडा. Photo library हे याचे नेहमीचे कारण असते. PhotoPrism आणि Immich साठी आवश्यक असलेली प्रत्यक्ष किमान RAM n8n ला लागणाऱ्या RAM पेक्षा खूप जास्त असते.

Media box साठीही हेच लागू होते. Jellyfin server आणि त्यासाठी browsable front end, जसे 90s मधील rental shop प्रमाणे library पुन्हा तयार करणारे Halcyon, n8n ला याची जाणीव होण्यापूर्वीच RAM आणि transcoding headroom वापरून टाकतील.

तुमच्याकडे एखादा domain किंवा subdomain असणे आवश्यक आहे, उदाहरणार्थ n8n.example.com. त्यासाठी VPS च्या public IP कडे निर्देश करणारा A record असावा. Certificate मागण्यापूर्वी तो resolve झाला पाहिजे. Proxy साठी ports 80 आणि 443 खुले असणे आवश्यक आहे. 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 चा default database /home/node/.n8n/database.sqlite येथे असलेली SQLite file आहे. फक्त प्राथमिक चाचणीसाठी ती पुरेशी आहे. कोणताही volume mount केला नाही, तर पहिल्याच container recreate वेळी ती file नष्ट होईल; हा देखील एक स्वतंत्र धडा आहे. Postgres कडे जाण्याचे कारण raw speed नाही. SQLite मध्ये एकच writer lock असतो. त्यामुळे एकाच वेळी अनेक workflows चालवणारे instance किंवा पुढे आवश्यक ठरणारा queue mode वापरल्यास concurrency अंतर्गत SQLITE_BUSY: database is locked निर्माण होते. Postgres ला ही मर्यादा नाही. pg_dump वापरून त्याचा backup व्यवस्थित घेता येतो. तसेच, ज्या server वर तुम्ही अवलंबून आहात त्यासाठी n8n च्या स्वतःच्या documentation मध्येही Postgres गृहीत धरले आहे. नंतर बदल करायचा असल्यास data manually migrate करावा लागतो. त्यामुळे हा box महत्त्वाचा असल्यास सुरुवातीपासून Postgres वापरा.

DNS आणि firewall

प्रमाणपत्राची पुढील पायरी अशा नावामुळे अयशस्वी होऊ नये, जे resolve होत नाही. त्यामुळे प्रथम DNS record योग्य ठिकाणी निर्देशित करा आणि आवश्यक ports उघडा.

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

5678 उघडू नका. Compose file n8n ला 127.0.0.1:5678 वर bind करते, त्यामुळे केवळ host वरील reverse proxy त्याच्यापर्यंत पोहोचू शकतो. ufw allow 5678 ही isolation रचना नष्ट करेल.

Compose फाइल

कार्य करण्यासाठी एक directory तयार करा आणि docker-compose.yml तयार करा. हा पूर्ण stack आहे: दोन services, एक private network आणि दोन named volumes.

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 हे service name आहे. Docker shared network वर याचे resolution करते. localhost नाही, कारण n8n container मध्ये त्याचा अर्थ n8n स्वतः असा होतो. condition: service_healthy असलेले depends_on boot वेळी n8n आणि Postgres यांच्यातील race थांबवते. ते नसल्यास n8n सुरू होते, database सापडत नाही आणि process बंद होतो. /home/node/.n8n येथे जोडलेले named volume n8n_data encryption key आणि SQLite वापरत असल्यास database ठेवते. ही एक directory तुम्ही गमावू नये. Image ला exact version वर pin करा; कधीही latest वापरू नका. त्याची कारणे खालील upgrade section मध्ये दिली आहेत.

गुप्त माहितीची फाइल

Compose फाइलमध्ये कधीही पासवर्ड ठेवू नका. त्याऐवजी तिच्या शेजारी .env फाइलमध्ये पासवर्ड ठेवा. ही फाइल Compose आपोआप वाचते. पासवर्ड प्रत्यक्षात यादृच्छिक असतील अशा पद्धतीने ते तयार करा.

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 आहे. साठवलेल्या प्रत्येक credential चे encryption करण्यासाठी ही key वापरली जाते. n8n ला ती स्वतः generate करू देण्याऐवजी ती स्पष्टपणे सेट करा. तुम्ही स्वतः generate केलेली value लिहून ठेवून नंतर restore करू शकता. n8n ने या key ने पहिल्या credential चे encryption केल्यानंतर ती बदलल्यास प्रत्येक credential decrypt करता येणार नाही, म्हणून ती आत्ताच एकदा सेट करा आणि त्यानंतर ही line पुन्हा कधीही बदलू नका.

वेबhooks कार्यरत आहेत की नाही हे ठरवणारे env vars

चार variables n8n बाह्य प्रणालींसमोर स्वतःचे वर्णन कसे करते हे नियंत्रित करतात. हे चुकीचे सेट करणे हा n8n support मधील सर्वात सामान्य प्रश्न आहे.

• N8N_HOST हा सार्वजनिक hostname आहे, n8n.example.com. Proxy मागे तो default localhost ठेवल्यास editor आपल्या browser मध्ये localhost येथून स्वतःचे API load करण्याचा प्रयत्न करतो. ते अयशस्वी होते.
• N8N_PROTOCOL=https n8n ला सेवा TLS वर उपलब्ध आहे असे सांगतो. त्यामुळे तो session cookie Secure म्हणून चिन्हांकित करतो आणि https:// URLs तयार करतो.
• N8N_PORT=5678 हा n8n कंटेनरच्या आतील बाजूने ऐकत असलेला port आहे. तो सार्वजनिक port नाही. Proxy 443 हाताळतो.
• WEBHOOK_URL=https://n8n.example.com/ मुळे सर्वाधिक समस्या निर्माण होतात. n8n या values पासून webhook addresses तयार करते आणि ते Stripe, GitHub किंवा इतर कोणत्याही बाह्य caller मध्ये paste करण्यासाठी दाखवते. हे unset किंवा चुकीचे असल्यास n8n N8N_HOST:N8N_PORT वर fallback करते आणि https://n8n.example.com:5678/webhook/... किंवा, त्याहून वाईट, http://localhost:5678/webhook/... देते. हे कोणतीही error न दाखवता print होते, पाहता योग्य वाटते; परंतु इंटरनेटवरून त्यापर्यंत पोहोचता येत नाही. त्यामुळे caller च्या requests शांतपणे कधीच पोहोचत नाहीत. ते trailing slash असलेल्या अचूक सार्वजनिक base URL वर सेट करा. त्यानंतर webhook node मध्ये port नसलेला URL दिसत आहे याची खात्री करा.

N8N_PROXY_HOPS=1 n8n च्या Express server ला त्याच्या समोर एक proxy असल्यावर त्यावर विश्वास ठेवण्यास सांगतो. त्यामुळे rate-limiting आणि client IP वाचणारे कोणतेही feature proxy च्या पत्त्याऐवजी वास्तविक address पाहते. येथे तुम्ही जाणीवपूर्वक सेट न करणारा एक variable म्हणजे N8N_RUNNERS_ENABLED. task runners n8n चे Code-node logic स्वतंत्र sandboxed process मध्ये चालवतात. ते 1.69 पासून default आहेत आणि या guide मध्ये निश्चित केलेल्या 2.x line पासून अनिवार्य आहेत. त्यामुळे जुना opt-in deprecated आहे. तो आता सेट केल्यास n8n तो काढून टाकण्यास सांगणारी notice log करते.

पहिली सुरुवात

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 मध्ये Up हे दोन्ही containers दिसले पाहिजेत आणि postgres हे (healthy) म्हणून चिन्हांकित असले पाहिजे. n8n Restarting loop मध्ये अडकत असल्यास logs तपासा. खाली स्पष्ट केलेल्या database connection किंवा volume permissions पैकी एखादी समस्या असणे हे याचे जवळजवळ नेहमीचे कारण असते.

रिव्हर्स proxy सह TLS

n8n स्वतः 5678 वर साधे HTTP वापरते; त्याच्या पुढे HTTPS termination करणारा घटक आवश्यक असतो. यासाठी दोन सोपे पर्याय आहेत.

तुम्ही आधीच अनेक containers चालवत असाल, तर आपोआप TLS प्रमाणपत्रे जारी करणाऱ्या Traefik reverse proxy च्या मागे n8n ठेवा. यासाठी काही labels पुरेसे आहेत. Traefik तुमच्यासाठी प्रमाणपत्राची विनंती करून त्याचे नूतनीकरण करते.

या मशीनवर हेच एकमेव अॅप असल्यास, Let's Encrypt प्रमाणपत्रासह nginx virtual host अधिक सोपा आहे. प्रमाणपत्र मिळवण्यासाठी 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 live execution updates editor कडे WebSocket द्वारे पाठवते. या दोन lines नसल्यास login page लोड होते आणि नंतर lost-connection banner दिसून तेथेच अडकते. proxy_read_timeout 3600 मुळे nginx च्या default 60 seconds नंतर दीर्घकाळ चालणाऱ्या executions बंद होत नाहीत. X-Forwarded-Proto $scheme header हा N8N_PROXY_HOPS=1 चा companion आहे. तो n8n ला सांगतो की मूळ request HTTPS होती, जरी proxy त्याच्याशी plain HTTP द्वारे जोडलेला असला तरी. त्यामुळे n8n connection असुरक्षित आहे असे ठरवत नाही आणि स्वतःची cookie नाकारत नाही.

तुमचा पहिला workflow प्रत्यक्षात आणा

https://n8n.example.com/ उघडा, owner account तयार करा (पुढील विभाग पहा) आणि मार्ग कार्यरत असल्याचे सिद्ध करणारा सर्वात लहान workflow तयार करा: webhook इनपुट, HTTP call आणि response आउटपुट.

1. Webhook node जोडा. Method POST वर सेट करा आणि hello सारखा path द्या. त्यात दोन URLs दिसतात: Test URL आणि Production URL. “माझा webhook काम करत नाही” या तक्रारींपैकी निम्म्या तक्रारींचे कारण हेच असते. तुम्ही Listen for test event वर क्लिक केलेले असेल, तेव्हाच Test URL एक call स्वीकारतो; त्यानंतर तो कालबाह्य होतो. Workflow Active असेल, तेव्हा Production URL प्रत्येक वेळी call स्वीकारतो.
2. त्यानंतर HTTP Request node जोडा आणि तो कोणत्याही सार्वजनिक JSON API कडे निर्देशित करा. https://api.github.com/zen ला GET केल्यास एका ओळीची string मिळते; त्यासाठी ते पुरेसे आहे.
3. Respond to Webhook node जोडा. Caller ला HTTP node चे output परत मिळावे यासाठी Webhook node मधील Respond पर्याय "Using Respond to Webhook node" असा सेट करा.
4. Workflow Active करा (वरच्या उजव्या बाजूला) आणि त्याला call करा: curl -X POST https://n8n.example.com/webhook/hello. तुम्हाला zen line परत मिळावी: POST इनपुट, API call आणि response आउटपुट. बहुतेक प्रत्यक्ष automations ची रचना अशीच असते.

Scheduled प्रकारात Webhook node ऐवजी Schedule Trigger वापरला जातो आणि त्याऐवजी model endpoint ला call केले जाते. त्याच VPS वर चालणारा Ollama वापरणे nightly summariser तयार करण्याचा व्यवस्थित मार्ग आहे.

मूलभूत auth नव्हे, वापरकर्ता व्यवस्थापन

जुन्या n8n मार्गदर्शकांमध्ये N8N_BASIC_AUTH_ACTIVE=true सेट करण्यास सांगितले जाते. n8n 1.0 मध्ये हे variables काढून टाकले गेले आणि आता त्यांचा कोणताही परिणाम होत नाही. सध्या authentication ही owner account वर आधारित आहे: तुम्ही editor पहिल्यांदा लोड करता तेव्हा n8n तुम्हाला email-and-password owner account तयार करण्यास सांगते. हा प्रवेश-अडथळा अनिवार्य आहे; anonymous mode उपलब्ध नाही. URL कोणालाही देण्यापूर्वी, first boot नंतर लगेच ही account तयार करा: docker compose up आणि पहिल्या form submission दरम्यान instance वर प्रथम पोहोचणारी व्यक्ती त्यावर दावा करू शकते. त्यावर reverse-proxy basic-auth layer लावणे हा अतिरिक्त lock म्हणून योग्य उपाय आहे. मात्र तो second factor आहे; तो वास्तविक authentication नाही. Owner account आणि या मार्गदर्शकातील इतर सर्व बाबी free community edition मध्ये उपलब्ध आहेत. पुढे granular roles असलेले extra users किंवा SSO हवे असल्यास, त्यांची योजना करण्यापूर्वी कोणत्या n8n features साठी paid licence आवश्यक आहे हे वाचणे उपयुक्त ठरेल.

बॅकअप: प्रथम encryption key, त्यानंतर database

दोन गोष्टींचा बॅकअप घेणे आवश्यक आहे. या दोन्ही गोष्टी समान प्रकारे बदलता येत नाहीत.

N8N_ENCRYPTION_KEY. n8n मध्ये साठवलेली प्रत्येक credential, API tokens, database passwords आणि OAuth secrets ही key वापरून at rest encryption केली जाते. ही key नसल्यास Postgres मधील workflows निरुपयोगी ठरतात. वेगळ्या key असलेल्या नवीन server वर database restore केल्यास n8n एकही credential decrypt करू शकत नाही. यासाठी recovery किंवा reset उपलब्ध नसतो. तुमच्या .env file मध्ये ही key असते. ती server च्या बाहेर सुरक्षित ठिकाणी कॉपी करा. Password-manager entry हा योग्य पर्याय आहे. ही प्रक्रिया key तयार केल्याच दिवशी करा. हा खरोखर महत्त्वाचा बॅकअप आहे.

Postgres database, ज्यामध्ये workflows, execution history आणि encrypted credentials साठवलेल्या असतात:

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

हे नियमित schedule वर चालवा आणि dump server च्या बाहेर कॉपी करा. नवीन VPS वर restore करण्यासाठी प्रथम stack एकदा सुरू करा, जेणेकरून database तयार होईल. त्यानंतर n8n थांबवा आणि psql वापरून dump पुन्हा load करा. तीच N8N_ENCRYPTION_KEY .env मध्ये ठेवा आणि n8n सुरू करा. तीच key आणि dump असल्यास instance कार्यरत होते. नवीन key वापरल्यास workflows मधील एकही credential वापरता येत नाही.

अपग्रेड: tag निश्चित करा

Compose फाइलमध्ये n8nio/n8n:2.29.10 ऐवजी latest जाणीवपूर्वक निश्चित केले आहे. n8n बहुतेक आठवड्यांत नवीन minor आवृत्ती release करते आणि त्यांमध्ये database schema किंवा node behaviour कधीकधी बदलते. त्यामुळे latest असल्यास, unattended pull मुळे अशी build मिळू शकते की सुरू होताच ती तुमच्या database चे migration करेल. एखादी आवृत्ती निश्चित करा. आवृत्ती वाढवण्यापूर्वी 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 default करण्यात आले. त्यामुळे process.env वाचणाऱ्या कोणत्याही Code node ला तुम्ही ते पुन्हा false वर सेट करेपर्यंत प्रवेश मिळत नाही; हा बदल कोणतीही सूचना न देता लागू होतो. त्याच release मध्ये settings file साठी strict permissions लागू करण्यात आल्या. Major boundary ओलांडण्यापूर्वी 2.0 breaking-changes page वाचा. n8n सुरू होताना आवश्यक database migrations आपोआप चालवते. म्हणूनच upgrade पूर्वीचे pg_dump ऐच्छिक नाही. Credentials .env मधील key ने encrypted स्वरूपात साठवलेली असतात आणि data Postgres मध्ये असतो. त्यामुळे containers disposable असतात: त्यांना बदलून upgrade करा आणि मागील tag निश्चित करून dump restore करा.

त्रुटीची कारणे आणि दिसणारे संदेश

The requested webhook "POST hello" is not registered. workflow Active नसताना त्याच्या webhook ला call केल्यास किंवा कोणीही listen करत नसताना test path ला call केल्यास 404 मिळतो. Test paths (/webhook-test/...) तुम्ही "Listen for test event" वर click केलेले असतानाच प्रतिसाद देतात; production paths (/webhook/...) workflow toggle on असतानाच प्रतिसाद देतात. शेजारील 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 unset किंवा चुकीचे आहे. त्यामुळे n8n ने तुमच्या public base ऐवजी N8N_HOST:N8N_PORT पासून address तयार केला. WEBHOOK_URL=https://n8n.example.com/ सेट करा आणि docker compose up -d वापरून container पुन्हा तयार करा. त्यानंतर port दिसणार नाही.

ब्राउझरमध्ये There was a problem loading init data दिसते. Editor load झाला आहे, पण त्याच्या backend API शी संपर्क साधू शकत नाही. Proxy मागे ही समस्या जवळजवळ नेहमी चुकीच्या N8N_HOST किंवा WEBHOOK_URL मुळे येते. Proxy मध्ये WebSocket Upgrade headers नसणे किंवा N8N_PROTOCOL तुमच्या connection पद्धतीशी जुळत नसणे हेही कारण असू शकते. Public-facing चारही variables आणि proxy Upgrade व Connection forward करतो का ते तपासा.

Container पुन्हा सुरू होत असताना logs मध्ये password authentication failed for user "n8n" दिसते. n8n पाठवत असलेला password database initialise करताना वापरलेल्या password शी जुळत नाही. येथे एक महत्त्वाची बाब आहे: Postgres POSTGRES_PASSWORD फक्त empty data directory initialise करतानाच वाचतो. Stack एकदा सुरू केल्यानंतर .env मधील POSTGRES_PASSWORD बदलल्यास, विद्यमान postgres_data volume मध्ये जुना passwordच राहतो. मूळ password पुन्हा सेट करा. किंवा data जतन करण्याची गरज नसल्यास docker compose down आणि docker volume rm वापरून postgres volume हटवा, त्यानंतर stack नव्याने सुरू करा.

सुरू करताना EACCES: permission denied, open '/home/node/.n8n/config' दिसते. n8n node user (UID 1000) म्हणून चालते आणि त्याच्या config directory मध्ये लिहू शकत नाही. Host folder bind-mount करताना (./n8n_data:/home/node/.n8n) तो root च्या मालकीचा असल्यास ही समस्या येते. वर दाखवलेला 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 line पासून n8n त्या settings file वर default ने 0600 लागू करते आणि boot वेळी ते स्वतः दुरुस्त करते. ही log line म्हणजे mode आधीच दुरुस्त केला आहे. Bind mount नंतर किंवा restore करताना file सैल permissions सह पुन्हा copy झाल्यानंतर हे सामान्यतः दिसते. कोणतीही कृती आवश्यक नाही. तुमची filesystem permissions खरोखर support करू शकत नसेल तरच N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false सेट करा.

Mismatching encryption keys यामध्ये fuller line सांगते की settings file मधील encryption key /home/node/.n8n/config तुमच्या environment मधील N8N_ENCRYPTION_KEY शी जुळत नाही. तुमच्या environment मधील key ही मागील run मध्ये n8n ने data volume मध्ये लिहिलेल्या key पेक्षा वेगळी आहे. Variable unset असताना n8n ने आधीच्या boot वेळी random key तयार केली आणि नंतर तुम्ही वेगळी key सेट केली, हे याचे सर्वात सामान्य कारण आहे. मूळ key .env मध्ये पुन्हा ठेवा. किंवा stored credentials जतन करण्यासारखे खरोखर काहीही नसल्यासच n8n_data volume मधील config file हटवा आणि 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 ने पोहोचलात. साधारणपणे IP आणि port थेट वापरल्यास, HTTPS proxy ऐवजी, ही समस्या येते. https://n8n.example.com/ वापरून n8n पर्यंत पोहोचा. HTTPS खरोखर वापरता येत नसेल तरच N8N_SECURE_COOKIE=false सेट करा. Internet-facing box वर हे कधीही करू नका.

त्या workflows मध्ये language model समाविष्ट करण्यासाठी Claude आणि n8n वापरून AI workflows तयार करणे पहा.

FAQ

n8n साठी SQLite वापरावे की Postgres?

n8n ची चाचणी घेण्यासाठी आणि एका वेळी एक workflow चालवणाऱ्या वैयक्तिक instance साठी SQLite (default) पुरेसे आहे. तुमच्या कामासाठी महत्त्वाचे असलेल्या कोणत्याही वापरासाठी Postgres वापरा: concurrency दरम्यान SQLite चा single writer lock database is locked निर्माण करतो, तर Postgres चा backup pg_dump वापरून व्यवस्थित घेता येतो. नंतर migration करणे manual असते. त्यामुळे server महत्त्वाचा असल्यास सुरुवातीपासून Postgres वापरा.

माझे n8n webhooks कधीच fire का होत नाहीत?

बहुतेक वेळा कारण WEBHOOK_URL असते. हे unset किंवा चुकीचे असल्यास, n8n N8N_HOST:N8N_PORT पासून तयार केलेले webhook addresses दाखवतो. त्यात अनेकदा :5678 किंवा localhost असते. ते addresses वैध दिसतात, पण internet वरून पोहोचता येत नाहीत. त्यामुळे caller च्या requests कधीच n8n पर्यंत पोहोचत नाहीत. WEBHOOK_URL=https://n8n.example.com/ सेट करा आणि node मध्ये port नसलेली URL दिसत आहे याची खात्री करा. दुसरे कारण म्हणजे workflow Active केलेले नसताना त्याच्या webhook ला call करणे. अशा वेळी The requested webhook ... is not registered. मिळतो.

n8n मध्ये कोणत्या गोष्टींचा backup घ्यावा?

दोन गोष्टींचा backup घ्या. तुमच्या .env file मधील N8N_ENCRYPTION_KEY जतन करा. प्रत्येक stored credential त्याच्याने encrypted केलेले असते. तो key हरवल्यास credentials कायमचे undecryptable होतात. तो तयार केल्याच्या दिवशीच server च्या बाहेर त्याची copy ठेवा. तसेच workflows, history आणि credentials असलेल्या Postgres database चा pg_dump घ्या. Restore करण्यासाठी दोन्ही आवश्यक असतात: तोच key आणि dump.

n8n ला HTTPS मागे कसे ठेवावे?

n8n port 5678 वर plain HTTP देते. तिच्यासमोरील reverse proxy TLS termination करतो. n8n ला 127.0.0.1:5678 वर bind करा, जेणेकरून फक्त proxy तिला पोहोचू शकेल. त्यानंतर automatic certificates सह Traefik किंवा Let's Encrypt certificate सह nginx वापरा. N8N_PROTOCOL=https आणि WEBHOOK_URL=https://your-host/ सेट करा. Proxy WebSocket Upgrade headers forward करतो याची खात्री करा. अन्यथा editor अडकतो.

n8n सुरक्षितपणे upgrade कसे करावे?

latest ऐवजी विशिष्ट image tag pin करा. प्रथम pg_dump घ्या, कारण n8n सुरू होताना migrations आपोआप चालवते. Breaking changes साठी release notes वाचा. त्यानंतर tag अपडेट करा आणि docker compose pull n8n && docker compose up -d n8n चालवा. Container disposable असल्याने, मागील tag pin करून आणि upgrade पूर्वी घेतलेला dump restore करून rollback करता येतो.