VPS-এ n8n offline হওয়ার আসল কারণ কীভাবে খুঁজবেন

n8n কেন offline হয়ে যায়: চারটি ব্যর্থতা, একটি উপসর্গ

“n8n keeps going offline” কথাটি চারটি ভিন্ন ব্যর্থতাকে বোঝাতে পারে, এবং প্রতিটির সমাধানও আলাদা। container স্বাভাবিকভাবে চললেও editor-এ connection lost banner দেখা যেতে পারে। container নিজে থেকেই restart হতে পারে। অতিরিক্ত memory ব্যবহারের কারণে kernel Node.js process-টিকে বন্ধ করে দিতে পারে। অথবা process-এর কোনো সমস্যাই না থাকলেও সক্রিয় workflow কখনো চালু নাও হতে পারে। ভুল setting পরিবর্তন করলে এমন একটি সমস্যা সমাধানে পুরো weekend নষ্ট হতে পারে, যে সমস্যা আসলে ছিলই না।

তাই কোনো configuration পরিবর্তন করার আগে আপনার ক্ষেত্রে কোন ব্যর্থতাটি ঘটেছে তা শনাক্ত করুন। n8n একটি single Node.js process হিসেবে চলে, সাধারণত TLS (transport layer security) termination করা একটি reverse proxy-এর পেছনে একটি Docker container-এর ভিতরে থাকে। প্রতিটি layer নিজস্ব উপায়ে ব্যর্থ হতে পারে, কিন্তু browser সবগুলোর জন্য একই message দেখায়।

এই ক্রমে নির্ণয় করুন

VPS (virtual private server)-এ এই command-গুলো চালান এবং আপনার নিজের machine যে value দেখায় তা পড়ুন। কোনো forum thread-এর number-এর সঙ্গে এগুলো তুলনা করবেন না। এখানে গুরুত্বপূর্ণ value-গুলো আপনার 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-এ আছে। আপনার সমস্যা শুরু হওয়ার সময়ের সঙ্গে এটি তুলনা করুন। banner দেখা দেওয়ার অনেক আগে থেকেই container চালু থাকলে n8n কখনো offline যায়নি। সমস্যা হয়েছে আপনার browser এবং backend-এর মধ্যকার connection-এ। পরের section-এ এই websocket path নিয়ে আলোচনা করা হয়েছে।

RestartCount হলো Docker এই container-টি কতবার restart করেছে তার সংখ্যা। সংখ্যাটি লিখে রাখুন, এক মিনিট অপেক্ষা করুন, তারপর আবার পড়ুন। আপনি দেখার সময় সংখ্যা বাড়লে এটি restart loop। প্রতিটি restart-এর ঠিক আগের log line-গুলোতেই কারণটি থাকে।

OOMKilled হলো true অথবা false flag। True হলে Linux kernel process-টিকে বন্ধ করেছে, কারণ process-টি কোনো memory limit অতিক্রম করেছে। এই limit container-এর নিজস্ব limit অথবা পুরো machine-এর limit হতে পারে। এই একটি field memory kill-কে অন্য সব ধরনের exit থেকে আলাদা করে। তাই অনুমান করার আগে এটি পড়ুন।

ExitCode হলো আপনার container সর্বশেষ যে exit code দিয়ে বন্ধ হয়েছে। প্রতিটি code-এর অর্থ মুখস্থ করার প্রয়োজন নেই। আপনার code পড়ুন। তারপর একই timestamp থেকে docker logs-এর শেষ অংশ পড়ুন। Log-এর শেষ অংশ এবং out of memory flag একসঙ্গে কী ঘটেছে তা জানায়। যেকোনো একটি একা দেখলে ভুল সিদ্ধান্ত হতে পারে।

docker stats কার্যকর limit-এর পাশে বর্তমান memory use দেখায়। এটি দ্বিতীয় terminal-এ চালু রাখুন। যে workflow-এ সমস্যা হয় সেটি চালান। Failure ঘটার সময় number-টি কীভাবে পরিবর্তিত হয় তা দেখুন।

সংযোগ বিচ্ছিন্ন হওয়ার ব্যানারের কারণ সাধারণত আপনার reverse proxy

