SSD Nodes Learn
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-07-25

VPS-ல் n8n self-host: Docker + HTTPS முழு வழிகாட்டி

Docker Compose, Postgres, reverse proxy கொண்டு VPS-ல் n8n-ஐ HTTPS உடன் இயக்குவது எப்படி? WEBHOOK_URL, encryption key பிழைகள் மற்றும் அனைத்து error strings-ம் இங்கே விளக்கப்பட்டுள்ளன.

நீங்கள் எதை உருவாக்கிக் கொண்டிருக்கிறீர்கள்

n8n என்பது ஒரு workflow automation tool ஆகும். இது ஒரு visual editor ஆகும். இங்கே ஒரு trigger — ஒரு webhook, ஒரு schedule, ஒரு form submission — பல nodes-களின் சங்கிலியைச் செயல்படுத்துகிறது. அந்த nodes-கள் API-களை அழைக்கின்றன, data-வை மாற்றி அமைக்கின்றன, மற்ற கணினிகளில் எழுதுகின்றன. இது AI-agent workflows-க்கான இயல்புநிலை இணைப்பாக மாறியுள்ளது. ஏனெனில் நீங்கள் ஒரு service எழுதாமலேயே ஒவ்வொரு model provider மற்றும் database-உடனும் இது பேசுகிறது. ஒரு docker run இரண்டு நிமிடங்களில் ஒரு வேலை செய்யும் editor-ஐத் தருகிறது. இந்த வழிகாட்டி மீதமுள்ள தொண்ணூறு சதவீதத்தைப் பற்றியது: இயல்புநிலை SQLite file-க்குப் பதிலாக Postgres உடன் இதை நிலையானதாக ஆக்குவது, HTTPS வழியாக அணுகத்தக்கதாக ஆக்குவது, மற்றும் — கிட்டத்தட்ட அனைவரும் தவறாகச் செய்யும் பகுதி — webhooks-கள் வெளிப்புற உலகம் உண்மையில் அணுகக்கூடிய ஒரு URL-ஐ வழங்குவதை உறுதிசெய்வது.

முடிந்த stack என்பது ஒரே Docker network-இல் இரண்டு containers ஆகும்: n8n அதனுள்ளே, மற்றும் அதன் workflows மற்றும் credentials-ஐ கொண்டிருக்கும் ஒரு Postgres database. Host-இல் உள்ள ஒரு reverse proxy, TLS-ஐ முடித்து localhost-இல் n8n-க்கு முன்னோக்கி அனுப்புகிறது. எனவே அந்த proxy வழியாக மட்டுமே ஏதாவது internet-ஐ நோக்கி திறக்கப்படுகிறது. இது 2026 self-hosting shortlist-இல் உள்ள மற்ற சேவைகளுக்கு கீழே அமைகிறது.

முன்தேவைகள், மற்றும் உண்மையான வரம்புகள்

குறைந்தது 1 GB RAM கொண்ட ஒரு VPS உங்களுக்குத் தேவை. ஒரு vCPU தொடங்குவதற்குப் போதுமானது. பணிப்பாய்வுகள் உண்மையான வேலையைச் செய்யத் தொடங்கியதும் 2 GB திட்டமிடுங்கள். ஏனெனில் செயல்பாடுகள் மற்றும் Node.js இயக்கநேரம் ஆகியவை நினைவகத்தை நுகர்கின்றன. இயக்கத்தின் நடுவே out-of-memory killer கொள்கலனைக் கொல்வது இதை நீங்கள் கற்றுக்கொள்வதற்கான ஒரு கடினமான வழியாகும்.

ஒரு டொமைன் அல்லது துணைடொமைன் — உதாரணமாக n8n.example.com — உங்களுக்குத் தேவை. சான்றிதழைக் கோருவதற்கு முன்பு, A record ஆனது VPS பொது IP-யை நோக்கி இருக்க வேண்டும் மற்றும் அது தீர்க்கப்பட வேண்டும். Port 80 மற்றும் 443 ஆகியவை ப்ராக்ஸிக்குத் திறந்திருக்க வேண்டும். n8n-ன் சொந்த port 5678 இணையத்தை நோக்கித் திறந்திருக்கக் கூடாது. Docker Engine மற்றும் Compose plugin உங்களுக்குத் தேவை. docker compose version என்பது docker: 'compose' is not a docker command பிழையைத் தருகிறது என்றால், பழைய தனித்த பைனரி உங்களிடம் உள்ளது; plugin ஆனது sudo apt install docker-compose-plugin ஆகும்.

