VPS پر n8n بار بار offline کیوں ہو جاتا ہے؟

n8n کے بار بار offline ہونے کی وجہ: چار failures، ایک symptom

"n8n keeps going offline" ایک ایسا جملہ ہے جو چار مختلف failures کو ظاہر کر سکتا ہے، اور ہر failure کے لیے الگ fix درکار ہے۔ container معمول کے مطابق چل رہا ہوتا ہے، لیکن editor میں connection lost کا banner دکھائی دیتا ہے۔ container خود restart ہو جاتا ہے۔ kernel زیادہ memory استعمال کرنے پر Node.js process کو ختم کر دیتا ہے۔ یا process میں کوئی خرابی نہیں ہوتی، لیکن فعال workflow کبھی run ہی نہیں ہوتا۔ غلط setting تبدیل کرنے سے آپ پورا weekend ایسے مسئلے پر صرف کر سکتے ہیں جو دراصل موجود ہی نہیں تھا۔

اس لیے configuration میں کوئی تبدیلی کرنے سے پہلے معلوم کریں کہ failure کون سا ہے۔ n8n ایک single Node.js process کے طور پر چلتا ہے، عموماً ایک Docker container کے اندر، اور اس کے سامنے ایک reverse proxy ہوتا ہے جو TLS (transport layer security) termination کرتا ہے۔ ان میں سے ہر layer اپنے مخصوص طریقے سے fail ہوتی ہے، لیکن browser ان سب کے لیے ایک ہی message دکھاتا ہے۔

اس ترتیب سے تشخیص کریں

VPS (virtual private server) پر یہ commands چلائیں اور وہ values پڑھیں جو آپ کی اپنی machine دکھاتی ہے۔ ان کا موازنہ کسی forum thread میں موجود numbers سے نہ کریں۔ یہاں اہم values آپ کے server کی حالت بیان کرتی ہیں، کسی دوسرے server کی نہیں۔

docker ps -a --filter name=n8n
docker logs --tail 200 --timestamps n8n
docker inspect n8n | grep -iE 'Status|Running|RestartCount|OOMKilled|ExitCode'
docker stats --no-stream

docker ps -a کی STATUS column بتاتی ہے کہ container موجودہ state میں کتنی دیر سے ہے۔ اس کا موازنہ اس وقت سے کریں جب مسئلہ شروع ہوا تھا۔ اگر container banner ظاہر ہونے سے بہت پہلے سے up ہے تو n8n کبھی offline نہیں ہوا۔ مسئلہ browser اور backend کے درمیان connection میں ہے۔ یہ websocket path ہے، جس کا اگلے section میں احاطہ کیا گیا ہے۔

RestartCount بتاتا ہے کہ Docker نے اس container کو کتنی بار restart کیا ہے۔ یہ number لکھ لیں، ایک منٹ انتظار کریں، پھر اسے دوبارہ پڑھیں۔ اگر آپ کے دیکھتے ہوئے number بڑھتا رہے تو یہ restart loop ہے۔ ہر restart سے فوراً پہلے کی log lines وجہ ظاہر کرتی ہیں۔

OOMKilled true یا false flag ہے۔ True کا مطلب ہے کہ Linux kernel نے process کو ختم کر دیا کیونکہ اس نے memory limit سے تجاوز کیا۔ یہ limit خود container کی یا پوری machine کی ہو سکتی ہے۔ یہ field memory kill کو ہر دوسری قسم کے exit سے الگ کرتی ہے۔ اسی لیے اندازہ لگانے سے پہلے اسے پڑھیں۔

ExitCode وہ value ہے جس کے ساتھ آپ کا container آخری بار exited ہوا۔ آپ کو ہر code کا مطلب یاد رکھنے کی ضرورت نہیں۔ اپنی value پڑھیں، پھر اسی timestamp سے docker logs کا اختتامی حصہ پڑھیں۔ Log tail اور out of memory flag مل کر بتاتے ہیں کہ کیا ہوا۔ ان میں سے کوئی ایک اکیلا گمراہ کن ہو سکتا ہے۔

