SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-27

VPSలో n8n self-hosting: Docker మరియు HTTPS

Docker Compose, Postgres, reverse proxyతో VPSలో n8n నడపండి. WEBHOOK_URL, encryption-key తప్పిదాలు మరియు కనిపించే ప్రతి error stringకు పరిష్కారాలు తెలుసుకోండి.

మీరు నిర్మించేది

n8n ఒక workflow automation సాధనం. ఇది visual editor. ఇందులో trigger, webhook, schedule లేదా form submission జరిగినప్పుడు, APIs ను పిలిచే, data ను మార్చే, ఇతర systems లో రాసే nodes యొక్క chain ప్రారంభమవుతుంది. మీరు స్వయంగా service రాయకుండానే ప్రతి model provider మరియు database తో అనుసంధానం చేయగలగడం వల్ల, AI-agent workflows కోసం ఇది ప్రామాణిక glue గా మారింది. ఒక docker run ద్వారా రెండు నిమిషాల్లో పని చేసే editor లభిస్తుంది. ఈ guide లో మిగిలిన తొంభై శాతం విషయాలు ఉన్నాయి: default SQLite file బదులుగా Postgres తో దీన్ని స్థిరంగా నడపడం, HTTPS ద్వారా అందుబాటులో ఉంచడం, అలాగే దాదాపు అందరూ తప్పు చేసే ముఖ్యమైన అంశం అయిన webhooks కు బయటి ప్రపంచం నిజంగా చేరుకోగల URL ఇవ్వడం.

చివరికి ఒకే Docker network లో రెండు containers ఉంటాయి: n8n స్వయంగా ఒకటి, దాని workflows మరియు credentials ను నిల్వ చేసే Postgres database మరొకటి. Host పై ఉన్న reverse proxy TLS termination చేస్తుంది మరియు localhost లోని n8n కు requests ను forward చేస్తుంది. అందువల్ల proxy ద్వారా తప్ప మరే service internet కు నేరుగా అందుబాటులో ఉండదు. ఇది 2026 self-hosting జాబితా లోని ఇతర services పక్కన నడుస్తుంది.

అవసరాలు మరియు వాస్తవ పరిమితులు

మీకు కనీసం 1 GB RAM ఉన్న VPS అవసరం. Workflows వాస్తవంగా పని చేయడం ప్రారంభించిన తర్వాత 2 GB కోసం ప్రణాళిక వేయండి. Executions మరియు Node.js runtime కలిసి memoryని వినియోగిస్తాయి. మధ్యలో containerను out-of-memory killer ఆపివేయడం ద్వారా ఈ విషయం తెలుసుకోవడం చాలా ఇబ్బందికరం. ప్రారంభానికి ఒక vCPU సరిపోతుంది.

ఈ serverలో మరింత resource-intensive సేవ కూడా నడిస్తే, ముందుగా ఆ సేవ ఆధారంగా server పరిమాణాన్ని నిర్ణయించండి. సాధారణంగా photo library ప్రధాన కారణంగా ఉంటుంది. PhotoPrism మరియు Immich కోసం అవసరమైన వాస్తవ RAM కనిష్ఠాలు n8n అవసరాలకన్నా చాలా ఎక్కువగా ఉంటాయి.

Media serverకూ ఇదే వర్తిస్తుంది. Jellyfin serverతో పాటు దాని కోసం browsable front end, ఉదాహరణకు libraryని 90s rental shopలా మళ్లీ రూపొందించే Halcyon, n8nకు అవసరం గుర్తించబడేలోపే RAM మరియు transcoding headroomను వినియోగిస్తుంది.

మీకు ఒక domain లేదా subdomain అవసరం, ఉదాహరణకు n8n.example.com. దానికి VPS public IP ను చూపించే A record ఉండాలి. Certificate కోసం అభ్యర్థించే ముందు ఆ record resolve కావాలి. Proxy కోసం ports 80 మరియు 443 తెరిచి ఉండాలి. n8n ఉపయోగించే port 5678 మాత్రం internet‌కు అందుబాటులో ఉండకూడదు. మీకు Docker Engine మరియు Compose plugin అవసరం. docker compose version తో errorగా 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 సమయంలో data పోతుంది. అది కూడా ఒక ప్రత్యేకమైన పాఠమే. Postgres కు మారడానికి కారణం raw speed కాదు. SQLite ఒకేసారి ఒక writer lock మాత్రమే ఉంచుతుంది. అందువల్ల ఒకే సమయంలో అనేక workflows నడిపే instance లేదా మీరు తరువాత ఉపయోగించాలనుకునే queue mode, concurrency పెరిగినప్పుడు SQLITE_BUSY: database is locked ను విసురుతుంది. Postgres కు ఈ పరిమితి లేదు. pg_dump తో దాన్ని సులభంగా back up చేయవచ్చు. మీరు ఆధారపడే server కోసం n8n యొక్క స్వంత documentation కూడా Postgres నే పరిగణిస్తుంది. తరువాత మారాలంటే data ను చేతితో migrate చేయాలి. కాబట్టి ఈ box ముఖ్యమైనదైతే, మొదటి నుంచే Postgres తో ప్రారంభించండి.

