VPS پر n8n خود host کریں: Docker اور HTTPS

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

n8n ایک workflow automation tool ہے: ایک visual editor جس میں trigger، webhook، schedule یا form submission، nodes کی ایسی chain چلاتا ہے جو APIs کو call کرتی ہے، data کی شکل تبدیل کرتی ہے اور اسے دوسرے systems میں لکھتی ہے۔ n8n AI-agent workflows کے لیے default glue بن چکا ہے، کیونکہ یہ service لکھے بغیر ہر model provider اور database سے رابطہ کر لیتا ہے۔ ایک docker run سے دو منٹ میں working editor تیار ہو جاتا ہے۔ یہ guide باقی 90 فیصد حصے کے بارے میں ہے: default SQLite file کے بجائے Postgres کے ساتھ اسے durable بنانا، HTTPS کے ذریعے قابلِ رسائی بنانا، اور وہ حصہ جس میں تقریباً ہر شخص غلطی کرتا ہے، webhooks کو ایسا URL دینا جس تک بیرونی دنیا واقعی پہنچ سکے۔

مکمل stack ایک ہی Docker network پر دو containers پر مشتمل ہے: خود n8n، اور Postgres database جس میں اس کے workflows اور credentials محفوظ ہوتے ہیں۔ host پر موجود reverse proxy TLS termination کرتا ہے اور n8n کو localhost پر requests forward کرتا ہے، اس لیے proxy کے علاوہ کوئی چیز internet کے سامنے نہیں رہتی۔ یہ دیگر services کے ساتھ 2026 کی self-hosting مختصر فہرست میں شامل ہے۔

ضروریات اور عملی حدود

آپ کو کم از کم 1 GB RAM والا VPS درکار ہے۔ جب workflows حقیقی کام انجام دینے لگیں تو 2 GB کے لیے منصوبہ بندی کریں، کیونکہ executions اور Node.js runtime مل کر کافی memory استعمال کرتے ہیں، اور run کے دوران container کو out-of-memory killer کا ختم کر دینا یہ جاننے کا انتہائی ناخوشگوار طریقہ ہے کہ memory کم ہے۔ ابتدا کے لیے ایک vCPU کافی ہے۔

اگر یہ machine کوئی زیادہ resource-intensive سروس بھی چلائے گی تو sizing پہلے اسی سروس کے مطابق کریں۔ عموماً photo library سب سے بڑی وجہ بنتی ہے، اور PhotoPrism اور Immich کے لیے درکار حقیقی RAM کی کم از کم مقدار n8n کی ضرورت سے کہیں زیادہ ہوتی ہے۔

Media box کے لیے بھی یہی اصول ہے۔ Jellyfin server کے ساتھ اس کے لیے کوئی browsable front end، مثلاً Halcyon، جو library کو 90s کی rental shop کی صورت میں دوبارہ بناتا ہے، RAM اور transcoding headroom n8n کے محسوس کرنے سے بہت پہلے استعمال کر لے گا۔

آپ کے پاس ایک domain یا subdomain ہونا چاہیے، مثلاً n8n.example.com، اور اس کا A record VPS کے public IP کی طرف اشارہ کرتا ہو۔ Certificate طلب کرنے سے پہلے اس record کا resolve ہونا ضروری ہے۔ Ports 80 اور 443 proxy کے لیے کھلے ہونے چاہییں؛ n8n کا اپنا port 5678 internet پر دستیاب نہیں ہونا چاہیے۔ آپ کو Docker Engine اور Compose plugin کی ضرورت ہے۔ اگر docker compose version، docker: 'compose' is not a docker command کے ساتھ error دے تو آپ کے پاس پرانا standalone binary موجود ہے، جبکہ plugin sudo apt install docker-compose-plugin ہے۔

ٹیسٹ کے لیے SQLite کافی ہے، لیکن جس چیز پر آپ انحصار کرتے ہوں اس کے لیے Postgres استعمال کریں