SQLite சோதனைக்கு போதுமானது, நீங்கள் நம்பும் எதற்கும் Postgres பயன்படுத்தவும்

n8n-ன் இயல்புநிலை தரவுத்தளம் /home/node/.n8n/database.sqlite-ல் உள்ள ஒரு SQLite கோப்பு. ஆரம்ப சோதனைக்கு இது போதுமானது. நீங்கள் எந்த volume-ம் இணைக்கவில்லை என்றால், முதல் container-ஐ மறுஉருவாக்கம் செய்யும்போதே இந்தக் கோப்பு இழக்கப்படும். இதுவே ஒரு பாடம். Postgres-க்கு மாறுவதற்கான காரணம் வெறும் வேகம் அல்ல. SQLite ஒரே ஒரு writer lock-ஐ மட்டுமே வைத்திருக்கும். எனவே, ஒரே நேரத்தில் பல workflow-க்களை இயக்கும் instance, அல்லது நீங்கள் இறுதியில் தேவைப்படும் queue mode, concurrency-யின்போது SQLITE_BUSY: database is locked பிழையை எறியும். Postgres-க்கு இந்த வரம்பு கிடையாது. pg_dump மூலம் இது சுத்தமாக backup செய்யப்படும். மேலும், நீங்கள் சார்ந்திருக்கும் server-க்கு n8n-ன் சொந்த ஆவணங்களும் Postgres-ஐயே கருதுகின்றன. பிறகு மாறினால் தரவை கைமுறையாக migrate செய்ய வேண்டும். எனவே, இந்த அமைப்பு முக்கியமானது என்றால், Postgres-லேயே தொடங்கவும்.

DNS மற்றும் ஃபயர்வால்

முதலில் பதிவை சுட்டிக்காட்டி போர்ட்களைத் திறக்கவும். இதனால் பின்னர் சான்றிதழ் படி தீர்க்கப்படாத பெயரில் தோல்வியடையாது.

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 கோப்பு n8n-ஐ 127.0.0.1:5678 உடன் பிணைக்கிறது. எனவே ஹோஸ்டின் reverse proxy மட்டுமே அதை அணுக முடியும். ஒரு ufw allow 5678 அந்த தனிமைப்படுத்தலை நீக்கிவிடும்.

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 மறைகுறியாக்க விசையையும், SQLite-ல் தரவுத்தளத்தையும் கொண்டுள்ளது — இதுவே நீங்கள் கட்டாயம் இழக்கக் கூடாத ஒரே கோப்பகம். படிமத்தை ஒரு சரியான பதிப்பிற்குப் பொருத்தவும், latest என்று ஒருபோதும் விடாதீர்கள்; காரணங்கள் கீழே உள்ள மேம்படுத்தல் பிரிவில் உள்ளன.

ரகசியங்கள் கோப்பு

கடவுச்சொற்களை 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 இங்கே மிக முக்கியமான சரம் ஆகும் — ஒவ்வொரு சேமிக்கப்பட்ட நற்சான்றிதழும் இந்த விசையால் மறையாக்கம் செய்யப்படுகிறது. n8n ஒன்றை தானாக உருவாக்க அனுமதிப்பதற்கு பதிலாக இதை வெளிப்படையாக அமைக்கவும். நீங்களே உருவாக்கிய மதிப்பை நீங்கள் எழுதி வைத்து மீட்டெடுக்க முடியும். n8n இந்த விசையால் தனது முதல் நற்சான்றிதழை மறையாக்கம் செய்தவுடன், இதை மாற்றினால் எல்லா நற்சான்றிதழ்களும் மீட்க முடியாதவை ஆகிவிடும் — எனவே இதை இப்போது ஒருமுறை அமைத்துவிட்டு, அந்த வரியை மீண்டும் ஒருபோதும் தொட வேண்டாம்.

webhook கள் செயல்படுகின்றனவா என்பதைத் தீர்மானிக்கும் env vars