docker stats موجودہ memory use کو نافذ limit کے ساتھ دکھاتا ہے۔ اسے دوسرے terminal میں چلتا رہنے دیں، وہ workflow trigger کریں جس سے مسئلہ پیدا ہوتا ہے، اور failure کے دوران number کی تبدیلی دیکھیں۔

کنکشن ختم ہونے کا بینر عموماً آپ کے reverse proxy کی وجہ سے ظاہر ہوتا ہے

n8n editor backend کے ساتھ ایک طویل مدت تک قائم رہنے والا push connection کھلا رکھتا ہے تاکہ execution کی پیش رفت canvas پر stream کی جا سکے۔ پہلے سے یہ connection WebSocket ہوتا ہے، جسے N8N_PUSH_BACKEND منتخب کرتا ہے، اور اس کی default value websocket ہے۔ WebSocket کا آغاز ایک عام HTTP request سے ہوتا ہے، جس میں Connection: Upgrade اور Upgrade: websocket headers شامل ہوتے ہیں۔ server 101 Switching Protocols کے ساتھ جواب دیتا ہے، اور اس کے بعد دونوں فریق ایک ہی TCP socket کو دونوں سمتوں میں استعمال کرتے ہیں۔

یہ عمل دو وجوہات سے متاثر ہو سکتا ہے، اور دونوں وجوہات n8n کے بجائے proxy میں ہوتی ہیں۔ proxy upstream سے HTTP/1.0 کے ذریعے بات کرتا ہے یا upgrade headers ہٹا دیتا ہے۔ اس طرح upgrade مکمل نہیں ہوتا اور editor مسلسل reconnect کرتا رہتا ہے۔ یا upgrade کامیاب ہو جاتا ہے، لیکن بعد میں proxy socket بند کر دیتا ہے کیونکہ اس پر کچھ وقت سے کوئی سرگرمی نہیں ہوئی ہوتی۔ اس کی وجہ یہ ہے کہ ایسا WebSocket جس پر کوئی message نہ آ رہا ہو، idle connection جیسا دکھائی دیتا ہے۔ دونوں صورتوں میں container درست حالت میں ہوتا ہے۔ یہ banner دراصل browser کی طرف سے اطلاع ہے کہ اس کا channel ختم ہو گیا ہے۔

کچھ بھی تبدیل کرنے سے پہلے browser میں اس کی تصدیق کریں۔ developer tools کھولیں، Network tab پر جائیں، filter کو WS پر سیٹ کریں، اور editor reload کریں۔ push request کو 101 Switching Protocols تک پہنچ کر کھلا رہنا چاہیے۔ اگر push request ordinary status code واپس کرے یا ہر چند seconds بعد دوبارہ ظاہر ہو، تو مسئلہ proxy میں ہے۔

وہ Nginx settings جو editor کو connected رکھتے ہیں

Nginx upgrade request کو خودکار طور پر آگے نہیں بھیجتا۔ proxy_pass default طور پر backend سے HTTP/1.0 کے ذریعے بات کرتا ہے، جبکہ Connection اور Upgrade hop-by-hop headers ہیں جنہیں Nginx آگے بھیجتے وقت ہٹا دیتا ہے۔ آپ کو دونوں headers دوبارہ شامل کرنے ہوں گے۔ map block کو http context میں رکھیں، server کے اندر نہیں۔

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    http2 on;
    server_name n8n.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
    }
}

proxy_read_timeout وہ line ہے جسے لوگ اکثر چھوڑ دیتے ہیں۔ اس کی default value 60 seconds ہے، اور یہ upgraded WebSocket پر بھی لاگو ہوتی ہے۔ اس لیے خاموش instance پر کھلا editor tab آخری message گزرنے کے تقریباً ایک منٹ بعد connection کھو دیتا ہے۔ اس value کو بڑھانے سے وہ banner ختم ہو جاتا ہے جو کافی دیر سے کھلے tab پر واپس آنے کے وقت دکھائی دیتا ہے۔

sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | grep -iE 'proxy_http_version|upgrade|proxy_read_timeout'

nginx -T صرف ایک file کے بجائے مکمل running configuration دکھاتا ہے۔ اس سے ثابت ہوتا ہے کہ آپ کی edit واقعی load ہوئی ہے۔ اگر configuration ایسی file میں موجود ہو جسے کوئی include line شامل نہیں کرتی، تو درست fix بھی بے اثر دکھائی دے گا۔

