VPS پر n8n Docker Compose کے ساتھ کیسے لگائیں

آپ کیا بنا رہے ہیں

n8n ایک ورک فلو آٹومیشن ٹول ہے: ایک بصری ایڈیٹر جہاں ایک ٹرگر — ایک ویب ہوک، ایک شیڈول، ایک فارم جمع کرانا — نوڈز کی ایک زنجیر کو چلاتا ہے جو APIs کو کال کرتے ہیں، ڈیٹا کو نئی شکل دیتے ہیں اور دیگر سسٹمز میں لکھتے ہیں۔ یہ AI-ایجنٹ ورک فلو کے لیے پہلے سے طے شدہ کنیکٹر بن گیا ہے کیونکہ یہ ہر ماڈل فراہم کنندہ اور ڈیٹا بیس سے بات کرتا ہے بغیر آپ کے کوئی سروس لکھے۔ ایک docker run دو منٹ میں ایک کام کرنے والا ایڈیٹر حاصل کر لیتا ہے۔ یہ رہنمائی باقی ننانوے فیصد کے بارے میں ہے: اسے پہلے سے طے شدہ SQLite فائل کے بجائے Postgres کے ساتھ پائیدار بنانا، HTTPS پر قابل رسائی بنانا، اور — وہ حصہ جسے تقریباً ہر کوئی غلط کرتا ہے — ویب ہوکس کو ایک ایسا URL دینا جس تک باہری دنیا واقعی پہنچ سکے۔

مکمل اسٹیک ایک Docker نیٹ ورک پر دو کنٹینرز پر مشتمل ہے: n8n خود، اور ایک Postgres ڈیٹا بیس جو اس کے ورک فلو اور اسناد کو محفوظ رکھتا ہے۔ ہوسٹ پر ایک ریورس پراکسی TLS کو ختم کرتی ہے اور n8n کو localhost پر فارورڈ کرتی ہے، لہٰذا انٹرنیٹ کی طرف کچھ بھی اس پراکسی کے ذریعے سوا سامنے نہیں آتا۔ یہ 2026 سیلف ہوسٹنگ شارٹ لسٹ پر دیگر سروسز کے ساتھ موجود ہے۔

پیش نیازات، اور حقیقی حدود

آپ کو کم از کم 1 GB RAM والے VPS کی ضرورت ہے۔ جب ورک فلوز حقیقی کام کرنے لگیں تو 2 GB کا بندوبست کریں۔ وجہ یہ ہے کہ ایگزیکیوشنز اور Node.js رن ٹائم میموری استعمال کرتے ہیں، اور اگر کنٹینر چلتے وقت آؤٹ آف میموری کلر اسے بند کر دے تو یہ جاننا تکلیف دہ ہوتا ہے۔ شروعات کے لیے ایک vCPU کافی ہے۔

آپ کو ایک ڈومین یا سب ڈومین کی ضرورت ہے — مثلاً n8n.example.com — جس میں A ریکارڈ VPS کے پبلک IP کی طرف اشارہ کرتا ہو اور یہ سرٹیفکیٹ کی درخواست سے پہلے ریزولو ہو جائے۔ پورٹس 80 اور 443 پراکسی کے لیے کھلے ہونے چاہئیں۔ n8n کی اپنی پورٹ 5678 انٹرنیٹ پر باز نہیں ہونی چاہیے۔ آپ کو Docker Engine اور Compose پلگ ان درکار ہے۔ اگر docker compose version میں docker: 'compose' is not a docker command کی خرابی آئے تو اس کا مطلب ہے کہ آپ کے پاس پرانا اسٹینڈ ایلون بائنری ہے، اور پلگ ان sudo apt install docker-compose-plugin ہے۔

SQLite ٹیسٹ کے لیے ٹھیک ہے، Postgres کسی بھی قابلِ انحصار کام کے لیے