நான்கு மாறிகள் n8n தன்னை வெளிப்புறத்திற்கு எவ்வாறு அடையாளப்படுத்துகிறது என்பதைக் கட்டுப்படுத்துகின்றன. இவற்றைத் தவறாக அமைப்பதுதான் n8n-க்கான முதல் எண் ஆதரவுக் கேள்வி.

  • N8N_HOST என்பது பொது hostname ஆகும், n8n.example.com. ஒரு proxy-க்குப் பின்னால் இதை இயல்புநிலை மதிப்பான localhost-ல் விட்டுவிட்டால், editor தனது சொந்த API-ஐ உங்கள் உலாவியில் localhost-லிருந்து ஏற்ற முயற்சிக்கிறது, இது தோல்வியடைகிறது.
  • 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 இந்த மதிப்புகளிலிருந்து உருவாக்கி, நீங்கள் Stripe, GitHub அல்லது எந்த ஒரு வெளிப்புற அழைப்பாளரிடமும் ஒட்டும் webhook முகவரிகளை அச்சிடுகிறது. இது அமைக்கப்படாவிட்டால் அல்லது தவறாக இருந்தால், n8n N8N_HOST:N8N_PORT-க்குத் திரும்புகிறது மற்றும் உங்களுக்கு https://n8n.example.com:5678/webhook/... அல்லது மோசமாக http://localhost:5678/webhook/...-ஐத் தருகிறது — பிழையின்றி அச்சிடப்பட்டு, நம்பகமானது போல் தோன்றும், ஆனால் இணையத்திலிருந்து அணுக முடியாதது, எனவே அழைப்பாளரின் கோரிக்கைகள் மௌனமாக வந்து சேருவதே இல்லை. இதை முடிவில் slash உடைய சரியான பொது base URL-ல் அமைக்கவும், பிறகு webhook node port இல்லாத ஒரு URL-ஐக் காட்டுகிறதா என உறுதி செய்யவும்.

N8N_PROXY_HOPS=1 என்பது n8n-இன் Express server-ஐ அதற்கு முன் ஒரு proxy-ஐ நம்பும்படி கூறுகிறது. எனவே rate-limiting மற்றும் client IP-ஐ வாசிக்கும் எந்த அம்சமும் proxy-இன் முகவரிக்கு பதிலாக உண்மையான முகவரியைப் பார்க்கிறது. இங்கே நீங்கள் வெளிப்படையாக அமைக்கக் கூடாது ஒரு மாறி N8N_RUNNERS_ENABLED ஆகும்: task runners — n8n Code-node logic-ஐ ஒரு தனிப்பட்ட sandboxed process-ல் இயக்குவது — 1.69 முதல் இயல்புநிலையாக உள்ளது மற்றும் இந்த வழிகாட்டி பொருத்தும் 2.x வரிசையிலிருந்து கட்டாயமானது, எனவே பழைய opt-in நீக்கப்பட்டது. இப்போது அதை அமைத்தால் n8n அதை நீக்கும்படி உங்களுக்கு ஒரு அறிவிப்பை log செய்கிறது.

முதல் தொடக்கம்

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

ஒரு சிறந்த முதல் தொடக்கம் Editor is now accessible via: வரியுடன் முடிகிறது, அதற்கு மேலே n8n ready on ..., port 5678 வரி இருக்கும். docker compose ps இரண்டு container-களையும் Up எனக் காட்ட வேண்டும், postgres ஆனது (healthy) எனக் குறிக்கப்பட்டிருக்க வேண்டும். n8n ஆனது Restarting சுழற்சியில் இருந்தால், log-களைப் படிக்கவும் — இது பெரும்பாலும் கீழே விளக்கப்பட்டுள்ள database இணைப்பு அல்லது volume அனுமதிகள் சிக்கலாகத்தான் இருக்கும்.

ரிவர்ஸ் ப்ராக்ஸி மூலம் TLS

n8n தனித்த 5678 போர்ட்டில் சாதாரண HTTP பயன்படுத்துகிறது. அதற்கு முன்னால் உள்ள ஒரு அமைப்பு HTTPS இணைப்பை முடிக்கிறது. இதற்கு இரண்டு சரியான வழிகள் உள்ளன.

நீங்கள் ஏற்கனவே பல கன்டெய்னர்களை இயக்கினால், n8n-ஐ TLS சான்றிதழ்களை தானாகவே வழங்கும் ஒரு Traefik ரிவர்ஸ் ப்ராக்ஸி பின்னால் சில லேபிள்களுடன் இணைக்கவும். Traefik உங்களுக்காக சான்றிதழை கோரி புதுப்பிக்கும்.