DNS మరియు firewall

ముందుగా DNS record ను సరైన స్థానానికి point చేసి, అవసరమైన ports ను open చేయండి. ఇలా చేయకపోతే తరువాత certificate దశలో resolve కాని name కారణంగా ప్రక్రియ విఫలమవుతుంది.

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 ను open చేయవద్దు. compose file n8n ను 127.0.0.1:5678 కు bind చేస్తుంది. అందువల్ల host యొక్క reverse proxy మాత్రమే దాన్ని చేరుకోగలదు. ufw allow 5678 ఉపయోగిస్తే ఈ isolation తొలగిపోతుంది.

Compose ఫైల్

పనిచేసే డైరెక్టరీని సృష్టించి, ఒక docker-compose.yml తయారు చేయండి. ఇదే మొత్తం stack: రెండు సేవలు, ఒక 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 పై resolve చేస్తుంది. localhost కాదు. n8n container లో localhost అంటే n8n స్వయమే. depends_on లోని condition: service_healthy, boot సమయంలో n8n Postgres కంటే ముందుగా ప్రారంభమయ్యే పరిస్థితిని నివారిస్తుంది. ఇది లేకపోతే n8n ప్రారంభమై database కనిపించకపోవడంతో exit అవుతుంది. /home/node/.n8n వద్ద ఉన్న named volume n8n_data encryption key ని, SQLite ఉపయోగించినప్పుడు database ను కూడా నిల్వ చేస్తుంది. మీరు ఎట్టి పరిస్థితుల్లోనూ కోల్పోకూడని ఒకే directory ఇదే. Image ను ఖచ్చితమైన version కు pin చేయండి. ఎప్పుడూ latest ఉపయోగించవద్దు. కారణాలు కింద ఉన్న upgrade section లో ఉన్నాయి.

సీక్రెట్స్ ఫైల్

పాస్‌వర్డ్‌లను compose file లో ఎప్పుడూ ఉంచవద్దు. Compose స్వయంచాలకంగా చదివే .env ఫైల్‌లో వాటిని ఉంచండి. అవి నిజంగా యాదృచ్ఛికంగా ఉండేలా వాటిని generate చేయండి.

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 ను encrypt చేయడానికి ఉపయోగించే key ఇదే. n8n దాన్ని స్వయంగా generate చేయనివ్వకుండా, దీన్ని explicit గా set చేయండి. మీరు generate చేసిన విలువను రాసి ఉంచి restore చేయవచ్చు. ఈ key తో n8n మొదటి credential ను encrypt చేసిన తర్వాత, దీన్ని మార్చితే ప్రతి credential ను decrypt చేయడం సాధ్యం కాదు. కాబట్టి దీన్ని ఇప్పుడు ఒకసారి set చేసి, ఆ line ను ఇక ఎప్పుడూ మార్చవద్దు.

వెబ్‌హుక్‌లు పనిచేయాలా వద్దా నిర్ణయించే env vars