n8n کا ڈیفالٹ database /home/node/.n8n/database.sqlite پر موجود SQLite فائل ہے۔ ابتدائی آزمائش کے لیے یہ کافی ہے۔ کوئی volume mount نہ کریں تو پہلے container کو دوبارہ بناتے ہی database ضائع ہو جائے گا، اور یہ بھی ایک الگ سبق ہے۔ Postgres پر منتقل ہونے کی وجہ خام رفتار نہیں ہے؛ وجہ یہ ہے کہ SQLite میں ایک وقت میں صرف ایک writer lock ہوتا ہے۔ اس لیے ایک ہی instance میں بیک وقت کئی workflows چلانے پر، یا اس queue mode میں جس کی آپ کو آگے چل کر ضرورت پڑ سکتی ہے، concurrency کے دوران SQLITE_BUSY: database is locked ظاہر ہوتا ہے۔ Postgres میں یہ حد نہیں ہوتی، pg_dump کے ذریعے صاف طریقے سے backup لیا جا سکتا ہے، اور n8n کی اپنی documentation بھی ایسے server کے لیے Postgres فرض کرتی ہے جس پر آپ انحصار کرتے ہوں۔ بعد میں منتقل ہونے کے لیے data کو دستی طور پر migrate کرنا پڑتا ہے، اس لیے اگر یہ machine اہم ہے تو ابتدا ہی Postgres سے کریں۔

DNS اور firewall

پہلے DNS record کو درست IP کی طرف point کریں اور ports کھولیں، تاکہ بعد میں certificate کا مرحلہ ایسے نام کی وجہ سے ناکام نہ ہو جو resolve نہیں ہوتا۔

dig +short n8n.example.com
curl -s ifconfig.me
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw enable

5678 کو نہ کھولیں۔ Compose file n8n کو 127.0.0.1:5678 پر bind کرتی ہے، اس لیے صرف host کا reverse proxy اس تک پہنچ سکتا ہے، اور ufw allow 5678 اس isolation کو ختم کر دے گا۔

Compose فائل

ایک working directory بنائیں اور ایک docker-compose.yml تیار کریں۔ یہی مکمل stack ہے: دو services، ایک private network، اور دو named volumes۔

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - n8n_net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.29.10
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Europe/London
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - n8n_net
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres_data:
  n8n_data:

networks:
  n8n_net:

چند فیصلوں کی واضح وضاحت ضروری ہے۔ DB_POSTGRESDB_HOST=postgres service name ہے، جسے Docker مشترکہ network پر resolve کرتا ہے؛ یہ localhost نہیں ہے، کیونکہ n8n container کے اندر localhost سے مراد خود n8n ہوتا ہے۔ depends_on میں condition: service_healthy شامل ہونے سے boot کے وقت n8n، Postgres کے ساتھ race نہیں کرتا؛ اس کے بغیر n8n start ہوتا ہے، database نہیں ملتا، اور exit ہو جاتا ہے۔ n8n_data نامی volume، جو /home/node/.n8n پر mounted ہے، encryption key اور SQLite استعمال کرنے کی صورت میں database محفوظ رکھتا ہے۔ یہی وہ directory ہے جسے آپ کو ہرگز ضائع نہیں ہونے دینا چاہیے۔ image کو ہمیشہ exact version پر pin کریں، کبھی latest استعمال نہ کریں؛ اس کی وجوہات ذیل کے upgrade section میں بیان ہیں۔

رازوں کی فائل

Compose فائل میں passwords ہرگز شامل نہ کریں۔ انہیں اسی کے ساتھ موجود .env فائل میں رکھیں، جسے Compose خودکار طور پر پڑھتا ہے، اور انہیں اس طرح generate کریں کہ وہ واقعی 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 ہے۔ ہر stored credential اسی key سے encrypt ہوتا ہے۔ اسے خود واضح طور پر set کریں، n8n کو خود generate کرنے نہ دیں، کیونکہ آپ کی generate کی ہوئی value کو لکھ کر محفوظ اور بعد میں restore کیا جا سکتا ہے۔ n8n کے اس key سے اپنا پہلا credential encrypt کرنے کے بعد اسے تبدیل کرنے سے ہر credential decrypt نہیں ہو سکے گا۔ اس لیے اسے ابھی ایک بار set کریں اور اس line کو دوبارہ کبھی تبدیل نہ کریں۔