n8n کا ڈیفالٹ ڈیٹا بیس /home/node/.n8n/database.sqlite پر ایک SQLite فائل ہے۔ آزمائش کے لیے یہ ٹھیک ہے — کوئی والیوم منٹ نہ کریں اور پہلی ہی کنٹینر ری کریٹ پر یہ ڈیٹا ضائع ہو جائے گا، جو کہ خود ایک سبق ہے۔ Postgres کی طرف منتقل ہونے کی وجہ خام رفتار نہیں ہے۔ وجہ یہ ہے کہ SQLite ایک وقت میں صرف ایک رائٹر لاک رکھتا ہے۔ لہٰذا ایک ساتھ کئی ورک فلو چلانے والا انسٹنس، یا قطع (queue) موڈ جس کی آپ کو بالآخر ضرورت ہوگی، بھیڑ کی صورت میں SQLITE_BUSY: database is locked کا سامنا کرتا ہے۔ Postgres میں اس کی کوئی حد نہیں ہے۔ یہ pg_dump کے ساتھ صاف ستھرا بیک اپ ہوتا ہے۔ n8n کی اپنی دستاویزات بھی کسی قابلِ انحصار سرور کے لیے اسی کو فرض کرتی ہیں۔ بعد میں تبدیل کرنے کا مطلب ہے ڈیٹا کو دستی طور پر منتقل کرنا۔ لہٰذا اگر یہ سسٹم اہم ہے تو شروع سے ہی 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 سے باندھتی ہے تاکہ صرف ہوسٹ کا ریورس پراکسی اس تک پہنچ سکے، اور ایک 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 شروع ہوتا ہے، کوئی ڈیٹا بیس نہیں پاتا، اور باہر نکل جاتا ہے۔ نامزد والیوم n8n_data جو /home/node/.n8n پر ہے، وہ انکرپشن کلید اور 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 اپنی پہلی اسناد کو اس کلید سے خفیہ کر لے، اسے تبدیل کرنا ہر اسناد کو ڈکرپٹ ناقابل بناتا ہے — لہٰذا اسے اب ایک بار سیٹ کریں، اور اس لائن کو دوبارہ کبھی نہ چھیڑیں۔

وہ env vars جو فیصلہ کرتے ہیں کہ webhooks کام کریں گے یا نہیں

چار متغیرات کنٹرول کرتے ہیں کہ n8n خود کو بیرونی دنیا میں کیسے پیش کرتا ہے، اور انہیں غلط ترتیب دینا n8n کا سب سے بڑا معاونتی سوال ہے۔

• N8N_HOST public hostname ہے، n8n.example.com۔ اسے proxy کے پیچھے default localhost پر چھوڑیں اور editor اپنے API کو آپ کے browser میں localhost سے لوڈ کرنے کی کوشش کرتا ہے، جو ناکام ہوتا ہے۔
• N8N_PROTOCOL=https n8n کو بتاتا ہے کہ یہ TLS پر serve کیا جا رہا ہے، اس لیے یہ اپنے session cookie کو Secure سے نشان زد کرتا ہے اور https:// URLs بناتا ہے۔
• N8N_PORT=5678 وہ port ہے جس پر n8n container کے اندر listen کرتا ہے۔ یہ public port نہیں ہے؛ proxy 443 کا مالک ہے۔
• WEBHOOK_URL=https://n8n.example.com/ وہ ہے جو نقصان پہنچاتا ہے۔ n8n ان webhook addresses کو ان متغیرات سے بنا کر print کرتا ہے جو آپ Stripe، GitHub یا کسی بھی بیرونی caller میں paste کرتے ہیں۔ اگر یہ unset یا غلط ہو، تو n8n N8N_HOST:N8N_PORT پر fallback کرتا ہے اور آپ کو https://n8n.example.com:5678/webhook/... دیتا ہے یا بدتر، http://localhost:5678/webhook/... — بغیر کسی error کے print ہوتا ہے، حقیقت کے قریب لگتا ہے، اور internet سے unreachable ہے، اس لیے caller کی requests خاموشی سے کبھی نہیں پہنچتیں۔ اسے trailing slash کے ساتھ exact public base URL پر set کریں، پھر confirm کریں کہ webhook node ایک ایسا URL دکھاتا ہے جس میں کوئی port نہ ہو۔