n8n తనను బయటి ప్రపంచానికి ఎలా చూపించాలో నాలుగు variables నియంత్రిస్తాయి. వీటిని తప్పుగా సెట్ చేయడం n8n support లో తరచుగా కనిపించే ప్రధాన సమస్య.

  • N8N_HOST అనేది public hostname, n8n.example.com. Proxy వెనుక default localhost గా ఉంచితే editor తన API ను మీ browser లోని localhost నుంచి లోడ్ చేయడానికి ప్రయత్నిస్తుంది. అది విఫలమవుతుంది.
  • N8N_PROTOCOL=https ద్వారా n8n తాను TLS ద్వారా అందించబడుతున్నట్లు తెలుసుకుంటుంది. అందువల్ల అది session cookie ను Secure గా గుర్తించి, https:// URLs ను రూపొందిస్తుంది.
  • N8N_PORT=5678 అనేది container లోపల n8n listening చేస్తున్న port. ఇది public port కాదు. 443 ను proxy నిర్వహిస్తుంది.
  • WEBHOOK_URL=https://n8n.example.com/ వల్ల ఎక్కువగా సమస్యలు వస్తాయి. ఈ values ఆధారంగా webhook addresses ను n8n రూపొందిస్తుంది. ఆ addresses ను Stripe, GitHub లేదా ఇతర external callers లో paste చేస్తారు. ఇది unset గా లేదా తప్పుగా ఉంటే n8n N8N_HOST:N8N_PORT కు fallback అవుతుంది. అప్పుడు అది https://n8n.example.com:5678/webhook/... లేదా, ఇంకా దారుణంగా, http://localhost:5678/webhook/... ను ఇస్తుంది. ఇవి error లేకుండా print అవుతాయి, చూడటానికి సరైనవిగా కనిపిస్తాయి, కానీ internet నుంచి చేరుకోలేరు. అందువల్ల caller పంపిన requests నిశ్శబ్దంగా ఎక్కడికీ చేరవు. దీన్ని trailing slash తో కూడిన ఖచ్చితమైన public base URL గా సెట్ చేయండి. తరువాత webhook node చూపించే URL లో port లేదని నిర్ధారించండి.

N8N_PROXY_HOPS=1 ద్వారా n8n యొక్క Express server తన ముందు ఒక proxy ఉందని నమ్ముతుంది. అందువల్ల rate-limiting మరియు client IP చదివే ఇతర features proxy address బదులు నిజమైన 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, దాని పైభాగంలో n8n ready on ..., port 5678 line మరియు చివరలో Editor is now accessible via: line తో ముగుస్తుంది. docker compose ps రెండు containers అయిన Up ను చూపాలి. అందులో postgres కు (healthy) గా గుర్తింపు ఉండాలి. n8n Restarting loop లోనే ఉంటే logs ను పరిశీలించండి. సాధారణంగా కారణం database connection లేదా దిగువ వివరించిన volume permissions అయి ఉంటుంది.

రివర్స్ proxyతో TLS

n8n స్వయంగా 5678పై plain HTTP మాట్లాడుతుంది; దాని ముందు ఉండే భాగం HTTPS termination చేయాలి. దీనికి రెండు సరళమైన ఎంపికలు ఉన్నాయి.

మీరు ఇప్పటికే అనేక containers నడుపుతున్నట్లయితే, TLS certificates ను స్వయంచాలకంగా జారీ చేసే Traefik reverse proxy వెనుక n8n ను ఉంచండి. కొన్ని labels తోనే Traefik మీ కోసం certificate ను అభ్యర్థించి renew చేస్తుంది.

ఈ serverలో n8n మాత్రమే నడుస్తుంటే, Let's Encrypt certificate తో nginx virtual host సరళంగా ఉంటుంది. Certificate పొందడానికి Ubuntu 24.04 కోసం Certbot మరియు nginx TLS setup ను ఉపయోగించండి. తరువాత ఈ 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 load అవుతుంది, తరువాత lost-connection bannerతో నిలిచిపోతుంది. nginx యొక్క default 60 seconds గడువు వల్ల long-running executions మధ్యలో నిలిచిపోకుండా proxy_read_timeout 3600 నిర్ధారిస్తుంది. X-Forwarded-Proto $scheme header, N8N_PROXY_HOPS=1 కు అనుబంధంగా ఉంటుంది. Proxy n8n ను plain HTTP ద్వారా చేరుకున్నప్పటికీ, అసలు request HTTPS ద్వారా వచ్చిందని ఇది n8n కు తెలియజేస్తుంది. అందువల్ల connection సురక్షితం కాదని n8n భావించి తన cookieని తిరస్కరించదు.

మీ మొదటి workflow: దీన్ని వాస్తవంగా అమలు చేయడం

