VPS-ல் Docker பயன்படுத்தி n8n-ஐ நிறுவுவது எப்படி?

நீங்கள் உருவாக்குவது என்ன

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

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

முன்நிபந்தனைகள் மற்றும் நடைமுறை எல்லைகள்

குறைந்தது 1 GB RAM கொண்ட VPS தேவை. Workflows உண்மையான பணிகளைச் செய்யத் தொடங்கியதும் 2 GB RAM-க்கு திட்டமிடவும். Executions மற்றும் Node.js runtime ஆகியவை memory-ஐ பயன்படுத்தும். Execution நடுவில் out-of-memory killer container-ஐ நிறுத்துவது, இதை அறிய மிகவும் மோசமான வழியாகும்.

தொடக்கத்திற்கு ஒரு vCPU போதுமானது. இந்த box-ல் அதிக resource தேவைப்படும் வேறு service-ஐயும் இயக்கப் போகிறீர்கள் என்றால், முதலில் அந்த service-க்குத் தேவையான அளவை அடிப்படையாகக் கொண்டு VPS-ஐத் தேர்ந்தெடுக்கவும். பொதுவாக photo library அதிக resource தேவைப்படும். PhotoPrism மற்றும் Immich-க்கான உண்மையான RAM தேவைகள் n8n கேட்கும் அளவைவிட மிகவும் அதிகமாக இருக்கும்.

Media box-க்கும் இதே விதி பொருந்தும். Jellyfin server மற்றும் அதற்கான browsable front end ஆகியவை, 90s rental shop போல library-ஐ மீண்டும் உருவாக்கும் Halcyon போன்றவை, n8n கவனிப்பதற்கும் முன்பே RAM மற்றும் transcoding headroom-ஐ பயன்படுத்திவிடும்.

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

சோதனைக்கு SQLite சிறந்தது, ஆனால் நம்பகமான பயன்பாட்டிற்கு Postgres அவசியம்

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

DNS மற்றும் firewall

முதலில் DNS record-ஐ point செய்து, தேவையான ports-ஐத் திறக்கவும். அப்போதுதான், பெயர் resolve ஆகாத காரணத்தால் பிற்காலத்தில் certificate உருவாக்கும் செயல்முறை தோல்வியடையாது.

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 port-ஐத் திறக்க வேண்டாம். compose file-ல் n8n ஆனது 127.0.0.1:5678-உடன் பிணைக்கப்பட்டுள்ளதால் (bind), host-ன் reverse proxy-ஆல் மட்டுமே அதை அணுக முடியும். ஒரு ufw allow 5678-ஐச் சேர்ப்பது அந்தத் தனிமைப்படுத்தலை (isolation) நீக்கிவிடும்.

Compose கோப்பு

ஒரு பணி அடைவை (working directory) உருவாக்கி, அதில் ஒரு 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 பகிரப்பட்ட network-ல் கண்டறியும். இது localhost அல்ல; ஏனெனில் n8n container-க்குள் localhost என்பது n8n-ஐயே குறிக்கும். condition: service_healthy உடன் கூடிய depends_on, boot-ன் போது n8n-க்கு முன்பே Postgres தொடங்குவதை உறுதி செய்கிறது; இது இல்லையெனில், n8n தொடங்கும் போது database-ஐக் கண்டறிய முடியாமல் வெளியேறிவிடும். /home/node/.n8n-ல் உள்ள n8n_data என்ற named volume, encryption key மற்றும் SQLite-ன் database-ஐச் சேமித்து வைக்கிறது; இது நீங்கள் இழக்கக்கூடாத ஒரே அடைவு ஆகும். image-ஐ ஒரு குறிப்பிட்ட version-க்கு மட்டும் pin செய்யவும், ஒருபோதும் latest-ஐப் பயன்படுத்த வேண்டாம்; இதற்கான காரணங்கள் கீழே உள்ள upgrade பகுதியில் விளக்கப்பட்டுள்ளன.

Secrets கோப்பு

கடவுச்சொற்களை ஒருபோதும் compose கோப்பில் வைக்க வேண்டாம். அதற்குப் பதிலாக, அதை ஒரு .env கோப்பில் வைத்து, Compose தானாகவே வாசிக்கும்படி அமைக்கவும். மேலும், அவை உண்மையாகவே சீரற்றதாக (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). சேமிக்கப்படும் ஒவ்வொரு நற்சான்றிதழும் (credential) இந்த சாவியைக் கொண்டே குறியாக்கப்படுகிறது (encrypted). n8n தானாகவே ஒன்றை உருவாக்குவதற்குப் பதிலாக, நீங்களே ஒரு மதிப்பைத் தெளிவாக அமைக்கவும்; ஏனெனில் நீங்கள் உருவாக்கும் மதிப்பை எழுதி வைத்துக்கொண்டு, தேவைப்படும்போது மீட்டெடுக்க முடியும். n8n தனது முதல் நற்சான்றிதழை இந்தச் சாவியைக் கொண்டு குறியாக்கம் செய்த பிறகு, இதை மாற்றினால் எந்தவொரு நற்சான்றிதழையும் மீண்டும் மறைகுறியாக்கம் (decrypt) செய்ய முடியாது. எனவே, இதை இப்போதே ஒருமுறை சரியாக அமைத்துவிட்டு, மீண்டும் அந்த வரியைத் தொடாதீர்கள்.

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