இது அந்த சர்வரில் உள்ள ஒரே ஆப்பாக இருந்தால், Let's Encrypt சான்றிதழுடன் கூடிய ஒரு nginx விர்ச்சுவல் ஹோஸ்ட் எளிதானது. சான்றிதழைப் பெற Ubuntu 24.04-கான Certbot மற்றும் nginx TLS அமைப்பைப் பயன்படுத்தவும். பிறகு இந்த சர்வர் பிளாக்கைப் பயன்படுத்தவும்:

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" தலைப்புகள் விருப்பப்பட்டவை அல்ல. n8n எடிட்டருக்கு WebSocket வழியாக நேரடி செயல்பாட்டு புதுப்பிப்புகளை அனுப்புகிறது. அந்த இரண்டு வரிகள் இல்லாவிட்டால், உள்நுழைவு பக்கம் ஏற்றப்பட்டு, பின்னர் இணைப்பு துண்டிக்கப்பட்டது என்ற செய்தியுடன் நிறுத்திவிடும். proxy_read_timeout 3600 நீண்ட நேரம் இயங்கும் செயல்பாடுகள் nginx-ன் இயல்புநிலையான 60 விநாடிகளில் துண்டிக்கப்படுவதைத் தடுக்கிறது. X-Forwarded-Proto $scheme தலைப்பு N8N_PROXY_HOPS=1-க்கு இணையானது: ப்ராக்ஸி n8n-ஐ சாதாரண HTTP வழியாக அணுகினாலும், அசல் கோரிக்கை HTTPS ஆக இருந்ததை n8n-க்கு இது தெரிவிக்கிறது. எனவே n8n இணைப்பு பாதுகாப்பற்றது என முடிவு செய்து அதன் சொந்த குக்கீயை நிராகரிப்பதில்லை.

உங்கள் முதல் வேலைப்பாய்வு, அதை நடைமுறையில் செய்ய

https://n8n.example.com/ ஐத் திறக்கவும். உரிமையாளர் கணக்கை உருவாக்கவும் (அடுத்த பிரிவு). பாதை சரியாக இயங்குகிறது என்பதை நிரூபிக்கும் மிகச் சிறிய வேலைப்பாய்வை உருவாக்கவும்: ஒரு webhook உள்ளீடு, ஒரு HTTP அழைப்பு, ஒரு பதில் வெளியீடு.

  1. ஒரு Webhook முனையைச் சேர்க்கவும். முறையை POST எனவும் பாதையை hello எனவும் அமைக்கவும். இது இரண்டு URLகளைக் காட்டுகிறது: ஒரு Test URL மற்றும் ஒரு Production URL. இவைதாம் "எனது webhook வேலை செய்யவில்லை" என்ற புகார்களில் பாதிக்குக் காரணம். Test URL ஒரே ஒரு அழைப்புக்கு மட்டுமே பதிலளிக்கும். அதுவும் நீங்கள் Listen for test event என்பதைச் சொடுக்கிய பிறகே பதிலளிக்கும்; பின்னர் அது காலாவதியாகும். Production URL வேலைப்பாய்வு Active நிலையில் இருக்கும்போது எப்போது வேண்டுமானாலும் பதிலளிக்கும்.
  2. அதற்குப் பிறகு ஒரு HTTP Request முனையைச் சேர்க்கவும். ஏதேனும் பொது JSON APIயை நோக்கி அமைக்கவும் — https://api.github.com/zen க்கு ஒரு GET அழைப்பு ஒரு வரி சரத்தைத் திருப்பித் தரும். இது போதுமானது.
  3. ஒரு Respond to Webhook முனையைச் சேர்க்கவும். Webhook முனையின் Respond விருப்பத்தை "Using Respond to Webhook node" என அமைக்கவும். இதனால் அழைப்பவருக்கு HTTP முனையின் வெளியீடு திரும்பும்.
  4. வேலைப்பாய்வை Active ஆக மாற்றவும் (மேல் வலது). பிறகு அதை அழைக்கவும்: curl -X POST https://n8n.example.com/webhook/hello. நீங்கள் அந்த zen வரியைத் திரும்பப் பெறுவீர்கள் — POST உள்ளீடு, API அழைப்பு, பதில் வெளியீடு. இதுதான் பெரும்பாலான உண்மையான தானியக்கங்களின் அமைப்பு.