https://n8n.example.com/ తెరిచి, owner account ను (తదుపరి విభాగంలో) సృష్టించండి. మార్గం సరిగ్గా పనిచేస్తుందని నిర్ధారించే అతి చిన్న workflow ను రూపొందించండి: webhook ఇన్‌పుట్, HTTP call, response అవుట్.

  1. Webhook node ను జోడించండి. method ను POST కు, path ను hello వంటి విలువకు సెట్ చేయండి. ఇది Test URL మరియు Production URL అనే రెండు URLs ను చూపిస్తుంది. “నా webhook పనిచేయడం లేదు” అనే నివేదికల్లో సగానికి ఇదే కారణం. మీరు Listen for test event పై click చేసినప్పుడు మాత్రమే, ఒక్క call కు Test URL స్పందిస్తుంది. ఆ తర్వాత అది గడువు ముగుస్తుంది. workflow Active గా ఉన్నప్పుడు Production URL స్పందిస్తుంది.
  2. దాని తర్వాత HTTP Request node ను జోడించి, దాన్ని ఏదైనా public JSON API కు point చేయండి. https://api.github.com/zen కు GET request పంపితే ఒకే పంక్తి string వస్తుంది; ఇది సరిపోతుంది.
  3. Respond to Webhook node ను జోడించండి. caller కు HTTP node output తిరిగి అందేలా, Webhook node లోని Respond option ను "Using Respond to Webhook node" గా సెట్ చేయండి.
  4. workflow ను (కుడి ఎగువన) Active కు toggle చేసి, దానికి call చేయండి: curl -X POST https://n8n.example.com/webhook/hello. మీకు zen line తిరిగి రావాలి. POST ఇన్‌పుట్, API call, response అవుట్ — చాలా వాస్తవ automation workflows యొక్క నిర్మాణం ఇదే.

షెడ్యూల్ ఆధారిత రూపంలో Webhook node స్థానంలో Schedule Trigger ఉంటుంది మరియు బదులుగా model endpoint కు call చేస్తుంది. అదే VPS పై నడుస్తున్న Ollama వంటి self-hosted ఎంపికతో ప్రతి రాత్రి summary రూపొందించే workflow ను సులభంగా నిర్మించవచ్చు.

వినియోగదారు నిర్వహణ, basic auth కాదు

పాత n8n మార్గదర్శకాలు N8N_BASIC_AUTH_ACTIVE=true ను సెట్ చేయమని సూచిస్తాయి. ఆ variables n8n 1.0లో తొలగించబడ్డాయి, ఇప్పుడు అవి ఎలాంటి ప్రభావం చూపవు. ప్రస్తుతం authentication owner account ద్వారా జరుగుతుంది: మీరు editor ను మొదటిసారి తెరిచినప్పుడు, n8n మీతో email-and-password owner ను సృష్టించిస్తుంది. ఈ రక్షణ తప్పనిసరి; anonymous mode లేదు. మొదటి boot తర్వాత, URL ను ఎవరికైనా అందించే ముందు వెంటనే ఈ account ను సృష్టించండి. docker compose up మరియు ఆ మొదటి form submission మధ్యలో instance ను ముందుగా చేరుకున్న వ్యక్తి claim చేయగలడు. దీనికి అదనంగా reverse-proxy basic-auth layer ఉంచడం సముచితమైన extra lock, కానీ అది రెండవ రక్షణ మాత్రమే; అసలు authentication కాదు. ఈ మార్గదర్శకంలోని owner account మరియు మిగతా అన్ని అంశాలు free community edition లో పనిచేస్తాయి. తరువాత granular roles ఉన్న అదనపు users లేదా SSO కావాలనుకుంటే, ప్రణాళిక రూపొందించే ముందు ఏ n8n features కు paid licence అవసరం చదవడం మంచిది.

బ్యాకప్‌లు: ముందుగా encryption key, తరువాత database

బ్యాకప్ చేయాల్సిన రెండు అంశాలు ఉన్నాయి. వాటిని తిరిగి పొందే అవకాశాలు సమానంగా ఉండవు.

N8N_ENCRYPTION_KEY. n8nలో మీరు నిల్వ చేసే ప్రతి credential — API tokens, database passwords, OAuth secrets — ఈ keyతో నిల్వ సమయంలో encrypt చేయబడుతుంది. ఇది లేకుండా Postgresలోని workflows ఉపయోగించలేరు. వేరే keyతో కొత్త serverలో databaseను restore చేస్తే, n8n ఒక్క credentialను కూడా decrypt చేయలేరు. Recovery లేదా resetకు మార్గం ఉండదు. మీ .env fileలో ఈ key ఉంటుంది. దాన్ని server వెలుపల సురక్షిత ప్రదేశానికి కాపీ చేయండి. Password managerలో entryగా అదే రోజు భద్రపరచడం ఉత్తమం. నిజంగా ముఖ్యమైన backup ఇదే.

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 చేయడానికి: database సృష్టించబడేలా stackను ఒకసారి ప్రారంభించండి, n8nను ఆపండి, psqlతో dumpను తిరిగి load చేయండి, అదే N8N_ENCRYPTION_KEY ను .envలో ఉంచి, n8nను ప్రారంభించండి. అదే keyతో dump ఉంటే పనిచేసే instance సిద్ధమవుతుంది. కొత్త key ఉపయోగిస్తే ఒక్క credentialను కూడా ఉపయోగించలేని workflows మాత్రమే మిగులుతాయి.