وہ environment variables جو طے کرتے ہیں کہ webhooks کام کریں گے یا نہیں

چار variables یہ طے کرتے ہیں کہ n8n بیرونی دنیا کے سامنے اپنی شناخت کیسے بیان کرتا ہے۔ انہیں غلط ترتیب دینا n8n سے متعلق support کے سوالات کی سب سے عام وجہ ہے۔

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

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

پہلی بار start

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 connection یا ذیل میں بیان کردہ volume permissions میں ہوتا ہے۔

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

n8n خود 5678 پر سادہ HTTP استعمال کرتا ہے؛ HTTPS کو کوئی سامنے موجود جزو terminate کرتا ہے۔ اس کے لیے دو سادہ طریقے ہیں۔

اگر آپ پہلے ہی کئی containers چلا رہے ہیں تو n8n کو ایسے Traefik reverse proxy کے پیچھے رکھیں جو TLS certificates خودکار طور پر جاری کرتا ہے اور اس کے لیے چند labels کافی ہوں گے۔ Traefik آپ کی طرف سے certificate طلب اور renew کر دے گا۔

اگر یہ server پر واحد ایپ ہے تو 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 کو WebSocket کے ذریعے editor تک بھیجتا ہے۔ ان دونوں lines کے بغیر login page لوڈ ہونے کے بعد رک جاتا ہے اور lost-connection banner دکھاتا ہے۔ proxy_read_timeout 3600 طویل وقت تک چلنے والی executions کو nginx کے default 60 seconds بعد بند ہونے سے روکتا ہے۔ X-Forwarded-Proto $scheme header، N8N_PROXY_HOPS=1 کا companion ہے۔ یہ n8n کو بتاتا ہے کہ اصل request HTTPS تھی، حالانکہ proxy اس تک plain HTTP کے ذریعے پہنچتی ہے۔ اس طرح n8n connection کو غیر محفوظ قرار دے کر اپنی cookie reject نہیں کرتا۔

آپ کا پہلا workflow، اسے حقیقت بنائیں

https://n8n.example.com/ کھولیں، owner account بنائیں (اگلا section)، اور سب سے چھوٹا workflow بنائیں جو یہ ثابت کرے کہ راستہ درست کام کر رہا ہے: webhook اندر آئے، HTTP call ہو، اور response باہر جائے۔

1. ایک Webhook node شامل کریں۔ method کو POST اور path کو hello جیسی قدر پر set کریں۔ یہ دو URLs دکھاتا ہے: ایک Test URL اور ایک Production URL۔ یہی ان رپورٹوں کی بنیادی وجہ ہے کہ "میرا webhook کام نہیں کر رہا"۔ Test URL صرف ایک call کا جواب دیتا ہے، اور وہ بھی اسی وقت جب آپ نے Listen for test event پر click کیا ہو؛ اس کے بعد یہ expire ہو جاتا ہے۔ Production URL اس وقت جواب دیتا ہے جب workflow Active ہو۔
2. اس کے بعد ایک HTTP Request node شامل کریں اور اسے کسی بھی public JSON API کی طرف point کریں۔ https://api.github.com/zen کو GET request کرنے سے one-line string واپس آتی ہے، جو اس مقصد کے لیے کافی ہے۔
3. ایک Respond to Webhook node شامل کریں، اور Webhook node کے Respond option کو "Using Respond to Webhook node" پر set کریں تاکہ caller کو HTTP node کا output واپس ملے۔
4. workflow کو اوپر دائیں جانب سے Active کریں اور اسے call کریں: curl -X POST https://n8n.example.com/webhook/hello۔ آپ کو zen line واپس ملنی چاہیے۔ POST اندر، API call، اور response باہر؛ زیادہ تر حقیقی automations کی ساخت یہی ہوتی ہے۔