n8n editor backend-এর সঙ্গে একটি দীর্ঘস্থায়ী push connection খোলা রাখে, যাতে execution-এর অগ্রগতি canvas-এ দেখানো যায়। ডিফল্টভাবে এই connection একটি WebSocket, যা N8N_PUSH_BACKEND নির্বাচন করে, এবং এর default value হলো websocket। WebSocket প্রথমে Connection: Upgrade এবং Upgrade: websocket header বহনকারী একটি সাধারণ HTTP request হিসেবে শুরু হয়। Server 101 Switching Protocols দিয়ে উত্তর দেয়। এরপর উভয় পক্ষ একই TCP socket ব্যবহার করে দুই দিকেই যোগাযোগ করে।

দুটি কারণে এই প্রক্রিয়া ব্যর্থ হতে পারে। দুটিরই অবস্থান n8n-এর বদলে proxy-তে। Proxy upstream-এ HTTP/1.0 ব্যবহার করে অথবা upgrade header সরিয়ে দেয়। ফলে upgrade সম্পন্ন হয় না এবং editor বারবার reconnect করতে থাকে। অথবা upgrade সফল হওয়ার পর proxy socket বন্ধ করে দেয়, কারণ সেখানে কোনো activity না থাকলে WebSocket-কে idle connection হিসেবে দেখা হয়। উভয় ক্ষেত্রেই container সুস্থ থাকে। ব্যানারটি শুধু জানায় যে browser তার channel হারিয়েছে।

কোনো কিছু সম্পাদনা করার আগে browser-এ এটি নিশ্চিত করুন। Developer tools খুলুন, Network tab-এ যান, WS filter প্রয়োগ করুন এবং editor reload করুন। Push request-এর 101 Switching Protocols-এ পৌঁছে open অবস্থায় থাকা উচিত। কোনো push request যদি সাধারণ status code ফেরত দেয় অথবা কয়েক সেকেন্ড পরপর আবার দেখা দেয়, তাহলে সমস্যাটি proxy-তে থাকার সম্ভাবনা বেশি।

সম্পাদক সংযুক্ত রাখে এমন nginx সেটিং

nginx-কে নির্দেশ না দিলে এটি upgrade forward করে না। proxy_pass ডিফল্টভাবে backend-এর সঙ্গে HTTP/1.0 ব্যবহার করে, আর Connection ও Upgrade হলো hop-by-hop header, যেগুলো nginx পথিমধ্যে সরিয়ে দেয়। দুটিই আবার যোগ করতে হবে। map block-টি http context-এর মধ্যে থাকবে, server-এর ভিতরে নয়। নিচের server block-এর বাকি অংশ অপরিচিত হলে nginx server block-এর প্রতিটি লাইন ব্যাখ্যা করা নির্দেশিকা প্রতিটি directive কী করে তা দেখায়।

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 60 seconds এবং এটি upgraded WebSocket-এর ক্ষেত্রেও প্রযোজ্য। তাই নীরব instance-এ খোলা editor tab-এ শেষ message যাওয়ার প্রায় এক মিনিট পর connection বিচ্ছিন্ন হয়ে যায়। এই মান বাড়ালেই খোলা রেখে আসা tab-এ ফিরে এলে যে banner দেখা যায়, সেটি আর আসে না।

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

nginx -T একটি file-এর পরিবর্তে সম্পূর্ণ চলমান configuration দেখায়। তাই এটি নিশ্চিত করে যে আপনার edit আসলেই load হয়েছে। এমন configuration, যা কোনো include line গ্রহণ করে না, সঠিক fix কার্যকর না হওয়ার কারণ হতে পারে।

এরপর n8n-কে জানান যে এটি একটি proxy-এর পেছনে চলছে, কারণ n8n এই মানগুলো থেকে URL তৈরি করে।

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 0। এর অর্থ n8n connecting address-কে client address হিসেবে ধরে এবং X-Forwarded-For উপেক্ষা করে। container-এর সামনে থাকা proxy-এর সংখ্যা অনুযায়ী এটি সেট করুন। August 2026 অনুযায়ী, N8N_WEBHOOK_URL হলো বর্তমান নাম। পুরোনো WEBHOOK_URL এখনও কাজ করে, তবে startup-এর সময় deprecation warning দেখায়।

Traefik WebSocket forward করে, তারপর timeout ঘটায়