اس کے بعد n8n کو بتائیں کہ وہ proxy کے پیچھے چل رہا ہے، کیونکہ یہ انہی values سے URLs بناتا ہے۔

environment:
  - N8N_HOST=n8n.example.com
  - N8N_PROTOCOL=https
  - N8N_PORT=5678
  - N8N_PROXY_HOPS=1
  - N8N_WEBHOOK_URL=https://n8n.example.com/

N8N_PROXY_HOPS کی default value 0 ہے۔ اس کا مطلب ہے کہ n8n connecting address کو client address سمجھتا ہے اور X-Forwarded-For کو نظرانداز کرتا ہے۔ اسے container کے سامنے موجود proxies کی تعداد پر set کریں۔ August 2026 تک N8N_WEBHOOK_URL موجودہ نام ہے، جبکہ پرانا WEBHOOK_URL startup پر deprecation warning دکھاتے ہوئے اب بھی کام کرتا ہے۔

Traefik WebSocket کو forward کرتا ہے، پھر timeout کر دیتا ہے

Traefik بغیر کسی middleware اور اضافی labels کے WebSocket upgrade کو forward کرتا ہے۔ اس لیے Traefik استعمال کرنے والا وہ صارف جسے یہ banner نظر آئے، عموماً missing header کے بجائے timeout کا سامنا کر رہا ہوتا ہے۔ متعلقہ settings entryPoint میں ہوتی ہیں۔ August 2026 تک Traefik v3 میں، idleTimeout کی default قدر 180 seconds اور readTimeout کی default قدر 60 seconds ہے۔

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 0
        idleTimeout: 3600s

Caddy reverse_proxy میں upgrade خودکار طور پر handle کرتا ہے اور اس کے لیے کسی directive کی ضرورت نہیں ہوتی۔ اگر آپ proxy میں بالکل تبدیلی نہیں کر سکتے کیونکہ اس کا انتظام کسی اور کے پاس ہے، تو N8N_PUSH_BACKEND=sse کے ذریعے push channel تبدیل کریں۔ SSE (server-sent events) ایک عام HTTP response ہے جسے کھلا رکھا جاتا ہے، اس لیے یہ ایسے proxy کے ذریعے بھی چلتا رہتا ہے جو upgrades مسترد کرتا ہو، تاہم بہت کم idle timeout اسے بھی منقطع کر دیتا ہے۔ خود proxy کا انتخاب ایک الگ فیصلہ ہے، اور nginx، Caddy اور Traefik کا تقابلی جائزہ میں بتایا گیا ہے کہ ہر proxy کو چلانے کے لیے آپ کو کیا انتظامی لاگت برداشت کرنا پڑتی ہے۔

جب container واقعی طور پر دوبارہ start ہو رہا ہو

اگر RestartCount بڑھ رہا ہے تو container fail ہو رہا ہے اور Docker اسے دوبارہ start کر رہا ہے۔ ہر restart کے وقت کو log timestamps کے ساتھ ملائیں اور دیکھیں کہ اس سے فوراً پہلے کیا ہوا تھا۔ تقریباً تمام صورتوں کی 4 وجوہات ہوتی ہیں: startup روکنے والی configuration error، ایسا database جس تک n8n نہیں پہنچ سکتا، running حالت میں crash، اور memory kill۔

سب سے پہلے volume دیکھیں، کیونکہ permissions کا مسئلہ اکثر خاموش رہتا ہے۔ official image غیر مراعات یافتہ user node کے طور پر چلتی ہے اور اپنا data /home/node/.n8n میں رکھتی ہے۔ root کے ذریعے بنایا گیا bind mount اس user کے لیے writable نہیں ہوتا، اس لیے process ہر بار startup پر ختم ہو جاتا ہے اور restart policy اسے loop کے پیچھے چھپا دیتی ہے۔

docker compose config
docker run --rm -it --entrypoint sh docker.n8n.io/n8nio/n8n -c 'id'
docker exec n8n ls -ld /home/node/.n8n