scheduled variant میں Webhook node کی جگہ Schedule Trigger استعمال کیا جاتا ہے اور اس کے بجائے model endpoint کو call کیا جاتا ہے۔ اسی VPS پر چلنے والا Ollama self-hosted طریقہ nightly summariser بنانے کے لیے ایک منظم حل ہے۔

صارف کا انتظام، basic auth نہیں

پرانے n8n رہنما آپ کو N8N_BASIC_AUTH_ACTIVE=true سیٹ کرنے کا کہتے ہیں۔ یہ متغیرات n8n 1.0 میں ہٹا دیے گئے تھے اور اب کوئی اثر نہیں رکھتے۔ آج authentication owner account کے ذریعے ہوتی ہے: پہلی بار editor کھولنے پر n8n آپ سے email اور password والا owner بنانے کو کہتا ہے، اور یہ حفاظتی مرحلہ لازمی ہے؛ anonymous mode موجود نہیں۔ پہلے boot کے فوراً بعد، کسی کو URL دینے سے پہلے یہ account بنائیں: docker compose up اور پہلی form submission کے درمیان instance پر سب سے پہلے پہنچنے والا شخص اسے claim کر سکتا ہے۔ اس کے اوپر reverse-proxy basic-auth layer لگانا اضافی تحفظ کے طور پر مناسب ہے، لیکن یہ دوسرا حفاظتی مرحلہ ہے، اصل authentication نہیں۔ owner account اور اس رہنما میں بیان کردہ باقی تمام خصوصیات free community edition میں چلتی ہیں؛ اگر بعد میں granular roles والے اضافی users یا SSO درکار ہوں تو کون سی n8n features کے لیے paid licence درکار ہے کو پڑھ لینا بہتر ہے، اس سے پہلے کہ آپ اپنا منصوبہ ان features پر منحصر کریں۔

بیک اپ: پہلے encryption key، پھر database

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

N8N_ENCRYPTION_KEY۔ n8n میں محفوظ ہر credential، API tokens، database passwords اور OAuth secrets کو rest پر اسی key سے encrypt کیا جاتا ہے۔ Postgres میں موجود workflows اس key کے بغیر بے کار ہیں: اگر database کو مختلف key والے نئے box پر restore کیا جائے تو n8n کسی ایک credential کو بھی decrypt نہیں کر سکتا، اور نہ recovery ممکن رہتی ہے نہ reset۔ آپ کی .env فائل میں یہ key موجود ہوتی ہے؛ اسے server سے باہر کسی محفوظ جگہ copy کریں۔ اسے بنانے کے دن ہی 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

اس command کو مقررہ schedule کے مطابق چلائیں اور dump کو box سے باہر copy کریں۔ نئے VPS پر restore کرنے کے لیے: stack کو ایک بار start کریں تاکہ database موجود ہو جائے، n8n کو stop کریں، psql کے ذریعے dump واپس load کریں، وہی N8N_ENCRYPTION_KEY کو .env میں رکھیں، اور n8n start کریں۔ وہی key اور dump مل کر ایک working instance بناتے ہیں؛ نئی key ایسے workflows پیدا کرتی ہے جو کسی ایک credential کو بھی استعمال نہیں کر سکتے۔

اپ گریڈز: tag کو pin کریں

compose فائل میں n8nio/n8n:2.29.10 کو جان بوجھ کر latest کے بجائے pin کیا گیا ہے۔ n8n زیادہ تر ہفتوں میں ایک نیا minor ورژن جاری کرتا ہے اور کبھی کبھار ان کے درمیان database schema یا node کے رویے میں تبدیلی کرتا ہے، اس لیے latest کا مطلب یہ ہے کہ unattended pull آپ کو ایسا build دے سکتا ہے جو start ہوتے ہی آپ کے database کو migrate کر دے۔ ایک version pin کریں، اسے bump کرنے سے پہلے 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 نے default طور پر N8N_BLOCK_ENV_ACCESS_IN_NODE کو true میں تبدیل کر دیا۔ اس لیے وہ Code node جو process.env پڑھتا تھا، خاموشی سے access کھو دیتا ہے، جب تک آپ اسے واپس false پر set نہ کریں۔ اسی release میں settings file کے لیے strict permissions بھی نافذ کی گئیں۔ Major boundary عبور کرنے سے پہلے 2.0 breaking-changes page پڑھیں۔ n8n start ہوتے وقت درکار database migrations خودکار طور پر چلاتا ہے۔ اسی وجہ سے upgrade سے پہلے کا pg_dump اختیاری نہیں ہے۔ Credentials .env میں موجود key کے ذریعے encrypted رہتے ہیں اور data Postgres میں رہتا ہے، اس لیے containers disposable ہیں: upgrade کرنے کے لیے انہیں replace کریں، اور rollback کرنے کے لیے previous tag کو pin کرکے dump restore کریں۔