n8n தன்னை வெளி உலகிற்கு எவ்வாறு அடையாளப்படுத்துகிறது என்பதை நான்கு மாறிகள் (variables) தீர்மானிக்கின்றன. இவற்றைத் தவறாக அமைப்பதுதான் n8n ஆதரவுப் பிரிவில் கேட்கப்படும் முதன்மையான கேள்வியாகும்.

• N8N_HOST என்பது பொதுவான hostname ஆகும், இது n8n.example.com. ஒரு proxy-க்கு பின்னால் இருக்கும்போது இதை இயல்புநிலையான localhost-லேயே விட்டால், உங்கள் browser-ல் உள்ள n8n editor, அதன் சொந்த API-ஐ localhost-லிருந்து ஏற்ற முயற்சிக்கும், இது தோல்வியடையும்.
• N8N_PROTOCOL=https, n8n ஒரு TLS வழியாக வழங்கப்படுகிறது என்பதை அதற்கு உணர்த்துகிறது. எனவே, இது session cookie-ஐ Secure என அடையாளப்படுத்தி, https:// URL-களை உருவாக்குகிறது.
• N8N_PORT=5678 என்பது container-க்குள் n8n இயங்கும் port ஆகும். இது பொதுவான port அல்ல; 443 port-ஐ proxy மட்டுமே கையாளும்.
• WEBHOOK_URL=https://n8n.example.com/ என்பது சிக்கலை ஏற்படுத்தும் காரணியாகும். Stripe, GitHub அல்லது பிற வெளிப்புற சேவைகளில் நீங்கள் பதிவிடும் webhook முகவரிகளை, இந்த மதிப்புகளைக் கொண்டு n8n உருவாக்குகிறது. இது அமைக்கப்படாவிட்டாலோ அல்லது தவறாக இருந்தாலோ, n8n இயல்புநிலையான N8N_HOST:N8N_PORT-க்குத் திரும்பி, உங்களுக்கு https://n8n.example.com:5678/webhook/... அல்லது மோசமான நிலையில் http://localhost:5678/webhook/...-ஐ வழங்கும். இது எந்தப் பிழையும் காட்டாமல், பார்ப்பதற்குச் சரியாகத் தெரிந்தாலும், இணையத்திலிருந்து அணுக முடியாததாக இருக்கும். இதனால், வெளிப்புற அழைப்புகள் (requests) n8n-க்கு வந்து சேராது. இதைச் சரியான பொது base URL மற்றும் இறுதியில் ஒரு slash குறியுடன் அமைக்கவும். பின்னர், webhook node-ல் port இல்லாத URL காட்டப்படுகிறதா என்பதை உறுதிப்படுத்தவும்.

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

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

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 சுழற்சியில் (loop) சிக்கிக்கொண்டால், logs-ஐப் பார்க்கவும்; பெரும்பாலும் இது database இணைப்பு அல்லது கீழே விவரிக்கப்பட்டுள்ள volume அனுமதிகள் (permissions) தொடர்பான சிக்கலாகவே இருக்கும்.

Reverse proxy மூலம் TLS

n8n ஆனது 5678 port-ல் plain HTTP-ஐ மட்டுமே கையாளும்; எனவே, HTTPS-ஐ முடிவுக்குக் கொண்டுவர (terminate) அதற்கு முன்னால் ஒரு கருவி தேவை. இதற்கு இரண்டு எளிய வழிகள் உள்ளன.

நீங்கள் ஏற்கனவே பல containers-ஐ இயக்குபவர் என்றால், தானாகவே TLS certificates-ஐ வழங்கும் Traefik reverse proxy-க்கு பின்னால் n8n-ஐ வைக்கவும். சில labels-ஐ மட்டும் சேர்த்தால் போதும், Traefik உங்களுக்காக certificate-ஐ பெற்று, புதுப்பித்துக்கொள்ளும்.

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

உங்கள் முதல் workflow, அதைச் செயல்படுத்தும் முறை

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

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