named volume اس مسئلے سے مکمل طور پر بچا لیتا ہے، کیونکہ Docker اسے درست ownership کے ساتھ بناتا ہے۔ اگر bind mount درکار ہو تو chown host directory کو پہلے command میں دکھائی گئی numeric user id کے مطابق set کریں۔ host اور container کے درمیان ownership mapping کو ایک بار سمجھ لینا مفید ہے، اور PUID اور PGID کی وضاحت بتاتی ہے کہ یہ images فائلیں لکھنے والے user کا تعین کیسے کرتی ہیں۔

وہ out of memory kill جو crash جیسا دکھائی دیتا ہے

ایک n8n process کے اوپر memory کی دو الگ حدود ہوتی ہیں، اور دونوں مختلف طریقے سے failure پیدا کرتی ہیں۔ Container control group limit kernel نافذ کرتا ہے: اسے عبور کرتے ہی process فوراً kill ہو جاتا ہے، اسے کچھ بھی لکھنے کا موقع نہیں ملتا، اور OOMKilled کی قدر true ہوتی ہے۔ V8 heap limit Node.js کے اندر نافذ ہوتی ہے: اسے عبور کرنے پر Node، stack trace کے ساتھ heap error دیتا ہے اور خود exit ہو جاتا ہے، اس لیے OOMKilled کی قدر false ہوتی ہے۔ Browser سے دونوں صورتیں ایک جیسی دکھائی دیتی ہیں۔ docker inspect میں یہ دونوں صرف ایک field کے فرق سے الگ ہوتی ہیں۔

Node heap ceiling کو container limit سے کم رکھیں۔ اگر heap ceiling دونوں میں زیادہ ہو تو V8 اس مقام سے بھی آگے allocation جاری رکھتا ہے جہاں kernel مداخلت کرتا ہے۔ اس طرح اس کا garbage collector اپنی حد تک نہیں پہنچتا، اور آپ کو ہمیشہ زیادہ سخت failure ملتا ہے جسے پڑھنے کے لیے کوئی log موجود نہیں ہوتا۔

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - NODE_OPTIONS=--max-old-space-size=<MiB, below the container limit>
    deploy:
      resources:
        limits:
          memory: <your container limit>

دونوں numbers کا انتخاب اپنے VPS میں موجود حقیقی وسائل کے مطابق کریں، اور database، proxy اور operating system کے لیے گنجائش باقی رکھیں۔ docker stats --no-stream موجودہ استعمال کو نافذ limit کے ساتھ دکھاتا ہے، اس لیے آپ تصدیق کر سکتے ہیں کہ آپ کی لکھی ہوئی limit وہی ہے جسے Docker نے apply کیا ہے۔ Compose کی memory limits کیسے apply ہوتی ہیں میں بتایا گیا ہے کہ کئی limits set ہونے پر کون سی key مؤثر ہوتی ہے۔

ایگزیکیوشن کا ڈیٹا وہ ہے جو آپ کے نیچے بڑھتا رہتا ہے

ایک execution میں run جاری رہنے کے دوران ہر node کا output موجود رہتا ہے، اور n8n پھر یہ data محفوظ کرتا ہے۔ اس کے دو نتائج نکلتے ہیں۔ ایک run کی peak memory اس بڑے ترین data batch سے متعین ہوتی ہے جسے آپ اس میں سے گزارتے ہیں۔ اس لیے ایک ہی workflow جو بیک وقت دس ہزار rows سنبھالتا ہے، اسی workflow سے مختلف program ہے جو ایک وقت میں دو سو rows سنبھالتا ہے۔ محفوظ شدہ copy بھی اس وقت تک بڑھتی رہتی ہے جب تک کوئی اسے delete نہ کر دے۔

Pruning دوسرے مسئلے کو حل کرتی ہے۔ August 2026 تک defaults میں pruning enabled ہے، EXECUTIONS_DATA_MAX_AGE کی قدر 336 hours (14 days) اور EXECUTIONS_DATA_PRUNE_MAX_COUNT کی قدر 10000 ہے۔ یہ ایک چھوٹے VPS کے لیے مناسب سے زیادہ مدت ہے جو SQLite چلا رہا ہو، کیونکہ ایک ہی file میں سب کچھ محفوظ ہوتا ہے اور editor فراہم کرنے والے اسی process کو اسے read اور write بھی کرنا پڑتا ہے۔