N8N_PROXY_HOPS=1 n8n کے Express server کو اپنے سامنے موجود ایک proxy پر بھروسہ کرنے کے لیے کہتا ہے، تاکہ rate-limiting اور client IP پڑھنے والی کوئی بھی feature proxy کے address کے بجائے حقیقی address دیکھے۔ ایک متغیر جسے آپ یہاں جان بوجھ کر set نہیں کرتے وہ N8N_RUNNERS_ENABLED ہے: task runners — n8n کا Code-node logic کو ایک الگ sandboxed process میں چلانا — 1.69 سے default رہے ہیں اور اس 2.x line سے لازمی ہیں جسے یہ guide pin کرتی ہے، اس لیے پرانا opt-in deprecated ہو چکا ہے۔ اسے ابھی set کریں تو n8n صرف ایک notice log کرتا ہے جو آپ کو اسے remove کرنے کے لیے کہتا ہے۔

پہلی شروع

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 میں دونوں کنٹینرز Up نظر آنے چاہئیں، جن میں postgres کو (healthy) کے طور پر نشان زد ہونا چاہیے۔ اگر n8n ایک Restarting لوپ میں پھنس جائے، تو لاگز پڑھیں — یہ تقریباً ہمیشہ نیچے بیان کردہ ڈیٹابیس کنکشن یا والیوم پرمیشنز کا مسئلہ ہوتا ہے۔

TLS کے ساتھ ریورس پراکسی

n8n خود 5678 پر سادہ HTTP بولتا ہے۔ اس کے سامنے موجود کوئی چیز HTTPS کو ختم کرتی ہے۔ دو صاف انتخاب ہیں۔

اگر آپ پہلے ہی کئی کنٹینرز چلا رہے ہیں، تو n8n کو ایک Traefik ریورس پراکسی کے پیچھے رکھیں جو TLS سرٹیفکیٹس خودکار جاری کرتا ہے چند لیبلز کے ساتھ۔ 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 کو بتاتا ہے کہ اصل درخواست HTTPS تھی حالانکہ پراکسی اس تک سادہ HTTP کے ذریعے پہنچتی ہے، اس لیے n8n یہ فیصلہ نہیں کرتا کہ کنکشن غیر محفوظ ہے اور اپنی کوکی کو مسترد نہیں کرتا۔

آپ کا پہلا ورک فلو، اسے حقیقی بنانے کے لیے

https://n8n.example.com/ کھولیں، مالک اکاؤنٹ بنائیں (اگلا سیکشن)، اور سب سے چھوٹا ورک فلو بنائیں جو یہ ثابت کرے کہ راستہ کام کرتا ہے: ایک ویب ہوک اندر، ایک HTTP کال، ایک ردعمل باہر۔

1. ایک Webhook نوڈ شامل کریں۔ طریقہ POST پر سیٹ کریں اور پاتھ hello جیسا دیں۔ یہ دو URL دکھاتا ہے، ایک Test URL اور ایک Production URL — یہ آدھے "میرا ویب ہوک کام نہیں کرتا" رپورٹس کا ذریعہ ہے۔ 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 لیتا ہے اور ماڈل اینڈ پوائنٹ کو کال کرتا ہے — اسی VPS پر چلنے والا Ollama سے ایک سیلف ہوسٹڈ ورژن ایک راتوں رات سمری بنانے والے کی بنانے کا صاف طریقہ ہے۔

صارف کا انتظام، بنیادی تصدیق نہیں