ஒரு திட்டமிடப்பட்ட மாறுபாட்டில், Webhook முனையை Schedule Trigger ஆக மாற்றலாம். அதற்கு பதிலாக ஒரு மாதிரி endpoint ஐ அழைக்கலாம் — அதே VPS இல் இயங்கும் Ollama போன்ற சுய-ஹோஸ்ட் செய்யப்பட்ட ஒன்று, தினசரி சுருக்கம் தயாரிக்கும் கருவியை உருவாக்க ஒரு சுத்தமான வழியாகும்.

அடிப்படை அங்கீகாரம் அல்ல, பயனர் மேலாண்மை

பழைய n8n வழிகாட்டிகள் N8N_BASIC_AUTH_ACTIVE=true ஐ அமைக்கச் சொல்லும். அந்த மாறிகள் n8n 1.0 இல் நீக்கப்பட்டன. இப்போது அவற்றால் எந்தவிதத்திலும் ஒன்றும் நிகழ்வதில்லை. இன்றைய அங்கீகாரம் உரிமையாளர் கணக்கு ஆகும்: நீங்கள் முதன்முதலில் எடிட்டரை ஏற்றும்போது, n8n உங்களை ஒரு மின்னஞ்சல் மற்றும் கடவுச்சொல் கொண்ட உரிமையாளரை உருவாக்கச் செய்கிறது. அந்தச் சோதனை கட்டாயமானது — அநாமதேய பயன்முறை எதுவும் இல்லை. யாருக்கும் URL ஐ கொடுப்பதற்கு முன்பாக, முதல் துவக்கத்திற்குப் பின் உடனடியாக அதை உருவாக்குங்கள்: docker compose up க்கும் அந்த முதல் படிவச் சமர்ப்பிப்பிற்கும் இடையில், யார் முதலில் இன்ஸ்டன்ஸை அடைகிறாரோ அவர் அதை உரிமை கொண்டாடலாம். அதற்கு மேலாக ஒரு ரிவர்ஸ்-ப்ராக்ஸி basic-auth அடுக்கு ஒரு நியாயமான கூடுதல் பூட்டு. ஆனால் அது இரண்டாவது காரணி, உண்மையான அங்கீகாரம் அல்ல.

காப்புப்பிரதிகள்: முதலில் மறைகுறியாக்க விசை, பின்னர் தரவுத்தளம்

இரண்டு பொருட்களுக்கு காப்புப்பிரதி தேவை. அவை இரண்டும் சமமாக மாற்றக்கூடியவை அல்ல.

N8N_ENCRYPTION_KEY. n8n இல் நீங்கள் சேமிக்கும் ஒவ்வொரு நற்சான்றிதழும் — API tokens, தரவுத்தள கடவுச்சொற்கள், OAuth secrets — இந்த விசையால் ஓய்வில் மறைகுறியாக்கப்படுகிறது. Postgres இல் உள்ள workflows இதற்கு இல்லாவிட்டால் பயனற்றவை: வேறொரு விசையுடன் புதிய சேவையகத்தில் தரவுத்தளத்தை மீட்டெடுத்தால் n8n ஒரே ஒரு நற்சான்றிதழைக் கூட மறைநீக்கம் செய்ய முடியாது; மீட்பதற்கோ மீட்டமைப்பதற்கோ வழியில்லை. உங்கள் .env கோப்பு இந்த விசையைக் கொண்டுள்ளது; அதை சேவையகத்திற்கு வெளியே எங்காவது நகலெடுத்து வைக்கவும் — கடவுச்சொல் மேலாளர் உள்ளீடு சிறந்தது — நீங்கள் அதை உருவாக்கிய அன்றே. உண்மையில் முக்கியமானது இந்தக் காப்புப்பிரதிதான்.

Postgres தரவுத்தளம், workflows, செயல்பாட்டு வரலாறு மற்றும் மறைகுறியாக்கப்பட்ட நற்சான்றிதழ்களுக்காக:

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

இதை ஒரு கால அட்டவணையில் இயக்கவும். dump கோப்பை சேவையகத்திற்கு வெளியே நகலெடுக்கவும். புதிய VPS இல் மீட்டெடுக்க: தரவுத்தளம் உருவாகும் வரை stack ஐ ஒருமுறை இயக்கவும், n8n ஐ நிறுத்தவும், dump ஐ psql உடன் மீண்டும் ஏற்றவும், அதே N8N_ENCRYPTION_KEY ஐ .env இல் வைக்கவும், பின்னர் n8n ஐ தொடங்கவும். அதே விசையுடன் dump என்பது செயல்படும் நிகழ்வு; புதிய விசை என்பது ஒரே ஒரு நற்சான்றிதழைக் கூட பயன்படுத்த முடியாத workflows ஆகும்.