Traefik কোনো middleware বা অতিরিক্ত label ছাড়াই WebSocket upgrade forward করে। তাই Traefik ব্যবহারকারী এই banner দেখলে সাধারণত missing header নয়, timeout-এর মুখোমুখি হচ্ছেন। নিয়ন্ত্রণের option-গুলো 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 পরিচালনা করে এবং এর জন্য কোনো directive প্রয়োজন হয় না। আপনি যদি proxy-তে কোনো পরিবর্তন করতে না পারেন, কারণ এটি অন্য কেউ পরিচালনা করে, তাহলে N8N_PUSH_BACKEND=sse ব্যবহার করে push channel পরিবর্তন করুন। SSE (server-sent events) হলো একটি স্বাভাবিক HTTP response, যা খোলা রাখা হয়। তাই upgrade প্রত্যাখ্যান করা proxy-এর মাধ্যমেও এটি কাজ করে। তবে idle timeout খুব কম হলে সংযোগ বিচ্ছিন্ন হয়ে যায়। Proxy নির্বাচন করা আলাদা সিদ্ধান্ত। nginx, Caddy এবং Traefik-এর তুলনা-এ প্রতিটি proxy পরিচালনার খরচ ব্যাখ্যা করা হয়েছে।

কনটেইনার সত্যিই পুনরায় চালু হলে

যদি RestartCount বাড়তে থাকে, তাহলে কনটেইনার ব্যর্থ হচ্ছে এবং Docker সেটিকে পুনরায় চালু করছে। প্রতিটি restart-এর সঙ্গে log timestamp মিলিয়ে দেখুন এবং তার ঠিক আগে কী ঘটেছিল তা পড়ুন। প্রায় সব ক্ষেত্রে চারটি কারণের একটি থাকে: startup বন্ধ করে দেওয়া configuration error, যে database-এ n8n পৌঁছাতে পারছে না, চালু হওয়ার পরে crash, অথবা memory kill।

প্রথমে volume পরীক্ষা করুন, কারণ permissions সমস্যাটি সহজে চোখে পড়ে না। Official image-টি unprivileged user node হিসেবে চলে এবং /home/node/.n8n-এ data সংরক্ষণ করে। root দ্বারা তৈরি bind mount ওই user লিখতে পারে না। তাই প্রতিবার startup-এর সময় process বন্ধ হয়ে যায়, আর 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 প্রয়োজন হলে, প্রথম command যে numeric user id দেখিয়েছে, host directory-টির ownership সেই id-তে পরিবর্তন করতে chown ব্যবহার করুন। Host ও container-এর মধ্যে ownership mapping একবার বোঝা দরকার। এই image-গুলো কীভাবে কোন user file লিখবে তা নির্ধারণ করে, সে বিষয়ে PUID ও PGID ব্যাখ্যা দেখুন।

ক্র্যাশের মতো দেখানো out-of-memory kill

একটি n8n process-এর ওপর দুটি আলাদা memory ceiling থাকে। এগুলো ভিন্নভাবে ব্যর্থ হয়। Container control group limit kernel প্রয়োগ করে: এটি অতিক্রম করলে process-টি সঙ্গে সঙ্গে kill হয়, কিছু লেখার সুযোগও থাকে না, এবং OOMKilled true দেখায়। V8 heap limit Node.js-এর ভেতরে প্রয়োগ হয়: এটি অতিক্রম করলে Node একটি heap error ও stack trace দেখিয়ে নিজে থেকে exit করে, তাই OOMKilled false দেখায়। Browser থেকে দুটিকে একই রকম মনে হয়। docker inspect-এ এগুলো মাত্র একটি field-এর ব্যবধানে আলাদা।

Node heap ceiling-টি container limit-এর নিচে সেট করুন। Heap ceiling যদি দুটির মধ্যে বেশি হয়, তাহলে kernel হস্তক্ষেপ করার সীমা পেরিয়েও V8 allocation চালিয়ে যায়। ফলে garbage collector নিজের limit-এ পৌঁছাতে পারে না, এবং আপনি সব সময় 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>

আপনার VPS-এ বাস্তবে যত memory আছে, তা দেখে দুটি সংখ্যা নির্ধারণ করুন। Database, proxy এবং operating system-এর জন্য অতিরিক্ত memory রাখুন। docker stats --no-stream বর্তমান ব্যবহার এবং কার্যকর limit পাশাপাশি দেখায়। তাই আপনি যাচাই করতে পারবেন, যে limit লিখেছেন Docker সেটিই প্রয়োগ করেছে কি না। Compose memory limit কীভাবে প্রয়োগ হয়-এ একাধিক limit সেট করা থাকলে কোন key কার্যকর হয়, তা ব্যাখ্যা করা হয়েছে।