پرانی n8n رہنمائیاں آپ کو N8N_BASIC_AUTH_ACTIVE=true مقرر کرنے کہتی ہیں۔ یہ متغیرات n8n 1.0 میں ہٹا دیے گئے اور اب یہ کچھ نہیں کرتے۔ آج کی تصدیق مالک اکاؤنٹ ہے: جب آپ پہلی بار ایڈیٹر لوڈ کرتے ہیں، n8n آپ سے ایک ای میل اور پاس ورڈ والا مالک بنوانے پر مجبور کرتا ہے۔ یہ دروازہ لازمی ہے — کوئی گمنام موڈ موجود نہیں۔ اسے پہلے بوٹ کے فوراً بعد بنائیں، کسی کو URL دینے سے پہلے: docker compose up اور پہلی فارم جمع کرانے کے درمیان، جو شخص سب سے پہلے پہنچ جائے وہ اس مثال کو اپنے نام کر سکتا ہے۔ اس کے اوپر ایک ریورس پراکسی بنیادی تصدیق کی تہہ ایک معقول اضافی قفل ہے، لیکن یہ دوسرا عنصر ہے، حقیقی تصدیق نہیں۔

بیک اپ: پہلے انکرپشن کلید، پھر ڈیٹا بیس

دو چیزیں بیک اپ کرنے کی ضرورت ہیں، اور یہ دونوں یکساں طور پر بدلنے کے قابل نہیں ہیں۔

N8N_ENCRYPTION_KEY۔ n8n میں محفوظ کردہ ہر اسناد — API tokens، ڈیٹا بیس پاس ورڈز، OAuth secrets — اس کلید سے انکرپٹڈ حالت میں رکھی جاتی ہے۔ Postgres میں موجود ورک فلو بغیر اس کے بے کار ہیں: ڈیٹا بیس کو کسی نئے سرور پر مختلف کلید کے ساتھ بحال کریں تو n8n ایک بھی اسناد کو ڈکرپٹ نہیں کر سکتا، نہ اس کی کوئی ریکوری ہے اور نہ ری سیٹ۔ آپ کی .env فائل میں یہ کلید موجود ہوتی ہے؛ اسے سرور سے باہر کسی جگہ کاپی کر لیں — پاس ورڈ مینیجر کا اندراج بہترین ہے — جس دن آپ اسے بنائیں۔ یہ وہ بیک اپ ہے جو واقعی اہمیت رکھتا ہے۔

Postgres ڈیٹا بیس، ورک فلو، ایگزیکیوشن ہسٹری اور انکرپٹڈ اسناد کے لیے:

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

اسے شیڈول پر چلائیں اور ڈمپ کو سرور سے باہر کاپی کر لیں۔ کسی نئے VPS پر بحال کرنے کے لیے: اسٹیک کو ایک بار اپ کر لیں تاکہ ڈیٹا بیس وجود میں آ جائے، n8n کو روکیں، ڈمپ کو psql کے ساتھ واپس لوڈ کریں، وہی N8N_ENCRYPTION_KEY کو .env میں ڈالیں، اور n8n شروع کریں۔ وہی کلید اور ڈمپ مل کر ایک کام کرنے والا انسٹنس بنتا ہے؛ نئی کلید کا مطلب ایسے ورک فلو ہیں جو ایک بھی اسناد استعمال نہیں کر سکتے۔

اپ گریڈز: ٹیگ کو مقفل رکھیں