மேம்படுத்தல்கள்: குறியீட்டைப் பொருத்தவும்

compose கோப்பு வேண்டுதலாக latest-க்குப் பதிலாக n8nio/n8n:2.29.10-ஐப் பொருத்துகிறது. n8n பெரும்பாலான வாரங்களில் ஒரு புதிய சிறுபதிப்பை வெளியிடுகிறது. இவற்றுக்கிடையே அவ்வப்போது தரவுத்தள அமைப்பு அல்லது முனை நடத்தை மாறுகிறது. எனவே latest என்பது கண்காணிப்பின்றி நிகழும் ஒரு pull உங்கள் தரவுத்தளத்தைத் தொடங்கியவுடனேயே இடம்பெயர்க்கும் ஒரு கட்டமைப்பைத் தரலாம் என்று பொருள். ஒரு பதிப்பைப் பொருத்துங்கள். மேம்படுத்துவதற்கு முன் வெளியீட்டுக் குறிப்புகளை படியுங்கள் — n8n அங்கே உடைக்கும் மாற்றங்களைக் குறிப்பிடுகிறது — பின்னர் வெளிப்படையாக மேம்படுத்துங்கள்:

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

பெரும்பதிப்பு தாவல்களில் இது மிகவும் முக்கியம். உதாரணமாக, 2.0 தொடர் இயல்பாக N8N_BLOCK_ENV_ACCESS_IN_NODE-ஐ true-ஆக மாற்றியது. எனவே process.env-ஐ வாசிக்கும் எந்த Code node-ம் நீங்கள் அதை false-ஆக மீண்டும் அமைக்கும் வரை அமைதியாக அணுகலை இழக்கிறது. அதே வெளியீடு அமைப்புகள் கோப்பில் கடுமையான அனுமதிகளைச் செயல்படுத்தத் தொடங்கியது. ஒரு பெரும்பதிப்பு எல்லையைக் கடப்பதற்கு முன் 2.0 உடைக்கும் மாற்றங்கள் பக்கத்தை படியுங்கள். n8n தொடங்கும்போது தேவையான தரவுத்தள இடம்பெயர்ப்புகளைத் தானாக இயக்குகிறது — இதுதான் மேம்படுத்தலுக்கு முந்தைய pg_dump கட்டாயம் என்று காரணம். சான்றாணைகள் .env-இல் உள்ள ஒரு திறவுகோலால் மறையாக்கப்பட்டு தரவு Postgres-இல் இருப்பதால், கொள்கலன்கள் நீக்கக்கூடியவை: நீங்கள் அவற்றை மாற்றியதன் மூலம் மேம்படுத்துகிறீர்கள், முந்தைய குறியீட்டைப் பொருத்தி டம்ப்பை மீட்டெடுப்பதன் மூலம் பின்செல்கிறீர்கள்.

பிழை நிலைகள், நீங்கள் காணும் சரங்களுடன்

The requested webhook "POST hello" is not registered. செயலில் இல்லாத ஒரு workflow-ஐ அழைக்கும்போது கிடைக்கும் 404, அல்லது யாரும் கவனிக்காத போது test path-ஐ அழைக்கும்போது கிடைக்கும் 404. Test path-கள் (/webhook-test/...) நீங்கள் "Listen for test event" என்பதைச் சொடுக்கருள்ள போது மட்டுமே பதிலளிக்கும்; production path-கள் (/webhook/...) workflow toggle இயக்கத்தில் இருக்கும்போது மட்டுமே பதிலளிக்கும். சகோதர 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-ஐ மீண்டும் உருவாக்கவும், போர்ட் மறைந்துவிடும்.

உலாவியில் There was a problem loading init data. editor ஏற்றப்பட்டது ஆனால் அதன் சொந்த backend API-ஐ அடைய முடியவில்லை. proxy ஒன்றுக்குப் பின்னால் இருந்தால், இது பெரும்பாலும் தவறான N8N_HOST அல்லது WEBHOOK_URL, WebSocket Upgrade headers இல்லாத proxy, அல்லது நீங்கள் இணையும் விதத்துடன் பொருந்தாத N8N_PROTOCOL ஆகும். நான்கு public-facing variables மற்றும் proxy Upgrade மற்றும் Connection-ஐ அனுப்புகிறது என்பதை உறுதிப்படுத்தவும்.