Execution data আপনার সিস্টেমে জমতে থাকে

একটি execution চলাকালে সেটির প্রতিটি node-এর output ধরে রাখে, এবং পরে n8n সেই data সংরক্ষণ করে। এর দুটি ফল আছে। একটি run-এর সর্বোচ্চ memory usage নির্ধারিত হয় আপনি এর মধ্য দিয়ে পাঠানো সবচেয়ে বড় data batch-এর আকারে। তাই একই workflow একবারে দশ হাজার row সামলালে, প্রতি বার দুই শত row সামলানোর তুলনায় সেটি ভিন্ন ধরনের program। আর কোনো কিছু মুছে না ফেলা পর্যন্ত সংরক্ষিত copy-এর আকার বাড়তেই থাকে।

Pruning দ্বিতীয় সমস্যাটি সামলায়। August 2026 অনুযায়ী pruning enabled থাকে, EXECUTIONS_DATA_MAX_AGE 336 hours (14 days) এবং EXECUTIONS_DATA_PRUNE_MAX_COUNT 10000-এ সেট করা থাকে। SQLite ব্যবহারকারী ছোট VPS-এর জন্য এগুলো যথেষ্ট উদার default। সেখানে একটি file-এই সব data থাকে, এবং editor পরিবেশনকারী একই process-কে সেই file 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 execution সংরক্ষণ করে এবং successful execution মুছে ফেলে। এই সিদ্ধান্ত ইচ্ছাকৃতভাবে নিন। কারণ কোনো workflow error না দেখিয়ে ভুল output তৈরি করলে পরে পরীক্ষা করার মতো কিছুই নাও থাকতে পারে। Pruning প্রথমে row-গুলোকে deleted হিসেবে চিহ্নিত করে এবং পরবর্তী pass-এ সেগুলো মুছে ফেলে। এছাড়া SQLite মুক্ত page পুনর্ব্যবহার করে, সেগুলো operating system-এ ফেরত দেয় না। তাই setting পরিবর্তন করার সঙ্গে সঙ্গে disk-এর file ছোট হয় না।

সংরক্ষিত মোট data কমানোর বদলে peak memory usage কমাতে চাইলে প্রতিটি run-এ কম data স্থানান্তর করুন। বড় job-গুলোকে এমন sub-workflow-এ ভাগ করুন, যেগুলো parent workflow-এ ছোট result ফেরত দেয়। Loop Over Items node ব্যবহার করে batch তৈরি করুন। সম্পূর্ণ dataset Code node-এর বাইরে রাখুন।

Binary ফাইল memory-র মধ্য দিয়ে চলা উচিত নয়

N8N_DEFAULT_BINARY_DATA_MODE-এর default মান হলো default। এতে চলমান execution-এর memory-তে binary data রাখা হয়। কোনো node যে ফাইল download করে এবং পরবর্তী node-এ পাঠানো প্রতিটি copy সেখানে execution শেষ হওয়া পর্যন্ত থাকে। কয়েকটি বড় attachment fetch করা একটি workflow-ই process-কে এমন memory limit অতিক্রম করাতে পারে, যা সাধারণ JSON কাজের ক্ষেত্রে কখনো হয় না। তাই crash নির্দিষ্ট একটি workflow অনুসরণ করে, সময়ের ভিত্তিতে নয়।

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

filesystem ব্যবহার করলে binary data N8N_BINARY_DATA_STORAGE_PATH-এর অধীনে লেখা হয়। Default অবস্থায় এটি n8n user folder-এর মধ্যে থাকে, তাই অন্যান্য সবকিছুর মতো একই volume-এ লেখা হয়। পরিবর্তন করার আগে volume-এ পর্যাপ্ত খালি স্থান আছে কি না পরীক্ষা করুন। N8N_PAYLOAD_SIZE_MAX incoming webhook payload-এর সর্বোচ্চ আকার MiB (mebibytes) হিসেবে নির্ধারণ করে এবং default মান 16। এই মান বাড়ালে বড় request গ্রহণ করা যায়, তবে এর memory খরচ আপনাকেই গ্রহণ করতে হবে।

একই server-এর অন্যান্য process ও service একই RAM ব্যবহারের জন্য প্রতিযোগিতা করে। Database container যোগ করার পর যদি OOM kill শুরু হয়ে থাকে, তাহলে Docker-এ বা host-এ database চালানো হলো আপনার নেওয়া trade-off।