compose فائل جان بوجھ کر latest کے بجائے n8nio/n8n:2.29.10 کو مقفل کرتی ہے۔ n8n ہر ہفتے تقریباً ایک نیا مائنر ورژن جاری کرتا ہے اور کبھی کبھی ان کے درمیان ڈیٹا بیس اسکیمیا یا نوڈ رویے میں تبدیلی لاتا ہے، لہٰذا latest کا مطلب ہے کہ بغیر نگرانی کی گئی پل آپ کو ایسا بلڈ دے سکتی ہے جو شروع ہوتے ہی آپ کے ڈیٹا بیس کو مائگریٹ کر دے۔ ایک ورژن مقفل کریں، ورژن بڑھانے سے پہلے ریلیز نوٹس پڑھیں — 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 میں تبدیل کر دیا، لہٰذا کوئی بھی Code نوڈ جو process.env پڑھتا تھا وہ خاموشی سے رسائی کھو بیٹھتا ہے جب تک آپ اسے واپس false پر نہ سیٹ کریں؛ اسی ریلیز نے سیٹنگز فائل پر سخت پرمیشنز نافذ کرنا شروع کر دیں۔ میجر سرحد عبور کرنے سے پہلے 2.0 بریکنگ تبدیلیوں کا صفحہ پڑھیں۔ n8n شروع ہونے پر کوئی بھی ضروری ڈیٹا بیس مائگریشنز خود بخود چلاتا ہے — اسی وجہ سے اپ گریڈ سے پہلے کا pg_dump لازمی ہے۔ چونکہ کریڈینشلز .env میں موجود کلید کے ساتھ انکرپٹڈ رہتے ہیں اور ڈیٹا Postgres میں رہتا ہے، لہٰذا کنٹینرز ڈسپوزایبل ہیں: آپ انہیں تبدیل کر کے اپ گریڈ کرتے ہیں، اور پچھلا ٹیگ مقفل کر کے اور ڈمپ بحال کر کے رول بیک کرتے ہیں۔

ناکامی کے طریقے، جن میں آپ کو نظر آنے والے متن شامل ہیں

The requested webhook "POST hello" is not registered. ایک غیر فعال ورک فلو کے ویب ہوک کو کال کرنے پر 404، یا جب کوئی نہیں سن رہا ہو تو ٹیسٹ پاتھ کو کال کرنے پر۔ ٹیسٹ پاتھ (/webhook-test/...) صرف اس وقت جواب دیتے ہیں جب آپ "Listen for test event" پر کلک کر چکے ہوں؛ پروڈکشن پاتھ (/webhook/...) صرف اس وقت جواب دیتے ہیں جب ورک فلو ٹوگل آن ہو۔ ہم مرتبہ This webhook is not registered for GET requests. Did you mean to make a POST request? کا مطلب ہے کہ طریقہ غلط ہے — نوڈ POST کی توقع کر رہا ہے اور آپ نے GET بھیجا۔

ویب ہوک URL میں :5678 یا localhost نظر آتا ہے۔ نوڈ https://n8n.example.com:5678/webhook/... یا http://localhost:5678/... دکھاتا ہے۔ WEBHOOK_URL سیٹ نہیں ہے یا غلط ہے، اس لیے n8n نے پتہ آپ کی عوامی بیس کے بجائے N8N_HOST:N8N_PORT سے بنایا۔ WEBHOOK_URL=https://n8n.example.com/ سیٹ کریں، کنٹینر کو docker compose up -d سے دوبارہ بنائیں، اور پورٹ غائب ہو جائے گی۔

براؤزر میں There was a problem loading init data۔ ایڈیٹر لوڈ ہو گیا لیکن اپنے بیک اینڈ API تک نہیں پہنچ سکتا۔ پراکسی کے پیچھے یہ تقریباً ہمیشہ ایک غلط N8N_HOST یا WEBHOOK_URL، WebSocket Upgrade ہیڈرز کی کمی والی پراکسی، یا N8N_PROTOCOL کا آپ کے کنیکٹ کرنے کے طریقے سے نہ ملنے کی وجہ سے ہوتا ہے۔ چار عوامی متغیرات کی تصدیق کریں اور یہ کہ پراکسی Upgrade اور Connection کو فارورڈ کرتی ہے۔