திட்டமிடப்பட்ட (scheduled) மாறுபாட்டில், Webhook node-க்கு பதிலாக Schedule Trigger-ஐப் பயன்படுத்தலாம். அதற்குப் பதிலாக ஒரு model endpoint-ஐ அழைக்கலாம். ஒரே VPS-ல் இயங்கும் Ollama-விலிருந்து சுய-ஹோஸ்ட் செய்யப்பட்ட (self-hosted) model-ஐப் பயன்படுத்துவது, இரவு நேரச் சுருக்கங்களை (nightly summariser) உருவாக்க ஒரு நேர்த்தியான வழியாகும்.

User management, basic auth அல்ல

பழைய n8n வழிகாட்டிகள் N8N_BASIC_AUTH_ACTIVE=true அமைக்குமாறு கூறுகின்றன. அந்த variables n8n 1.0-ல் நீக்கப்பட்டுவிட்டன; இப்போது அவை எந்தச் செயலையும் செய்யாது. தற்போது authentication என்பது owner account அடிப்படையிலானது: editor-ஐ முதன்முறையாக load செய்யும்போது, n8n உங்களிடம் email-and-password owner account உருவாக்கச் செய்யும். அந்த gate கட்டாயமானது; anonymous mode இல்லை. முதல் boot முடிந்தவுடன், URL-ஐ யாரிடமும் பகிர்வதற்கு முன் இதை உடனடியாக உருவாக்கவும்: docker compose up மற்றும் அந்த முதல் form submission இடையிலான நேரத்தில், instance-ஐ முதலில் அணுகும் எவரும் claim செய்யலாம். இதற்கு மேல் reverse-proxy basic-auth layer அமைப்பது கூடுதல் பாதுகாப்பாக நியாயமானது. ஆனால் அது second factor மட்டுமே; உண்மையான authentication அதுவல்ல. Owner account மற்றும் இந்த வழிகாட்டியில் உள்ள பிற அனைத்தும் free community edition-ல் இயங்கும். பின்னர் granular roles கொண்ட கூடுதல் users அல்லது SSO தேவைப்பட்டால், அவற்றை அடிப்படையாகக் கொண்டு திட்டமிடுவதற்கு முன் எந்த n8n features-க்கு paid licence தேவை என்பதைப் படிப்பது பயனுள்ளதாக இருக்கும்.

Backups: குறியாக்க விசை (encryption key) முதலில், அதன் பிறகு தரவுத்தளம் (database)

இரண்டு விஷயங்களை காப்புப்பிரதி (backup) எடுக்க வேண்டும், இவை இரண்டிற்கும் சமமான முக்கியத்துவம் இல்லை.

N8N_ENCRYPTION_KEY. n8n-ல் நீங்கள் சேமிக்கும் ஒவ்வொரு நற்சான்றிதழ் (credential), API tokens, தரவுத்தள கடவுச்சொற்கள், OAuth secrets ஆகிய அனைத்தும் இந்த விசையைக் கொண்டு குறியாக்கம் (encrypt) செய்யப்படுகின்றன. இந்த விசை இல்லாமல் Postgres-ல் உள்ள workflows பயனற்றவை: வேறொரு விசையுடன் புதிய server-ல் தரவுத்தளத்தை மீட்டெடுத்தால், n8n-ஆல் எந்தவொரு நற்சான்றிதழையும் மறைகுறியாக்கம் (decrypt) செய்ய முடியாது; இதை மீட்டெடுக்கவோ அல்லது மாற்றியமைக்கவோ வழியில்லை. உங்கள் .env கோப்புதான் இந்த விசையை வைத்திருக்கிறது; அதை உருவாக்கிய அன்றே server-க்கு வெளியே எங்காவது நகலெடுத்துக் கொள்ளுங்கள், password-manager-ல் சேமிப்பது சிறந்தது. இதுவே மிக முக்கியமான காப்புப்பிரதி ஆகும்.

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

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

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

மேம்படுத்தல்கள்: tag-ஐ pin செய்தல்