అప్‌గ్రేడ్‌లు: tag ను pin చేయండి

compose file ఉద్దేశపూర్వకంగా n8nio/n8n:2.29.10 కు బదులుగా latest ను pin చేస్తుంది. n8n చాలా వారాల్లో కొత్త minor version ను విడుదల చేస్తుంది. కొన్నిసార్లు వాటి మధ్య database schema లేదా node ప్రవర్తన మారుతుంది. అందువల్ల latest ఉపయోగిస్తే unattended pull ప్రారంభమైన వెంటనే database ను migrate చేసే build ను అందించవచ్చు. Version ను pin చేయండి. Version పెంచే ముందు 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 గా మార్చింది. అందువల్ల process.env ను చదివే ఏ Code node అయినా, దాన్ని తిరిగి false కు సెట్ చేసే వరకు, ఎలాంటి స్పష్టమైన error లేకుండానే access కోల్పోతుంది. అదే release settings file పై strict permissions ను అమలు చేయడం ప్రారంభించింది. Major boundary దాటే ముందు 2.0 breaking-changes page చదవండి. ప్రారంభ సమయంలో అవసరమైన database migrations ను n8n స్వయంచాలకంగా అమలు చేస్తుంది. అందుకే upgrade కు ముందు చేసే pg_dump ఐచ్ఛికం కాదు. Credentials, .env లోని key తో encrypted గా నిల్వ ఉంటాయి. Data Postgres లో ఉంటుంది. కాబట్టి containers ను తొలగించి మళ్లీ సృష్టించవచ్చు. Previous tag ను pin చేసి dump ను restore చేయడం ద్వారా upgrade చేయండి లేదా rollback చేయండి.

మీరు చూడగలిగే సందేశాలతో వైఫల్య పరిస్థితులు

The requested webhook "POST hello" is not registered. workflow Active లో లేకపోయినప్పుడు webhook ను call చేయడం వల్ల లేదా ఎవరూ listen చేయని సమయంలో test path ను call చేయడం వల్ల 404 వస్తుంది. మీరు "Listen for test event" పై click చేసినంతకాలం మాత్రమే test paths (/webhook-test/...) స్పందిస్తాయి. Workflow toggle on లో ఉన్నప్పుడు మాత్రమే production paths (/webhook/...) స్పందిస్తాయి. పక్కనే ఉన్న 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 లోడ్ అయింది, కానీ తన backend API ను చేరుకోలేకపోతోంది. Proxy వెనుక ఇది సాధారణంగా తప్పు N8N_HOST లేదా WEBHOOK_URL, proxy లో WebSocket Upgrade headers లేకపోవడం, లేదా మీరు connect అయ్యే విధానానికి N8N_PROTOCOL సరిపోకపోవడం వల్ల జరుగుతుంది. Public-facing variables నాలుగింటినీ నిర్ధారించండి. Proxy Upgrade మరియు Connection ను forward చేస్తుందో కూడా నిర్ధారించండి.

Logs లో password authentication failed for user "n8n" కనిపిస్తుంది, container మళ్లీ restart అవుతుంది. n8n పంపే password, database initialise చేసినప్పుడు ఉపయోగించిన password తో సరిపోలడం లేదు. ముఖ్యమైన విషయం: Postgres POSTGRES_PASSWORD ను ఖాళీ data directory ను initialise చేస్తున్నప్పుడు మాత్రమే చదువుతుంది. Stack ను ఒకసారి ప్రారంభించిన తరువాత .env లోని POSTGRES_PASSWORD ను మార్చితే, ఇప్పటికే ఉన్న postgres_data volume లో పాత password అలాగే ఉంటుంది. దాన్ని అసలు password కు తిరిగి మార్చండి. ఉంచాల్సిన data ఏదీ లేకపోతే, postgres volume ను docker compose down చేసి docker volume rm చేయండి. తరువాత దాన్ని కొత్తగా ప్రారంభించండి.