لاگز میں password authentication failed for user "n8n"، کنٹینر کو دوبارہ شروع کرنے کے ساتھ۔ پاس ورڈ جو n8n بھیجتا ہے وہ ڈیٹا بیس کے ساتھ شروع کیے گئے پاس ورڈ سے میل نہیں کھاتا۔ دھوکے کی بات: Postgres POSTGRES_PASSWORD کو صرف اس وقت پڑھتا ہے جب یہ ایک خالی ڈیٹا ڈائریکٹری کو شروع کرتا ہے۔ اسٹیک کو ایک بار شروع کریں، پھر POSTGRES_PASSWORD کو .env میں تبدیل کریں، اور موجودہ postgres_data والیوم اب بھی پرانا پاس ورڈ رکھتی ہے۔ اسے اصل میں واپس سیٹ کریں، یا، اگر آپ کے پاس رکھنے کے لیے کوئی ڈیٹا نہیں ہے، تو docker compose down اور docker volume rm postgres والیوم، پھر اسے تازہ شروع کریں۔

شروع ہونے پر EACCES: permission denied, open '/home/node/.n8n/config'۔ n8n node یوزر (UID 1000) کے طور پر چلتا ہے اور اپنی کنفیگ ڈائریکٹری میں نہیں لکھ سکتا۔ یہ ان لوگوں کو تکلیف دیتا ہے جو root کی ملکیت والی ہوسٹ فولڈر (./n8n_data:/home/node/.n8n) کو بائنڈ ماؤنٹ کرتے ہیں۔ اوپر دکھائی گئی نامزد والیوم کا استعمال کریں، یا اگر آپ بائنڈ ماؤنٹ پر اصرار کرتے ہیں، تو پہلے 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 بطور ڈیفالٹ اس سیٹنگز فائل پر 0600 کو نافذ کرتا ہے اور اسے بوٹ پر خود درست کرتا ہے — یہ لاگ لائن اس کا مطلب ہے کہ اس نے پہلے ہی موڈ کو درست کر دیا ہے، عام طور پر بائنڈ ماؤنٹ کے بعد یا اس کے بعد جب ری سٹور نے فائل کو ڈھیلی اجازت کے ساتھ واپس کاپی کیا۔ کوئی کارروائی کی ضرورت نہیں ہے؛ N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false کو صرف اس وقت سیٹ کریں جب آپ کی فائل سسٹم واقعی اجازتوں کی حمایت نہیں کر سکتی۔

Mismatching encryption keys — مکمل لائن کہتی ہے کہ سیٹنگز فائل میں انکرپشن کلید /home/node/.n8n/config آپ کے ماحول میں N8N_ENCRYPTION_KEY سے میل نہیں کھاتی۔ آپ کے ماحول میں کلید اس کلید سے مختلف ہے جو n8n نے پچھلی بار اپنی ڈیٹا والیوم میں لکھی تھی — اکثر اس لیے کیونکہ n8n نے پچھلی بوٹ پر متغیر سیٹ نہ ہونے کی صورت میں ایک بے ترتیب کلید بنائی تھی، اور پھر آپ نے ایک مختلف کلید سیٹ کی۔ اصل کلید کو .env میں واپس رکھیں، یا، صرف اس صورت میں جب آپ کے پاس واقعی رکھنے کے قابل کوئی محفوظ کردہ اسناد نہ ہوں، تو n8n_data والیوم کے اندر config فائل کو حذف کریں اور n8n کو اسے دوبارہ بنانے دیں — اس شرط کے ساتھ کہ موجودہ اسناد پڑھنے کے قابل نہیں رہیں گی۔

محفوظ کوکیز کے بارے میں لاگن بینر: 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 پراکسی کے بجائے براہ راست IP اور پورٹ تک رسائی حاصل کرنے کی وجہ سے۔ اس تک https://n8n.example.com/ کے ذریعے پہنچیں۔ صرف اس صورت میں جب آپ واقعی HTTPS کا استعمال نہیں کر سکتے تو آپ کو N8N_SECURE_COOKIE=false سیٹ کرنا چاہیے، اور انٹرنیٹ سے جڑے باکس پر کبھی نہیں۔

ان ورک فلو میں ایک لینگویج ماڈل کو شامل کرنے کے لیے، Claude اور n8n کے ساتھ AI ورک فلو بنانا دیکھیں۔

FAQ

n8n کے لیے SQLite استعمال کروں یا Postgres؟