Compose கோப்பில் latest-க்கு பதிலாக n8nio/n8n:2.29.10-ஐ pin செய்வது வேண்டுமென்றே செய்யப்படுகிறது. n8n வாரந்தோறும் புதிய minor பதிப்புகளை வெளியிடுகிறது. சில சமயங்களில் அவற்றுக்கிடையே database schema அல்லது node செயல்பாடுகளில் மாற்றங்கள் இருக்கும். எனவே latest என்று இருந்தால், unattended pull மூலம் உங்கள் database-ஐ உடனடியாக மாற்றியமைக்கும் ஒரு build-ஐ நீங்கள் பெற நேரிடும். ஒரு குறிப்பிட்ட பதிப்பை pin செய்யவும், பதிப்பை உயர்த்துவதற்கு முன் release notes-ஐப் படிக்கவும். n8n அதில் ஏற்படும் முக்கிய மாற்றங்களை (breaking changes) குறிப்பிடுகிறது, எனவே கவனமாக மேம்படுத்தவும்:

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 மாற்றங்களின் போது இது மிக முக்கியமானது. உதாரணமாக, 2.0 வரிசையில், இயல்பாகவே N8N_BLOCK_ENV_ACCESS_IN_NODE என்பது true என மாற்றப்பட்டது. இதனால், process.env-ஐப் படித்த எந்தவொரு Code node-ம், நீங்கள் அதை மீண்டும் false என மாற்றும் வரை அணுகலை இழக்கும். அதே வெளியீட்டில் settings கோப்பிற்கான கடுமையான அனுமதிகள் (strict permissions) அமல்படுத்தப்பட்டன. ஒரு major பதிப்பிற்கு மாறுவதற்கு முன் 2.0 breaking-changes பக்கத்தை படிக்கவும். n8n தொடங்கும் போது தேவையான database மாற்றங்களை தானாகவே செய்கிறது, அதனால்தான் மேம்படுத்தலுக்கு முந்தைய pg_dump கட்டாயமானது. Credentials அனைத்தும் .env-ல் உள்ள ஒரு key மூலம் குறியாக்கம் (encrypted) செய்யப்பட்டு, தரவுகள் Postgres-ல் சேமிக்கப்படுவதால், containers-ஐ எளிதாக நீக்கலாம்: நீங்கள் அவற்றை மாற்றுவதன் மூலம் மேம்படுத்தலாம், அல்லது முந்தைய tag-ஐ pin செய்து dump-ஐ restore செய்வதன் மூலம் பழைய நிலைக்குத் திரும்பலாம்.

தோல்விக்கான காரணங்கள் மற்றும் நீங்கள் காணும் செய்திகள்

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

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

Logs-ல் 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 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 வரி, அது ஏற்கனவே mode-ஐச் சரிசெய்துவிட்டது என்பதைக் குறிக்கிறது. இது பொதுவாக bind mount செய்த பிறகு அல்லது restore செய்த பிறகு கோப்பு தளர்வான அனுமதிகளுடன் (loose permissions) நகலெடுக்கப்பட்டால் நிகழும். எந்த நடவடிக்கையும் தேவையில்லை; உங்கள் filesystem அனுமதிகளை ஆதரிக்கவில்லை என்றால் மட்டுமே N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false-ஐ அமைக்கவும்.

Mismatching encryption keys, முழுமையான வரி என்னவென்றால், settings file /home/node/.n8n/config-ல் உள்ள encryption key, உங்கள் environment-ல் உள்ள N8N_ENCRYPTION_KEY-உடன் பொருந்தவில்லை. உங்கள் environment-ல் உள்ள key, முந்தைய இயக்கத்தின்போது n8n அதன் data volume-ல் எழுதிய key-யிலிருந்து வேறுபடுகிறது. பெரும்பாலும், variable அமைக்கப்படாதபோது n8n ஒரு random 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-ஐ அமைத்துள்ளீர்கள், ஆனால் HTTPS proxy-க்கு பதிலாக IP மற்றும் port-ஐ நேரடியாகப் பயன்படுத்தி plain HTTP மூலம் n8n-ஐ அணுகியுள்ளீர்கள். https://n8n.example.com/ வழியாக அணுகவும். HTTPS-ஐப் பயன்படுத்தவே முடியாது என்ற சூழலில் மட்டுமே N8N_SECURE_COOKIE=false-ஐ அமைக்கவும், இணையத்தில் நேரடியாகத் தெரியும் எந்தவொரு பெட்டியிலும் இதைச் செய்ய வேண்டாம்.

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

FAQ

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

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

எனது n8n webhooks ஏன் வேலை செய்யவில்லை?

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

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

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

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

n8n ஆனது port 5678-ல் plain HTTP-ஐ வழங்குகிறது; இதற்கு முன்னால் உள்ள ஒரு reverse proxy, TLS termination-ஐச் செய்யும். n8n-ஐ 127.0.0.1:5678-ல் bind செய்யவும், அப்போதுதான் proxy-ஆல் அதை அணுக முடியும். பிறகு, தானியங்கி 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-ஐப் பயன்படுத்தவும். n8n தொடங்கும்போதே தானாகவே migrations-ஐச் செய்வதால், முதலில் ஒரு pg_dump எடுத்துக்கொள்ளவும். மாற்றங்கள் குறித்த release notes-ஐப் படித்துவிட்டு, tag-ஐ மாற்றி docker compose pull n8n && docker compose up -d n8n-ஐ இயக்கவும். container-ஐ எளிதாக நீக்க முடியும் என்பதால், முந்தைய tag-ஐ மீண்டும் pin செய்து, upgrade-க்கு முந்தைய dump-ஐ restore செய்வதன் மூலம் பழைய நிலைக்குத் திரும்பலாம்.