environment:
  - EXECUTIONS_DATA_PRUNE=true
  - EXECUTIONS_DATA_MAX_AGE=72
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
  - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none aggressive setting ہے۔ یہ debugging کے لیے failed executions محفوظ رکھتی ہے اور successful executions کو discard کر دیتی ہے۔ یہ فیصلہ جان بوجھ کر کریں، کیونکہ اگر کسی workflow نے error دیے بغیر غلط output پیدا کیا تو پھر معائنے کے لیے آپ کے پاس کچھ نہیں بچے گا۔ Pruning پہلے rows کو deleted کے طور پر mark کرتی ہے اور بعد کے pass میں انہیں remove کرتی ہے۔ SQLite خالی ہونے والے pages کو دوبارہ استعمال کرتی ہے، انہیں واپس نہیں کرتی، اس لیے setting تبدیل کرتے ہی disk پر موجود file فوراً چھوٹی نہیں ہوتی۔

Stored total کم کرنے کے بجائے peak کم کرنے کے لیے ہر run میں کم data منتقل کریں۔ بڑے jobs کو ایسے sub-workflows میں تقسیم کریں جو parent کو چھوٹے results واپس کریں، Loop Over Items node کے ساتھ batch بنائیں، اور مکمل datasets کو Code node سے باہر رکھیں۔

بائنری فائلیں میموری کے ذریعے منتقل نہیں ہونی چاہییں

N8N_DEFAULT_BINARY_DATA_MODE کی default قدر default ہے، جس کے باعث بائنری ڈیٹا چلنے والی execution کی میموری میں رہتا ہے۔ ہر وہ فائل جو کوئی node download کرتا ہے، اور ہر وہ copy جو اگلے node کو دی جاتی ہے، run ختم ہونے تک وہیں رہتی ہے۔ چند بڑی attachments حاصل کرنے والا ایک workflow process کو اس حد سے آگے لے جا سکتا ہے جہاں عام JSON کام کبھی نہیں پہنچتا۔ اسی لیے crash وقت گزرنے کے بجائے ایک مخصوص workflow کے بعد ہوتا ہے۔

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

filesystem کے ساتھ بائنری ڈیٹا N8N_BINARY_DATA_STORAGE_PATH کے تحت لکھا جاتا ہے۔ یہ جگہ default طور پر n8n user folder کے اندر ہوتی ہے، اس لیے ڈیٹا اسی volume پر محفوظ ہوتا ہے جس پر باقی سب کچھ موجود ہے۔ تبدیلی کرنے سے پہلے تصدیق کریں کہ volume میں کافی جگہ موجود ہے۔ N8N_PAYLOAD_SIZE_MAX آنے والے webhook payload کا زیادہ سے زیادہ سائز MiB (mebibytes) میں مقرر کرتا ہے اور اس کی default قدر 16 ہے۔ اس قدر کو بڑھانے سے بڑی requests قبول ہو جاتی ہیں، لیکن اس کے لیے اضافی memory درکار ہوگی، جسے قبول کرنے کا فیصلہ آپ کر رہے ہیں۔

سرور پر چلنے والی دیگر تمام چیزیں اسی RAM کے لیے مقابلہ کرتی ہیں۔ اگر OOM kills کسی database container کو شامل کرنے کے بعد شروع ہوئے ہیں تو database کو Docker میں یا host پر چلانا اب آپ کے سامنے موجود trade-off ہے۔

ری اسٹارٹ پالیسی اور reboot کے بعد دوبارہ شروع ہونا

جس container پر restart policy مقرر نہ ہو، وہ exit ہونے کے بعد اور host کے reboot کے بعد بند رہتا ہے۔ restart: unless-stopped دونوں صورتوں میں اسے دوبارہ چلا دیتا ہے، جبکہ ہاتھ سے stop کیے گئے container کا احترام بھی کرتا ہے۔ restart: always جان بوجھ کر stop کیے گئے container کو بھی Docker کے اگلی بار start ہونے پر دوبارہ شروع کر دیتا ہے۔

n8n ایک health endpoint فراہم کرتا ہے، جسے N8N_ENDPOINT_HEALTH سے نامزد کیا جاتا ہے اور جس کی default قدر healthz ہے۔ پہلے اسے host سے check کریں تاکہ تصدیق ہو جائے کہ آپ کی instance پر path درست ہے۔