Restart policy এবং reboot-এর পরে আবার চালু হওয়া

কোনো container-এ restart policy না থাকলে সেটি exit করার পরে এবং host reboot হওয়ার পরে বন্ধই থাকে। restart: unless-stopped উভয় ক্ষেত্রেই container-টি আবার চালু করে, তবে আপনি হাতে বন্ধ করে দেওয়া container-কে সম্মান করে। restart: always ইচ্ছাকৃতভাবে বন্ধ করা container-টিকেও Docker পরেরবার চালু হলে আবার restart করে।

n8n একটি health endpoint সরবরাহ করে। N8N_ENDPOINT_HEALTH এই endpoint-এর নাম নির্ধারণ করে, যার default মান healthz। আপনার instance-এ path সঠিক কি না নিশ্চিত করতে প্রথমে host থেকে এটি পরীক্ষা করুন।

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 আবার চালু করা—এই দুই অংশই ব্যাখ্যা করে।

n8n ঠিক থাকলেও যে workflow কখনো চালু হয় না

এটি কোনো banner দেখায় না এবং restart-ও করে না। container চালু আছে, editor কাজ করছে, কিন্তু প্রত্যাশিত run-টি executions list-এ নেই। সাধারণত চারটি কারণে এমন হয়।

• workflow active নয়। Schedule Trigger শুধু production path-এ চলে। তাই canvas-এ এটি পরীক্ষা করলে কোনো schedule তৈরি হয় না।
• timezone আপনার সেট করা নয়। GENERIC_TIMEZONE-এর default হলো America/New_York। তাই GENERIC_TIMEZONE এবং TZ-এ নিজের timezone সেট না করা পর্যন্ত 09:00-এর schedule ওই timezone অনুযায়ী 09:00-তেই চালু হবে।
• downtime-এর সময় বাদ পড়া run পরে স্বয়ংক্রিয়ভাবে পূরণ হয় না। n8n চালু হওয়ার সময় trigger register হয়। তাই container restart হওয়ার সময় কোনো schedule-এর নির্ধারিত সময় পার হয়ে গেলে সেটি দেরিতে চলে না। startup-এর পর পরবর্তী নির্ধারিত সময়েই পরের run হবে।
• workflow আপনার জন্য deactivated হয়েছে। N8N_WORKFLOW_AUTODEACTIVATION_ENABLED default-ভাবে বন্ধ থাকে। এটি চালু থাকলে বারবার crash করা workflow unpublished হয়ে যায়। এরপর সেটি এমন দেখায় যেন কেউ কখনো active-ই করেনি।

Executions list খুলে ওই workflow-এ filter করুন। কোনো failed entry থাকলে সমস্যাটি workflow-এ। এটি একই server-এ চালানো অন্য কোনো service-এর বিরুদ্ধে 429 error-এ ব্যর্থ হলে limit-টি n8n-এর নয়, ওই service-এর। SearXNG 429 সংক্রান্ত walkthrough-এ নিজের rate limiter এবং আপনার server IP block করা engine-গুলোর মধ্যে পার্থক্য বোঝার পদ্ধতি দেখানো হয়েছে। কোনো entry না থাকলে এটি trigger-এর সমস্যা। তখন উপরের চারটি কারণ পরীক্ষা করুন।

প্রথমে যা পরিবর্তন করবেন

1. কোনো ফাইল সম্পাদনা করার আগে নিজের container-এ STATUS, RestartCount এবং OOMKilled পড়ুন।
2. যদি container কখনো বন্ধ না হয়ে থাকে, proxy upgrade header এবং idle timeout ঠিক করুন।
3. যদি OOMKilled সত্য হয়, আপনার প্রয়োজন অনুযায়ী নির্ধারিত একটি container limit সেট করুন, Node heap ceiling সেই সীমার নিচে রাখুন এবং binary data-এর জন্য filesystem ব্যবহার করুন।
4. কিছুই চালু না হলে, workflow সক্রিয় আছে কি না এবং instance-এর timezone আপনার timezone অনুযায়ী সেট করা আছে কি না যাচাই করুন।

এর অধিকাংশই একটি সচল install-এর ওপর করা একবারের configuration। আপনি যদি এখনও সেই install তৈরি করে থাকেন, HTTPS-সহ Docker-এ n8n চালানোর নির্দেশিকা-তে এই settings-এর ভিত্তি দেওয়া আছে।