ప్రారంభ సమయంలో 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 line నుంచి n8n ఆ settings file పై default గా 0600 ను అమలు చేస్తుంది మరియు boot సమయంలో దాన్ని స్వయంగా సరిచేస్తుంది. ఈ log line కనిపిస్తే mode ఇప్పటికే సరిచేయబడిందని అర్థం. సాధారణంగా bind mount తర్వాత లేదా restore సమయంలో loose permissions తో file తిరిగి copy అయినప్పుడు ఇది జరుగుతుంది. ఎలాంటి చర్య అవసరం లేదు. మీ filesystem permissions కు నిజంగా మద్దతు ఇవ్వలేకపోతే మాత్రమే N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false సెట్ చేయండి.

Mismatching encryption keys, పూర్తి log 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 ద్వారా చేరుకున్నారు. సాధారణంగా HTTPS proxy బదులుగా IP మరియు port ను నేరుగా ఉపయోగించినప్పుడు ఇది జరుగుతుంది. https://n8n.example.com/ ద్వారా చేరుకోండి. HTTPS ను నిజంగా ఉపయోగించలేని పరిస్థితిలో మాత్రమే N8N_SECURE_COOKIE=false సెట్ చేయండి. Internet-facing server పై దీన్ని ఎప్పుడూ ఉపయోగించవద్దు.

ఆ workflows లో language model ను చేర్చడం కోసం Claude మరియు n8n తో AI workflows నిర్మించడం చూడండి.

FAQ

n8n కోసం SQLite లేదా Postgres ఉపయోగించాలా?

n8n ను పరీక్షించడానికి, ఒకేసారి ఒక workflow మాత్రమే నడిచే వ్యక్తిగత instance కోసం SQLite (డిఫాల్ట్) సరిపోతుంది. మీరు ఆధారపడే ఏ ఉపయోగానికైనా Postgres కు మారండి: concurrency సమయంలో SQLite యొక్క single writer lock వల్ల database is locked వస్తుంది, అయితే Postgres ను pg_dump తో సరిగ్గా backup చేయవచ్చు. తరువాత migration మాన్యువల్‌గా చేయాలి. కాబట్టి ఈ server ముఖ్యమైనదైతే మొదటి నుంచే Postgres ఉపయోగించండి.

నా n8n webhooks ఎందుకు ఎప్పుడూ fire కావడం లేదు?

దాదాపు ఎల్లప్పుడూ కారణం WEBHOOK_URL. ఇది unset గా లేదా తప్పుగా ఉంటే, n8n N8N_HOST:N8N_PORT ఆధారంగా webhook addresses ను రూపొందిస్తుంది. వాటిలో తరచుగా :5678 లేదా localhost ఉంటుంది. అవి సరైనవిగా కనిపించినా internet నుంచి చేరుకోలేరు. అందువల్ల caller పంపిన requests ఎప్పుడూ చేరవు. WEBHOOK_URL=https://n8n.example.com/ ను set చేసి, node చూపించే URL లో port లేదని నిర్ధారించండి. రెండవ కారణం, workflow Active గా toggle చేయకుండానే దాని webhook ను call చేయడం. అప్పుడు The requested webhook ... is not registered. తిరిగి వస్తుంది.

n8n లో ఏమి backup చేయాలి?

రెండు విషయాలు. మీ .env file లోని N8N_ENCRYPTION_KEY తప్పనిసరిగా backup చేయాలి. Stored credential ప్రతి దానిని దానితో encrypt చేస్తారు. దాన్ని కోల్పోతే credentials ను శాశ్వతంగా decrypt చేయలేరు. దాన్ని సృష్టించిన రోజే 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/ ను set చేయండి. Proxy WebSocket Upgrade headers ను forward చేస్తోందని కూడా నిర్ధారించండి. లేకపోతే editor నిలిచిపోతుంది.

n8n ను సురక్షితంగా ఎలా upgrade చేయాలి?

latest కు బదులుగా నిర్దిష్ట image tag ను pin చేయండి. ముందుగా pg_dump తీసుకోండి, ఎందుకంటే n8n start సమయంలో migrations ను స్వయంచాలకంగా అమలు చేస్తుంది. Breaking changes కోసం release notes చదివి, తరువాత tag ను మార్చి docker compose pull n8n && docker compose up -d n8n అమలు చేయండి. Container ను తొలగించి మళ్లీ సృష్టించవచ్చు. కాబట్టి మునుపటి tag ను pin చేసి, upgrade కు ముందు తీసిన dump ను restore చేయడం ద్వారా rollback చేయవచ్చు.

#n8n#automation#docker#self-hosting#https