curl -fsS http://127.0.0.1:5678/healthz
docker exec n8n which wget curl
sudo systemctl is-enabled docker

healthcheck خود سے کچھ بھی restart نہیں کرتا۔ Compose container کو unhealthy نشان زد کرتا ہے اور وہیں رک جاتا ہے۔ اس لیے healthcheck کے مؤثر ہونے کے لیے اس کے ساتھ restart policy یا external watcher درکار ہوتا ہے۔ ایسا healthcheck لکھنا جو واقعی کارروائی کرے اور reboot کے بعد stack کو دوبارہ start کرانا دونوں پہلوؤں کا احاطہ کرتے ہیں۔

وہ workflow جو n8n کے درست ہونے کے باوجود کبھی اجرا نہیں کرتا

اس میں کوئی banner ظاہر نہیں ہوتا اور نہ ہی restart ہوتا ہے۔ Container چل رہا ہے، editor کام کر رہا ہے، لیکن جس run کی آپ کو توقع تھی وہ executions list میں موجود نہیں ہے۔ اس کی زیادہ تر وجوہات یہ چار ہیں۔

• Workflow active نہیں ہے۔ Schedule Trigger صرف production path پر چلتا ہے، اس لیے اسے canvas میں test کرنے سے کوئی schedule نہیں بنتا۔
• Timezone آپ کے مطابق نہیں ہے۔ GENERIC_TIMEZONE کی default قدر America/New_York ہے، اس لیے 09:00 کے لیے مقرر کیا گیا schedule اس zone کے وقت کے مطابق 09:00 پر چلتا ہے، جب تک آپ GENERIC_TIMEZONE اور TZ کو اپنی timezone پر set نہ کریں۔
• Downtime کے بعد missed run دوبارہ نہیں چلتا۔ n8n کے start ہونے پر triggers register ہوتے ہیں، اس لیے container کے restart ہونے کے دوران due ہونے والا schedule دیر سے run نہیں ہوتا۔ Startup کے بعد اگلا run اگلے مقررہ وقت پر ہوتا ہے۔
• Workflow آپ کی طرف سے deactivate ہو گیا ہے۔ N8N_WORKFLOW_AUTODEACTIVATION_ENABLED default طور پر off ہوتا ہے۔ جب یہ on ہو تو مسلسل crash ہونے والا workflow unpublished ہو جاتا ہے، اور اس کے بعد یہ بالکل ایسا دکھائی دیتا ہے جیسے اسے کبھی activate ہی نہیں کیا گیا تھا۔

Executions list کھولیں اور اسے اسی workflow تک filter کریں۔ اگر failed entry موجود ہے تو مسئلہ workflow میں ہے۔ اگر کوئی entry موجود ہی نہیں تو مسئلہ trigger میں ہے، اور دیکھنے کی جگہ اوپر دی گئی چار وجوہات ہیں۔

پہلے کیا تبدیل کریں

1. کسی بھی فائل میں ترمیم کرنے سے پہلے اپنے container میں STATUS، RestartCount اور OOMKilled پڑھیں۔
2. اگر container کبھی بند نہیں ہوا تھا تو proxy کے upgrade headers اور idle timeout درست کریں۔
3. اگر OOMKilled درست ہے تو اپنی ضرورت کے مطابق container limit مقرر کریں، Node heap کی حد اس سے کم رکھیں، اور binary data کو filesystem پر منتقل کریں۔
4. اگر کوئی کارروائی نہیں ہوئی تو تصدیق کریں کہ workflow فعال ہے اور instance کا timezone آپ کے مطلوبہ timezone پر سیٹ ہے۔

یہ زیادہ تر ایسی configuration ہے جسے working install کے اوپر ایک بار set کرنے کے بعد دوبارہ تبدیل کرنے کی ضرورت نہیں پڑتی۔ اگر آپ ابھی وہ install تیار کر رہے ہیں تو HTTPS کے ساتھ Docker پر n8n چلانے کی رہنما دستاویز وہ بنیادی setup ہے جس میں یہ settings شامل کی جاتی ہیں۔

FAQ