FAQ

n8n-এর container চালু থাকা সত্ত্বেও editor-এ connection lost banner কেন দেখা যায়?

Execution-এর অগ্রগতি পাঠানোর জন্য editor একটি WebSocket খোলা রাখে। আপনার reverse proxy যদি Connection: Upgrade এবং Upgrade: websocket header forward না করে, অথবা upstream হিসেবে HTTP/1.1 ব্যবহার না করে, তাহলে upgrade সম্পূর্ণ হয় না। ফলে n8n সুস্থ অবস্থায় থাকলেও browser অনবরত reconnect করতে থাকে। nginx-এ proxy_http_version 1.1 এবং উভয় proxy_set_header line প্রয়োজন। পাশাপাশি, proxy_read_timeout-এর সময় default 60 seconds-এর চেয়ে বেশি হতে হবে, যাতে নিষ্ক্রিয় tab কেটে না যায়। আপনি যে file সম্পাদনা করেছেন সেটি নয়, চলমান configuration পরীক্ষা করতে sudo nginx -T ব্যবহার করুন।

Out of memory kill এবং সাধারণ crash-এর মধ্যে পার্থক্য কীভাবে বুঝব?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' চালিয়ে OOMKilled flag-এর মান দেখুন। মান True হলে memory limit অতিক্রম করায় kernel process-টি kill করেছে। সে ক্ষেত্রে container log-এ কার্যকর কোনো তথ্য নাও থাকতে পারে, কারণ process-টি লেখার সুযোগ পায়নি। docker logs-এর শেষে heap error এবং stack trace-সহ মান False হলে বুঝবেন Node.js নিজের V8 heap ceiling-এ পৌঁছে নিজে exit করেছে। আপনার container limit-এর নিচে NODE_OPTIONS=--max-old-space-size সেট করুন। তাহলে দ্বিতীয় ধরনের failure পাবেন, যেটি প্রমাণ রেখে যায়।

Execution data prune করলে কি সঙ্গে সঙ্গে disk space খালি হয়?

না। EXECUTIONS_DATA_PRUNE পুরোনো execution-গুলো deletion-এর জন্য চিহ্নিত করে। পরে EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL-এ নির্ধারিত schedule অনুযায়ী একটি pass সেগুলো সরায়। SQLite ব্যবহার করলে file-টি মুক্ত page filesystem-এ ফেরত না দিয়ে পুনরায় ব্যবহার করে। তাই row মুছে যাওয়ার পরও কিছু সময় disk-এর size অপরিবর্তিত থাকে। আপনার server-এর উপযোগী মানে EXECUTIONS_DATA_MAX_AGE এবং EXECUTIONS_DATA_PRUNE_MAX_COUNT সেট করুন। তারপর সঙ্গে সঙ্গে নয়, পরের দিন আবার পরীক্ষা করুন।

n8n restart হওয়ার সময় আমার scheduled workflow কেন চলেনি?

Process start হওয়ার সময় n8n trigger register করে। Process বন্ধ থাকা অবস্থায় যেসব schedule-এর সময় পেরিয়ে যায়, n8n সেগুলো পুনরায় চালায় না। তাই restart loop হলে একসঙ্গে অনেক catch-up run না হয়ে কোনো execution দেখা যায় না। Startup-এর পর পরবর্তী নির্ধারিত সময়ে পরের execution হয়। কোনো run বাদ দেওয়া যাবে না হলে webhook-এ request পাঠানো একটি external caller দিয়ে workflow চালান। এতে retry logic n8n-এর বাইরে থাকে।

n8n response দেওয়া বন্ধ করলে কি healthcheck সেটিকে restart করবে?

নিজে থেকে নয়। Compose healthcheck শুধু container-কে healthy বা unhealthy হিসেবে চিহ্নিত করে। Restart করার কাজটি restart policy-এর। তাই container exit করলে restart: unless-stopped সেটিকে আবার চালু করে। Docker service enabled থাকলে host reboot-এর পরও এটি container চালু করে। sudo systemctl is-enabled docker দিয়ে বিষয়টি নিশ্চিত করুন। শুধু unhealthy অবস্থার ভিত্তিতে ব্যবস্থা নিতে হলে Docker-এর বাইরে এমন একটি watcher প্রয়োজন, যা status পড়ে service restart করবে।