خرابی کی صورتیں اور دکھائی دینے والے پیغامات

The requested webhook "POST hello" is not registered. ایسے webhook کو کال کرنے پر 404 ملتا ہے جس کا workflow Active نہیں ہے، یا test path کو اس وقت کال کرنے پر جب کوئی اسے سن نہیں رہا ہو۔ 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 unset یا غلط ہے، اس لیے n8n نے address آپ کے public base کے بجائے N8N_HOST:N8N_PORT سے بنایا۔ WEBHOOK_URL=https://n8n.example.com/ set کریں، 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 کا نہ ہونا، یا N8N_PROTOCOL کا آپ کے connection طریقے سے مطابقت نہ رکھنا ہوتی ہے۔ چاروں public-facing variables کی تصدیق کریں اور یہ بھی دیکھیں کہ proxy Upgrade اور Connection کو forward کر رہا ہے۔

Logs میں password authentication failed for user "n8n"، اور container بار بار restart ہو رہا ہے۔ n8n جو password بھیج رہا ہے وہ database کو initialize کرتے وقت استعمال کیے گئے password سے مطابقت نہیں رکھتا۔ اہم بات یہ ہے کہ Postgres POSTGRES_PASSWORD کو صرف اسی وقت پڑھتا ہے جب وہ خالی data directory کو initialize کرتا ہے۔ Stack کو ایک بار start کرنے کے بعد .env میں POSTGRES_PASSWORD تبدیل کیا جائے تو موجودہ postgres_data volume میں پرانا password برقرار رہتا ہے۔ اسے اصل password پر واپس set کریں، یا اگر محفوظ رکھنے کے لیے کوئی data نہیں ہے تو docker compose down اور docker volume rm کے ذریعے postgres volume حذف کریں، پھر stack کو نئے سرے سے start کریں۔

Start کے وقت EACCES: permission denied, open '/home/node/.n8n/config'۔ n8n node user (UID 1000) کے طور پر چلتا ہے اور اپنی config directory میں write نہیں کر سکتا۔ یہ مسئلہ عموماً اس وقت آتا ہے جب host folder (./n8n_data:/home/node/.n8n) کو bind-mount کیا جائے اور وہ root کی ملکیت ہو۔ اوپر دکھایا گیا named volume استعمال کریں، یا bind mount ضروری ہو تو پہلے sudo chown -R 1000:1000 ./n8n_data کریں۔

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600..۔ 2.x line سے n8n اس settings file پر بطور default 0600 نافذ کرتا ہے اور boot کے وقت اسے خود درست بھی کرتا ہے۔ یہ log line بتاتی ہے کہ mode پہلے ہی درست کیا جا چکا ہے، عموماً bind mount کے بعد یا restore کے دوران file کے ڈھیلی permissions کے ساتھ واپس copy ہونے پر۔ کسی کارروائی کی ضرورت نہیں؛ N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false صرف اس وقت set کریں جب آپ کا filesystem واقعی permissions support نہ کرتا ہو۔