SQLite (ڈیفالٹ) n8n کو آزمانے اور ایک وقت میں ایک ورک فلو چلانے والے ذاتی انسٹنس کے لیے ٹھیک ہے۔ کسی بھی ایسی چیز کے لیے جس پر آپ انحصار کرتے ہیں، Postgres کی طرف منتقل ہوں: SQLite کا سنگل رائٹر لاک کنکرنسی کے تحت database is locked کو ناکام بناتا ہے، اور Postgres pg_dump کے ساتھ صاف طریقے سے بیک اپ ہوتا ہے۔ بعد میں منتقلی دستی ہوتی ہے، اس لیے اگر باکس اہم ہے تو Postgres پر شروع کریں۔

میرے n8n ویب ہوکس کیوں کبھی فائر نہیں ہوتے؟

تقریباً ہمیشہ WEBHOOK_URL کی وجہ سے۔ سیٹ نہ ہونے یا غلط ہونے پر، n8n N8N_HOST:N8N_PORT سے بنائے گئے ویب ہوک ایڈریسز پرنٹ کرتا ہے — اکثر ان میں :5678 یا localhost ہوتا ہے — جو درست لگتے ہیں لیکن انٹرنیٹ سے ناقابل رسائی ہیں، اس لیے کالر کی درخواستیں کبھی نہیں پہنچتیں۔ WEBHOOK_URL=https://n8n.example.com/ سیٹ کریں اور تصدیق کریں کہ نوڈ پر بغیر پورٹ کے URL نظر آئے۔ دوسری وجہ ایک ایسے ویب ہوک کو کال کرنا ہے جس کا ورک فلو Active پر ٹوگل نہیں ہے، جو The requested webhook ... is not registered. واپس کرتا ہے۔

n8n میں کیا بیک اپ لینا ضروری ہے؟

دو چیزیں۔ آپ کی .env فائل سے N8N_ENCRYPTION_KEY، کیونکہ ہر محفوظ کردہ اسناد اس کے ساتھ انکرپٹڈ ہے اور اسے کھو دینے سے وہ مستقل طور پر ڈکرپٹ نہیں ہو سکتیں — اسے سرور سے بنانے کے دن ہی کاپی کر لیں۔ اور ورک فلو، ہسٹری اور اسناد کے لیے Postgres ڈیٹا بیس کا pg_dump۔ بحال کرنے کے لیے دونوں درکار ہیں: وہی کلید اور ڈمپ۔

n8n کو HTTPS کے پیچھے کیسے رکھوں؟

n8n پورٹ 5678 پر سادہ HTTP پیش کرتا ہے؛ سامنے ایک ریورس پراکسی TLS ختم کرتی ہے۔ n8n کو 127.0.0.1:5678 سے بائنڈ کریں تاکہ صرف پراکسی اس تک پہنچ سکے، پھر خودکار سرٹیفکیٹس کے ساتھ Traefik استعمال کریں یا Let's Encrypt سرٹیفکیٹ کے ساتھ nginx۔ N8N_PROTOCOL=https اور WEBHOOK_URL=https://your-host/ سیٹ کریں، اور یقینی بنائیں کہ پراکسی WebSocket Upgrade ہیڈرز فارورڈ کرے ورنہ ایڈیٹر ہینگ ہو جاتا ہے۔

n8n کو محفوظ طریقے سے کیسے اپ گریڈ کروں؟

latest کے بجائے ایک مخصوص امیج ٹیگ پن کریں، پہلے pg_dump لیں کیونکہ n8ن شروع ہونے پر مائگریشنز خودکار چلاتا ہے، بریکنگ تبدیلیوں کے لیے ریلیز نوٹس پڑھیں، پھر ٹیگ بڑھائیں اور docker compose pull n8n && docker compose up -d n8n چلائیں۔ کنٹینر ڈسپوزایبل ہے، اس لیے پچھلا ٹیگ پن کرنے اور اپ گریڈ سے پہلے کا ڈمپ بحال کرنے سے رول بیک کریں۔