n8n کا editor container کے چلنے کے باوجود connection lost کا banner کیوں دکھاتا ہے؟

Editor execution progress stream کرنے کے لیے WebSocket کھلا رکھتا ہے۔ اگر reverse proxy Connection: Upgrade اور Upgrade: websocket headers آگے forward نہ کرے، یا upstream کے لیے HTTP/1.1 استعمال نہ کرے، تو upgrade مکمل نہیں ہوتا۔ اس کے نتیجے میں browser مسلسل reconnect کرتا رہتا ہے، جبکہ n8n درست حالت میں چلتا رہتا ہے۔ nginx میں proxy_http_version 1.1 کے علاوہ دونوں proxy_set_header lines درکار ہیں۔ اس کے ساتھ proxy_read_timeout کی مدت default 60 seconds سے زیادہ ہونی چاہیے، تاکہ خاموش tab کا connection ختم نہ ہو۔ Edited file کے بجائے running config کو sudo nginx -T سے چیک کریں۔

عام crash اور out of memory kill میں فرق کیسے معلوم کریں؟

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' چلائیں اور OOMKilled flag پڑھیں۔ True کا مطلب ہے کہ kernel نے memory limit سے تجاوز کرنے پر process کو ختم کیا۔ Container log میں مفید معلومات نہیں ہوں گی، کیونکہ process کو لکھنے کا موقع ہی نہیں ملا۔ اگر False ہو، اور docker logs کے آخر میں heap error اور stack trace موجود ہو، تو Node.js اپنی V8 heap ceiling تک پہنچ کر خود exit ہوا ہے۔ NODE_OPTIONS=--max-old-space-size کو اپنے container limit سے کم مقرر کریں، تاکہ دوسرا failure ظاہر ہو۔ یہی failure ثبوت محفوظ کرتا ہے۔

کیا execution data کو prune کرنے سے disk space فوراً خالی ہو جاتی ہے؟

نہیں۔ EXECUTIONS_DATA_PRUNE پرانی executions کو deletion کے لیے نشان زد کرتا ہے، اور بعد میں ہونے والا pass انہیں EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL کی مقررہ schedule کے مطابق حذف کرتا ہے۔ SQLite میں file freed pages کو filesystem کو واپس کرنے کے بجائے دوبارہ استعمال بھی کرتی ہے۔ اس لیے rows حذف ہونے کے بعد کچھ وقت تک disk پر file کا size کم نہیں ہوتا۔ EXECUTIONS_DATA_MAX_AGE اور EXECUTIONS_DATA_PRUNE_MAX_COUNT کو اپنے system کے مطابق مقرر کریں۔ پھر فوراً نہیں، اگلے دن دوبارہ چیک کریں۔

n8n کے restart ہونے کے دوران میری scheduled workflow کیوں نہیں چلی؟

n8n process start ہونے پر triggers register کرتا ہے۔ یہ ان schedules کو دوبارہ execute نہیں کرتا جو process کے بند رہنے کے دوران due ہو چکی ہوں۔ اس لیے restart loop کے نتیجے میں catch-up runs کا ایک ساتھ سلسلہ شروع نہیں ہوتا۔ Startup کے بعد اگلی execution اگلے due time پر ہوتی ہے۔ اگر ایسی runs ضروری ہیں جو miss نہیں ہونی چاہئیں، تو workflow کو webhook کو call کرنے والے external caller سے چلائیں۔ اس طرح retry logic n8n کے باہر رہتی ہے۔

کیا healthcheck، n8n کے response دینا بند کرنے پر اسے restart کر دے گا؟

خود سے نہیں۔ Compose healthcheck صرف container کو healthy یا unhealthy mark کرتا ہے۔ Restart کرنا restart policy کی ذمہ داری ہے۔ اس لیے restart: unless-stopped container کے exit ہونے کے بعد اسے واپس چلاتا ہے۔ Docker service enabled ہو تو host reboot کے بعد بھی container واپس چل جاتا ہے۔ اس کی تصدیق sudo systemctl is-enabled docker سے کریں۔ صرف unhealthy حالت پر کارروائی کرنے کے لیے Docker کے باہر ایک watcher درکار ہے، جو status پڑھ کر service restart کرے۔