Mismatching encryption keys، اور مکمل line میں بتایا جاتا ہے کہ settings file میں موجود encryption key /home/node/.n8n/config آپ کے environment میں موجود N8N_ENCRYPTION_KEY سے مطابقت نہیں رکھتی۔ آپ کے environment کی key اس key سے مختلف ہے جو n8n نے پچھلے run میں اپنے data volume میں لکھی تھی۔ عموماً ایسا اس وقت ہوتا ہے جب پہلے boot پر variable unset ہونے کی وجہ سے n8n نے random key بنائی، اور بعد میں آپ نے دوسری key set کر دی۔ اصل key کو .env میں واپس رکھیں، یا صرف اسی صورت میں جب محفوظ شدہ credentials واقعی درکار نہ ہوں، n8n_data volume کے اندر موجود config file حذف کریں اور n8n کو اسے دوبارہ generate کرنے دیں۔ اس صورت میں موجودہ 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 set کیا ہے، لیکن n8n تک plain HTTP کے ذریعے پہنچے ہیں۔ عموماً ایسا IP اور port کو براہِ راست کھولنے پر ہوتا ہے، نہ کہ HTTPS proxy کے ذریعے۔ https://n8n.example.com/ کے ذریعے n8n تک پہنچیں۔ صرف اس صورت میں N8N_SECURE_COOKIE=false set کریں جب HTTPS استعمال کرنا واقعی ممکن نہ ہو، اور اسے internet-facing box پر کبھی set نہ کریں۔

ان workflows کے اندر language model شامل کرنے کے لیے Claude اور n8n کے ساتھ AI workflows بنانا دیکھیں۔

FAQ

کیا n8n کے لیے SQLite استعمال کرنا چاہیے یا Postgres؟

SQLite (پہلے سے طے شدہ) n8n آزمانے اور ایک وقت میں ایک workflow چلانے والی ذاتی instance کے لیے کافی ہے۔ جس کام پر آپ انحصار کرتے ہوں، اس کے لیے Postgres استعمال کریں: concurrency کے دوران SQLite کا single writer lock database is locked پیدا کرتا ہے، جبکہ Postgres کا backup pg_dump کے ذریعے صاف طور پر لیا جا سکتا ہے۔ بعد میں migration دستی طور پر کرنی پڑتی ہے، اس لیے اگر یہ server اہم ہے تو ابتدا ہی Postgres سے کریں۔

n8n کے webhooks کبھی trigger کیوں نہیں ہوتے؟

تقریباً ہمیشہ وجہ WEBHOOK_URL ہوتی ہے۔ اگر یہ unset یا غلط ہو تو n8n، N8N_HOST:N8N_PORT سے بنائے گئے webhook addresses دکھاتا ہے۔ ان addresses میں اکثر :5678 یا localhost شامل ہوتا ہے۔ یہ درست دکھائی دیتے ہیں، لیکن internet سے قابل رسائی نہیں ہوتے۔ اس لیے caller کی requests کبھی n8n تک نہیں پہنچتیں۔ WEBHOOK_URL=https://n8n.example.com/ set کریں اور تصدیق کریں کہ node ایسی URL دکھا رہا ہے جس میں port شامل نہ ہو۔ دوسری وجہ یہ ہے کہ آپ ایسے webhook کو call کر رہے ہیں جس کا workflow Active نہیں کیا گیا۔ اس صورت میں The requested webhook ... is not registered. واپس آتا ہے۔

n8n میں کن چیزوں کا backup لینا ضروری ہے؟

دو چیزوں کا۔ پہلی چیز آپ کی .env file سے حاصل ہونے والی N8N_ENCRYPTION_KEY ہے۔ ہر محفوظ credential اسی key سے encrypted ہوتی ہے۔ اسے کھو دینے پر credentials مستقل طور پر decrypt نہیں کیے جا سکتے۔ یہ key بنانے کے دن ہی server سے باہر copy کر لیں۔ دوسری چیز 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 اس تک پہنچ سکے۔ پھر automatic certificates کے ساتھ Traefik، یا Let's Encrypt certificate کے ساتھ nginx استعمال کریں۔ N8N_PROTOCOL=https اور WEBHOOK_URL=https://your-host/ set کریں۔ یہ بھی یقینی بنائیں کہ proxy WebSocket Upgrade headers forward کرے، ورنہ editor hang ہو جائے گا۔

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 کیا جا سکتا ہے۔