பதிவுகளில் password authentication failed for user "n8n", container மறுதொடக்கம் செய்யப்படுவதுடன். n8n அனுப்பும் கடவுச்சொல் database தொடங்கப்பட்டதில் உள்ளதற்கு ஒத்திருப்பதில்லை. சிக்கல்: Postgres POSTGRES_PASSWORD-ஐ வெறுமையான data directory-ஐத் தொடங்கும்போது மட்டுமே வாசிக்கிறது. stack-ஐ ஒருமுறை தொடங்கவும், பின்னர் .env-ல் POSTGRES_PASSWORD-ஐ மாற்றவும், ஏற்கனவே உள்ள postgres_data volume பழைய கடவுச்சொல்லைத் தக்கவைத்திருக்கும். அதை மூல நிலைக்கு அமைக்கவும், அல்லது தக்கவைக்க தரவு இல்லையென்றால், docker compose down மற்றும் docker volume rm postgres volume-ஐ, பின்னர் அதைப் புதிதாகத் தொடங்கவும்.

தொடக்கத்தில் EACCES: permission denied, open '/home/node/.n8n/config'. n8n ஆனது node பயனர் (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-ஐ இயல்பாகச் செயல்படுத்துகிறது, மேலும் தொடக்கத்தில் அதைத் தானே சரிசெய்கிறது — இந்த பதிவு வரி அது ஏற்கனவே முறையைச் சரிசெய்துவிட்டது என்று பொருள், பொதுவாக ஒரு bind mount-க்குப் பிறகு அல்லது ஒரு restore தளர்வான அனுமதிகளுடன் file-ஐ மீண்டும் நகலெடுத்த பிறகு. எந்தச் செயலும் தேவையில்லை; உங்கள் filesystem உண்மையில் அனுமதிகளை ஆதரிக்க முடியாதபோது மட்டுமே N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false-ஐ அமைக்கவும்.

Mismatching encryption keys — முழுமையான வரி settings file-ல் உள்ள encryption key /home/node/.n8n/config உங்கள் சூழலில் உள்ள N8N_ENCRYPTION_KEY-உடன் பொருந்தவில்லை என்கிறது. உங்கள் சூழலில் உள்ள key ஆனது n8n முந்தைய இயக்கத்தில் அதன் data volume-ல் எழுதியதிலிருந்து வேறுபடுகிறது — பெரும்பாலும் மாறி அமைக்கப்படாதபோது n8n முந்தைய தொடக்கத்தில் ஒரு சீரற்ற key-ஐ உருவாக்கியதால், நீங்கள் பின்னர் வேறொன்றை அமைத்தீர்கள். மூல key-ஐ .env-ல் மீண்டும் வைக்கவும், அல்லது தக்கவைக்க மதிப்புள்ள சேமித்த credentials உங்களிடம் இல்லையென்றால் மட்டும், n8n_data volume-ல் உள்ள config file-ஐ நீக்கி n8n அதை மீண்டும் உருவாக்க அனுமதிக்கவும் — ஏற்கனவே உள்ள credentials படிக்க முடியாதவை ஆகும் என்பதை ஏற்றுக்கொள்ளுங்கள்.

பாதுகாப்பான cookies பற்றிய ஒரு உள்நுழைவு 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-ஐ வெற்றை HTTP மூலம் அடைந்தீர்கள் — பொதுவாக HTTPS proxy-க்குப் பதிலாக IP மற்றும் port-ஐ நேரடியாகப் பயன்படுத்துவதால். அதை https://n8n.example.com/ வழியாக அடையவும். நீங்கள் உண்மையில் HTTPS பயன்படுத்த முடியாதபோது மட்டுமே N8N_SECURE_COOKIE=false-ஐ அமைக்கவும், மேலும் internet-உடன் இணைக்கப்பட்ட பெட்டியில் ஒருபோதும் அமைக்க வேண்டாம்.

அந்த workflows-ல் ஒரு language model-ஐ வைக்க, Claude மற்றும் n8n உடன் AI workflows உருவாக்குதல் பார்க்கவும்.

FAQ

n8n-க்கு SQLite அல்லது Postgres பயன்படுத்த வேண்டுமா?

SQLite (இயல்புநிலை) n8n-ஐ சோதிப்பதற்கும் ஒரே நேரத்தில் ஒரு workflow-ஐ இயக்கும் தனிப்பட்ட instance-க்கும் போதுமானது. நீங்கள் சார்ந்திருக்கும் எதற்கும் Postgres-க்கு மாறவும்: ஒரே நேரத்தில் பல செயல்கள் நிகழும்போது SQLite-ன் single writer lock database is locked-ஐ ஏற்படுத்துகிறது, மேலும் Postgres pg_dump உடன் சரியாக backup செய்யப்படுகிறது. பின்னர் migrate செய்வது கைமுறையானது, எனவே இந்த அமைப்பு முக்கியமானால், Postgres-லேயே தொடங்கவும்.

என் n8n webhooks ஏன் ஒருபோதும் இயங்குவதில்லை?

கிட்டத்தட்ட எப்போதும் WEBHOOK_URL காரணமாகும். அமைக்கப்படாவிட்டால் அல்லது தவறாக இருந்தால், n8n webhook முகவரிகளை N8N_HOST:N8N_PORT-லிருந்து உருவாக்குகிறது — பெரும்பாலும் அவற்றில் :5678 அல்லது localhost இருக்கும் — அவை சரியானதாகத் தெரிந்தாலும் இணையத்திலிருந்து அணுக முடியாதவை, எனவே caller-ன் கோரிக்கைகள் ஒருபோதும் வருவதில்லை. WEBHOOK_URL=https://n8n.example.com/-ஐ அமைத்து, node போர்ட் இல்லாத ஒரு URL-ஐக் காட்டுகிறதா என்பதை உறுதிப்படுத்திக்கொள்ளவும். இரண்டாவது காரணம், Active நிலையில் toggle செய்யப்படாத workflow-ன் webhook-ஐ அழைப்பதாகும், இது The requested webhook ... is not registered.-ஐ திருப்பியனுப்புகிறது

n8n-ல் நான் எதை backup செய்ய வேண்டும்?

இரண்டு பொருட்கள். உங்கள் .env கோப்பிலிருந்து N8N_ENCRYPTION_KEY, ஏனெனில் சேமிக்கப்பட்ட ஒவ்வொரு credential-ம் அதனால் encrypt செய்யப்பட்டுள்ளது, அதை இழந்தால் அவை நிரந்தரமாக decrypt செய்ய முடியாதவையாகிவிடும் — அதை உருவாக்கிய நாளிலேயே server-லிருந்து நகலெடுத்து வைக்கவும். மேலும் workflows, history மற்றும் credentials-க்கான Postgres தரவுத்தளத்தின் pg_dump. restore செய்ய இரண்டும் தேவை: அதே key மற்றும் dump.

n8n-ஐ HTTPS-க்குப் பின்னால் எவ்வாறு வைப்பது?

n8n போர்ட் 5678-ல் plain HTTP-ஐ வழங்குகிறது; முன்னால் உள்ள reverse proxy TLS-ஐ முடிக்கிறது. n8n-ஐ 127.0.0.1:5678-க்கு bind செய்யவும், இதனால் proxy மட்டுமே அதை அணுக முடியும், பிறகு தானியங்கி சான்றிதழ்களுடன் Traefik அல்லது Let's Encrypt சான்றிதழுடன் nginx பயன்படுத்தவும். N8N_PROTOCOL=https மற்றும் WEBHOOK_URL=https://your-host/-ஐ அமைக்கவும், மேலும் proxy WebSocket Upgrade headers-ஐ forward செய்கிறதா என்பதை உறுதிப்படுத்தவும், இல்லையெனில் editor இயங்குவதை நிறுத்திவிடும்.

n8n-ஐ பாதுகாப்பாக எவ்வாறு upgrade செய்வது?

latest-க்குப் பதிலாக ஒரு குறிப்பிட்ட image tag-ஐ pin செய்யவும், n8n தொடங்கும்போது migrations-ஐ தானாக இயக்குவதால் முதலில் pg_dump எடுக்கவும், முறிவான மாற்றங்களுக்கான release notes-ஐ படிக்கவும், பிறகு tag-ஐ உயர்த்தி docker compose pull n8n && docker compose up -d n8n-ஐ இயக்கவும். container நீக்கக்கூடியது, எனவே முந்தைய tag-ஐ pin செய்து upgrade-க்கு முந்தைய dump-ஐ restore செய்வதன் மூலம் roll back செய்யவும்.

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