LiveContext কীভাবে নিজের সার্ভারে হোস্ট করবেন

LiveContext কী এবং এটি চালানোর খরচ

LiveContext নিজে হোস্ট করার জন্য আপনার প্রায় 8 GB RAM যুক্ত একটি VPS প্রয়োজন। LiveContext CE হলো একটি ওপেন সোর্স অটোমেশন প্ল্যাটফর্ম যা অটোমেশনের ভেতরেই AI এজেন্ট চালায়। এটি ছয়টি কন্টেইনারের একটি Docker Compose স্ট্যাক হিসেবে রিলিজ করা হয়, যা একটি Java ব্যাকএন্ডের ওপর ভিত্তি করে তৈরি। আপস্ট্রিম README-তে ন্যূনতম 4 GB এবং প্রস্তাবিত 8 GB RAM-এর কথা বলা হয়েছে, এবং compose ফাইলে দেখা যায় এই মেমোরি কোথায় ব্যবহৃত হয়।

প্রজেক্টটি GitHub-এ livecontext-ai/livecontext-ce-এ রয়েছে এবং এটি AGPL-3.0 লাইসেন্সের অধীনে প্রকাশিত। আগস্ট 2026 অনুযায়ী বর্তমান রিলিজ হলো v0.2.11, যা 3 August 2026 তারিখে প্রকাশিত হয়েছে। প্রতিটি ইমেজ শুধুমাত্র linux/amd64-এর জন্য তৈরি করা হয়েছে, যার ফলে সস্তা Arm প্ল্যানগুলো এখানে ব্যবহার করা সম্ভব নয়। এই নির্দেশিকাটি সেই নির্দিষ্ট ট্যাগটি ব্যবহার করে, স্ট্যাকটিকে একটি reverse proxy-এর পেছনে রাখে এবং ব্যাকআপ পদ্ধতিটি কভার করে যা আপস্ট্রিম ডকুমেন্টেশনে অন্তর্ভুক্ত নেই।

LiveContext self-host করার আগে VPS-এর আকার নির্ধারণ

shipped compose ফাইলে প্রতিটি সার্ভিসের জন্য সুনির্দিষ্ট মেমোরি লিমিট দেওয়া আছে, তাই সার্ভার ভাড়া করার আগেই আপনি প্রয়োজনীয় রিসোর্সের পরিমাণ বুঝতে পারবেন। এগুলো v0.2.11 compose ফাইলে লেখা লিমিট, কোনো পরিমাপকৃত ব্যবহার নয়।

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 1536
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "label": "postgres",
    "memory_limit_mb": 256
  },
  {
    "label": "minio",
    "memory_limit_mb": 256
  },
  {
    "label": "websearch (optional)",
    "memory_limit_mb": 2048
  },
  {
    "label": "searxng (optional)",
    "memory_limit_mb": 512
  },
  {
    "label": "renderer (optional)",
    "memory_limit_mb": 1024
  }
]

শুধুমাত্র ব্যাকএন্ডের জন্য 1536 MB লিমিট নির্ধারণ করা হয়েছে। এই লিমিটটি একটি Java 21 প্রসেসের ওপর কার্যকর, তাই JVM এর বেশিরভাগ অংশই দখল করে রাখবে। পাঁচটি বেস সার্ভিস মিলিয়ে মোট 3 GB-এর কিছুটা কম জায়গা নেয় এবং ফ্রন্টএন্ডের কোনো লিমিট নেই, তাই Node যতটুকু প্রয়োজন ততটুকুই ব্যবহার করবে। একটি 4 GB VPS-এ কার্নেল এবং পেজ ক্যাশের জন্য প্রায় কিছুই অবশিষ্ট থাকে না, যে কারণে 4 GB-কে সুপারিশ হিসেবে নয়, বরং ন্যূনতম প্রয়োজনীয়তা হিসেবে উল্লেখ করা হয়েছে।

ঐচ্ছিক প্রোফাইলগুলো ব্যবহার করলে সার্ভারের প্রয়োজনীয়তা 8 GB পর্যন্ত পৌঁছাতে পারে। ব্রাউজার এজেন্ট প্রোফাইলটি একটি Chromium কন্টেইনার যোগ করে যার লিমিট 2048 MB এবং এর সাথে একটি SearXNG সার্চ ইনস্ট্যান্স থাকে; এছাড়া রেন্ডারার প্রোফাইলটি স্ক্রিনশট এবং PDF-এর জন্য আরও 1024 MB যোগ করে। প্রোফাইলগুলো সক্রিয় না করলে এগুলো চালু হয় না, তাই প্রয়োজন না হওয়া পর্যন্ত উভয়ই বন্ধ রাখুন। SearXNG কন্টেইনারটি এজেন্টের সার্চ ব্যাকএন্ড হিসেবে কাজ করে, তাই এটি থেকে প্রাপ্ত পেজগুলো আপনার প্রম্পটে untrusted text হিসেবে আসে। এই ট্রাস্ট বাউন্ডারি নিয়ে AI এজেন্টকে SearXNG ওয়েব সার্চ ব্যবহারের সুবিধা দেওয়া অংশে বিস্তারিত আলোচনা করা হয়েছে।

আপনি যদি ইতিমধ্যে n8n ব্যবহার করে থাকেন, তবে সেটির সাথে নতুন কিছু যোগ করার চেয়ে বরং সেটিকে প্রতিস্থাপন করার পরিকল্পনা করুন। Docker এবং HTTPS ব্যবহার করে VPS-এ n8n চালানোর নির্দেশিকা-তে বর্ণিত স্ট্যাকটি Postgres-এর পাশে একটি মাত্র Node প্রসেস নিয়ে গঠিত, যা ছোট সার্ভারে অনায়াসেই চলে। LiveContext শুধুমাত্র তার ব্যাকএন্ডের জন্যই পুরো n8n স্ট্যাকের চেয়ে বেশি মেমোরি রিজার্ভ করে রাখে। একটি 8 GB VPS-এ দুটি অটোমেশন প্ল্যাটফর্ম ততক্ষণই ঠিকঠাক চলবে যতক্ষণ না তারা একই সময়ে কোনো কাজ শুরু করে। যদি একই হোস্ট শেয়ার করতেই হয়, তবে Docker Compose-এ মেমোরি লিমিট নির্ধারণ বিষয়ক আমাদের পোস্ট-এর পদ্ধতি অনুসরণ করে অন্য সবকিছুর ওপর সুনির্দিষ্ট লিমিট বসিয়ে দিন, যাতে কোনো একটি অনিয়ন্ত্রিত ওয়ার্কফ্লো পুরো মেশিনকে অচল করে দিতে না পারে।

Docker Compose ব্যবহার করে LiveContext ইনস্টল করা, একটি নির্দিষ্ট ট্যাগ পিন করে

একটি পরিষ্কার Ubuntu 24.04 VPS থেকে শুরু করুন যেখানে Docker Engine 24 বা তার নতুন সংস্করণ এবং Compose v2 ইনস্টল করা আছে। যদি Docker এখনো ইনস্টল করা না থাকে, তবে প্রথমে আমাদের VPS-এর জন্য Docker Compose বেসিক অনুসরণ করুন এবং তারপর এখানে ফিরে আসুন।

README-তে npx livecontext-কে এক লাইনের স্টার্ট কমান্ড হিসেবে দেওয়া হয়েছে। ল্যাপটপের জন্য এটি ঠিক আছে। কিন্তু সার্ভারের ক্ষেত্রে আপনি চাইবেন compose ফাইলটি আপনার নিয়ন্ত্রিত একটি ডিরেক্টরিতে থাকুক, কারণ এতে আপগ্রেড করা মানে হলো একটি git checkout করা এবং আপনি স্পষ্টভাবে দেখতে পাবেন কী পরিবর্তন হয়েছে।

sudo apt update && sudo apt install -y git
git clone https://github.com/livecontext-ai/livecontext-ce.git
cd livecontext-ce
git tag --list 'v*' | tail -5
git checkout v0.2.11
cp docker/.env.ce.example docker/.env.ce
chmod 600 docker/.env.ce

compose ফাইলটিতে প্রতিটি ইমেজকে তার রিলিজ ট্যাগের সাথে পিন করা থাকে, উদাহরণস্বরূপ ghcr.io/livecontext-ai/livecontext-ce:v0.2.11। সংশ্লিষ্ট git ট্যাগ চেকআউট করাই হলো compose ফাইল এবং ইমেজগুলোকে সামঞ্জস্যপূর্ণ রাখার উপায়, কারণ v0.2.11-এর জন্য compose ফাইলটি সেই ইমেজগুলোর ওপর ভিত্তি করেই লেখা হয়েছিল। ট্যাগগুলোকে latest-এ পরিবর্তন করবেন না। একটি latest ট্যাগ আপনার অজান্তেই পরিবর্তিত হতে পারে এবং backend প্রতিবার স্টার্ট হওয়ার সময় তার ডাটাবেস মাইগ্রেশন চালায়, তাই ভুলবশত একটি pull আপনার স্কিমা পরিবর্তন করে ফেলতে পারে, যা রাত 3টার দিকে ঘটলে ব্যাকআপ রিস্টোর করা ছাড়া আর কোনো উপায় থাকবে না।

প্রথমবার স্টার্ট করার আগে docker/.env.ce এডিট করুন (পরের সেকশনে কী পরিবর্তন করতে হবে তার তালিকা দেওয়া আছে), তারপর স্ট্যাকটি চালু করুন।

docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce ps

এই গাইডের প্রতিটি compose কমান্ডে একই --env-file ফ্ল্যাগ ব্যবহার করুন। Compose প্রতিবার কমান্ড দেওয়ার সময় ফাইলটি নতুন করে পড়ে, তাই ফ্ল্যাগ ছাড়া কোনো কমান্ড দিলে তা compose ফাইলের ডিফল্ট সেটিংসে ফিরে যায় এবং আপনার কনফিগার করা পোর্টগুলোর পরিবর্তে ভিন্ন পোর্ট পাবলিশ করতে পারে।

backend হেলথচেক-এ 120 সেকেন্ডের একটি start_period থাকে এবং এটি /actuator/health পোল করে, তাই স্কিমা মাইগ্রেশন এবং টুল রেজিস্ট্রেশন চলাকালীন প্রথম দুই মিনিট docker compose ps সার্ভিসটিকে livecontext হিসেবে health: starting রিপোর্ট করে। এটি স্বাভাবিক। সার্ভার থেকে একটি দ্রুত চেক:

curl -s localhost:8080/actuator/health

এটি {"status":"UP"} প্রিন্ট করবে। যখন এটি দেখাবে, তখন পোর্ট 3000-এ ওয়েব UI খুলুন। আপনি যে প্রথম অ্যাকাউন্টটি তৈরি করবেন সেটিই অ্যাডমিন হবে, তাই অন্য কেউ পোর্টটি পাওয়ার আগেই আপনার অ্যাকাউন্ট তৈরি করে নিন। প্রথম দিনেই পোর্ট 3000 ইন্টারনেটে উন্মুক্ত না করার এটিই সবচেয়ে গুরুত্বপূর্ণ কারণ।

যেসব env ভ্যালু আপনাকে পরিবর্তন করতে হবে

উদাহরণ ফাইলটিতে ডিফল্ট সেটিংস দেওয়া থাকে যাতে স্ট্যাকটি ল্যাপটপে চালু করা যায়। পাবলিক সার্ভারে এগুলোর বেশ কয়েকটি অনিরাপদ।

POSTGRES_PASSWORD=<random>
MINIO_ROOT_USER=<not minioadmin>
MINIO_ROOT_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_SALT=<random>
ANTHROPIC_API_KEY=sk-ant-...
FRONTEND_PORT=3000
BACKEND_PORT=8080
GATEWAY_PUBLIC_URL=https://lc-api.example.com

প্রতিটি র‍্যান্ডম ভ্যালু openssl rand -base64 32 দিয়ে তৈরি করুন। যেসব বিষয় খেয়াল রাখা জরুরি:

• POSTGRES_PASSWORD এবং MINIO_ROOT_PASSWORD ডিফল্টভাবে postgres এবং minioadmin হিসেবে থাকে। কোনো ডাটাবেস পোর্টই হোস্টের জন্য উন্মুক্ত (publish) করা নেই, তাই এগুলো সরাসরি এক্সপোজ হয় না। তবে একই নেটওয়ার্কে পরবর্তীতে যুক্ত করা যেকোনো কন্টেইনার ডকুমেন্টেশনে থাকা ডিফল্ট ভ্যালু ব্যবহার করে এগুলোতে পৌঁছাতে পারবে।
• CREDENTIAL_ENCRYPTION_PASSWORD এবং CREDENTIAL_ENCRYPTION_SALT খালি রাখলে স্বয়ংক্রিয়ভাবে তৈরি হয়। এর পরিবর্তে এগুলো নিজে সেট করুন। আপনার ওয়ার্কফ্লোতে সংরক্ষিত ক্রেডেনশিয়ালগুলো এই জোড়া দিয়ে এনক্রিপ্ট করা থাকে। তাই একই পাসওয়ার্ড এবং সল্ট ছাড়া নতুন কোনো সার্ভারে ডাটাবেস ডাম্প রিস্টোর করলে ক্রেডেনশিয়াল রো-গুলো পড়া সম্ভব হবে না। এগুলো একবার সেট করুন এবং docker/.env.ce-কে ব্যাকআপের অংশ হিসেবে গণ্য করুন।
• FRONTEND_PORT এবং BACKEND_PORT পোর্ট ম্যাপিংয়ে ${FRONTEND_PORT:-3000}:3000 এবং ${BACKEND_PORT:-8080}:8080 হিসেবে ব্যবহৃত হয়। উদাহরণ env ফাইলে উভয়ই স্পষ্টভাবে সেট করা থাকে এবং এর ভ্যালু সবসময় 3000 বা 8080 হয় না। তাই অনুমান না করে আপনার কপিটি পড়ুন।
• GATEWAY_PUBLIC_URL হলো ব্রাউজার-ফেসিং ব্যাকএন্ড অরিজিন। রিভার্স প্রক্সি ব্যবহারের ক্ষেত্রে এটি গুরুত্বপূর্ণ। পরবর্তী সেকশনটি দেখুন।
• মডেল কিগুলো (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY এবং ঐচ্ছিকভাবে MISTRAL_API_KEY বা DEEPSEEK_API_KEY) এখানে প্লেইন টেক্সট হিসেবে থাকে। শুধুমাত্র যে প্রোভাইডারটি আপনি ব্যবহার করছেন তার কিগুলো পূরণ করুন।

ছয়টি কন্টেইনার যা করে

• postgres কন্টেইনার livecontext-db হিসেবে pgvector/pgvector:pg16 চালায়, যেখানে livecontext নামের ডেটাবেসটি থাকে। এমবেডিং সার্চের জন্য এতে pgvector এক্সটেনশনটি রয়েছে, তাই সাধারণ postgres:16 ইমেজ এখানে কাজ করবে না।
• redis কন্টেইনারটি appendonly yes এবং --maxmemory-policy noeviction সহ redis:7-alpine চালায়। এই পলিসিটি ইচ্ছাকৃতভাবে করা হয়েছে: Redis এখানে কিউ এবং রান স্টেট বহন করে, তাই এটি যখন তার মেমোরি সীমাতে পৌঁছায়, তখন এটি সাইলেন্টলি কি (key) মুছে ফেলার পরিবর্তে রাইটারকে একটি এরর প্রদান করে। কাজ হারিয়ে যাওয়ার চেয়ে এরর দেখা অনেক ভালো।
• minio হলো S3-সামঞ্জস্যপূর্ণ অবজেক্ট স্টোর, যা ওয়ার্কফ্লোর ফাইলগুলো আদান-প্রদান করে। একটি ওয়ান-শট minio-init কন্টেইনার স্টার্টআপের সময় mc mb myminio/workflow-files --ignore-existing চালায়, বাকেট তৈরি করে এবং তারপর বন্ধ হয়ে যায়। docker compose ps-এ minio-init-কে exited (0) হিসেবে দেখা হলো সুস্থ অবস্থার লক্ষণ।
• bridge-এ CLI অ্যাডাপ্টার এবং MCP (model context protocol) টুলগুলো থাকে। এটি ডকার নেটওয়ার্কের ভেতরে 8093 পোর্টে লিসেন করে এবং হোস্টের জন্য উন্মুক্ত নয়।
• livecontext হলো ব্যাকএন্ড, যা 8080 পোর্টে একটি Java 21 মনোলিথ হিসেবে চলে। এটি ওয়ার্কফ্লো ইঞ্জিন, শিডিউলার এবং এজেন্টগুলো পরিচালনা করে।
• frontend হলো 3000 পোর্টের Next.js ওয়েব UI। শুধুমাত্র এই শেষ দুটি কন্টেইনার হোস্টের জন্য উন্মুক্ত।

স্টেট পাঁচটি নেমড ভলিউমে থাকে: Postgres-এর জন্য livecontext_data, এবং livecontext_redis, livecontext_minio, livecontext_keys ও livecontext_logs। কম্পোজ এগুলোর শুরুতে প্রজেক্টের নাম যুক্ত করে, যা ডিফল্টভাবে ডিরেক্টরির নাম হয়, তাই ডিস্কে থাকা প্রকৃত ভলিউমের নাম livecontext-ce_livecontext_minio-এর মতো হয়। কোনো ব্যাকআপ স্ক্রিপ্ট লেখার আগে docker volume ls চালিয়ে সঠিক নামগুলো কপি করে নিন।

docker compose down -v পাঁচটি ভলিউমই মুছে ফেলে। এটি নতুন করে শুরু করার নথিভুক্ত উপায়, তবে এটি আপনার তৈরি করা সমস্ত ওয়ার্কফ্লো হারানোর দ্রুততম উপায়ও বটে। -v-ই হলো এই দুটির মধ্যে মূল পার্থক্য।

পোর্ট 3000 পাবলিশ না করে Traefik-এর পেছনে রাখুন

একটি পাবলিক VPS-এ 3000 এবং 8080 পোর্ট পাবলিশ করলে অ্যাপটি TLS (transport layer security) ছাড়াই উন্মুক্ত হয়ে যায় এবং অ্যাডমিন রেজিস্ট্রেশনের সামনে কোনো সুরক্ষা স্তর থাকে না। শুধুমাত্র একটি ufw রুল যথেষ্ট নয়, কারণ Docker পাবলিশ করা পোর্টের জন্য নিজস্ব iptables রুল তৈরি করে যা ufw-এর নিয়ন্ত্রিত চেইনের আগেই থাকে। ফলে, ufw-তে পোর্টটি ডিনাই করা থাকলেও 0.0.0.0-এ পাবলিশ করা পোর্টটি অ্যাক্সেসযোগ্য থেকে যায়।

এর সঠিক সমাধান হলো কোনো পোর্ট পাবলিশ না করা এবং একটি শেয়ারড Docker নেটওয়ার্কের মাধ্যমে প্রক্সিকে কন্টেইনারগুলোর সাথে যোগাযোগ করতে দেওয়া। রিপোজিটরির রুটে docker-compose.override.yml তৈরি করুন:

services:
  frontend:
    ports: !override []
    networks:
      - default
      - proxy
  livecontext:
    ports: !override []
    networks:
      - default
      - proxy

networks:
  proxy:
    external: true

এই পদ্ধতিটি কাজ করবে কি না তা দুটি বিষয়ের ওপর নির্ভর করে। !override পোর্ট লিস্টের সাথে মার্জ না হয়ে সেটিকে প্রতিস্থাপন করে, যার জন্য Compose v2.24 বা তার নতুন সংস্করণ প্রয়োজন: docker compose version চালিয়ে এটি চেক করুন, কারণ পুরনো Compose ভার্সনে দুটি লিস্ট মার্জ হয়ে যায় এবং পোর্টগুলো পাবলিশড থেকে যায়। এছাড়া default-কে অবশ্যই প্রতিটি networks লিস্টে রাখতে হবে, কারণ যেকোনো নেটওয়ার্কের নাম উল্লেখ করলে তা ডিফল্ট নেটওয়ার্ককে সরিয়ে দেয়; ফলে এটি বাদ দিলে ফ্রন্টএন্ড Postgres এবং Redis থেকে বিচ্ছিন্ন হয়ে যাবে। কোনো কিছু শুরু করার আগে মার্জড রেজাল্ট নিশ্চিত করুন:

docker compose --env-file docker/.env.ce config

রাউটার, সার্টিফিকেট রিজলভার এবং HTTP থেকে HTTPS রিডাইরেক্ট অন্য যেকোনো অ্যাপের মতোই, তাই নতুন TLS কনফিগারেশন না লিখে একটি VPS-এ একাধিক অ্যাপ চালানোর জন্য আমাদের Traefik reverse proxy গাইড অনুসরণ করুন। একটি হোস্টনামকে 3000 পোর্টে frontend-এর দিকে এবং দ্বিতীয়টিকে 8080 পোর্টে livecontext-এর দিকে রাউট করুন।

দ্বিতীয় হোস্টনামটি ঐচ্ছিক নয়। ওয়েব UI ব্রাউজার থেকে ব্যাকএন্ডকে কল করে, তাই ব্যাকএন্ডের নিজস্ব একটি অরিজিন প্রয়োজন যা ব্রাউজার রিচ করতে পারে। docker/.env.ce-এ GATEWAY_PUBLIC_URL-কে সেই ব্যাকএন্ড URL-এ সেট করুন, উদাহরণস্বরূপ https://lc-api.example.com। এটি বাদ দিলে পেজটি স্বাভাবিকভাবে লোড হলেও প্রতিটি অ্যাকশন ব্যর্থ হবে, কারণ UI আপনার ওপেন করা অ্যাড্রেস থেকেই ব্যাকএন্ড অরিজিন রিজলভ করে এবং এমন একটি পোর্টে কল করে যা আপনার প্রক্সি পাবলিশ করেনি।

যেহেতু সাইন-আপ পেজটি যে কেউ অ্যাক্সেস করতে পারে, তাই ফ্রন্টএন্ড রাউটারে ফরওয়ার্ড অথ (forward auth) ব্যবহার করা বুদ্ধিমানের কাজ। এতে প্রক্সিতে অথেন্টিকেট না হওয়া পর্যন্ত কেউ সেই পেজটি দেখতে পাবে না, যা আপনার নিজস্ব SSO লেয়ার হিসেবে Authentik চালানো সেটআপের মাধ্যমে একই Traefik কনফিগারেশনে যোগ করা যায়।

মডেল কি (key) কোথায় থাকে এবং কেন অলস ইনস্ট্যান্সের জন্য খরচ হয়

এখানে অটোমেশনের ভেতরে এজেন্টগুলো চলে, যা সাধারণ ওয়ার্কফ্লো টুলের তুলনায় এর অর্থনৈতিক কাঠামোকে ভিন্ন করে তোলে। প্রোভাইডার কি (provider key) docker/.env.ce-এ ANTHROPIC_API_KEY অথবা OPENAI_API_KEY হিসেবে থাকে, যা স্টার্টআপের সময় ব্যাকএন্ড এবং ব্রিজ দ্বারা পঠিত হয় এবং পুরো ইনস্ট্যান্সের ওপর কার্যকর হয়। এটি ব্যবহারকারী অনুযায়ী সীমাবদ্ধ নয়। আপনার ইনস্ট্যান্সে যার অ্যাকাউন্ট আছে এবং যে এজেন্ট তৈরি করতে পারে, সে এই কি (key) ব্যবহার করে খরচ করছে এবং প্রথম যে ব্যক্তি রেজিস্ট্রেশন করে সে-ই অ্যাডমিন হিসেবে গণ্য হয়।

তিনটি অভ্যাস খরচকে নিয়ন্ত্রণে রাখে। এই VPS-এর জন্য একটি আলাদা প্রোভাইডার কি তৈরি করুন, যাতে অন্য কোনো কিছুতে প্রভাব না ফেলেই আপনি এটি বাতিল করতে পারেন। প্রোভাইডার কনসোলে একটি নির্দিষ্ট খরচের সীমা (spend cap) নির্ধারণ করুন, কারণ মেশিনের বাইরে এটিই একমাত্র সুরক্ষা কবচ। এরপর LiveContext-এর প্রতি-এজেন্ট ক্রেডিট বাজেট এবং প্রতি-এজেন্ট মেট্রিক্স ব্যবহার করুন, যাতে আপনার নজরে আসার আগেই কোনো একটি লুপ পুরো কি (key)-এর ব্যালেন্স শেষ করতে না পারে।

এজেন্ট একবার শিডিউলে সেট হয়ে গেলে অলস অবস্থায়ও খরচ শূন্য হয় না। কেউ দেখুক বা না দেখুক, শিডিউল ট্রিগার কাজ করে এবং প্রতিটি ট্রিগার টোকেন খরচ করে। পাঁচ মিনিটের একটি শিডিউল মানে দিনে 288 বার রান করা, এবং একটি এজেন্ট যদি কোনো পেজ পড়ে সিদ্ধান্ত নেয় যে কিছু করার নেই, তবুও সেই পেজ পড়ার জন্য খরচ হয়। আপনার প্রথম এজেন্টগুলোকে ওয়েবহুক (webhook) বা চ্যাট ট্রিগারের ওপর রাখুন, এক সপ্তাহ প্রকৃত খরচ পর্যবেক্ষণ করুন এবং প্রতি-রান খরচ সম্পর্কে নিশ্চিত হওয়ার পর শিডিউলে স্থানান্তর করুন।

Postgres এবং অবজেক্ট স্টোর ব্যাকআপ নিন

এখানে দুটি ডেটা স্টোর এবং একটি সিক্রেট রয়েছে, যার যেকোনো একটি হারিয়ে গেলে আপনার ইনস্ট্যান্সটি অকেজো হয়ে যাবে। ডেটাবেস এবং বাকেট একই সময়ে ব্যাকআপ নিন এবং এই সময় ব্যাকআপের কাজ সম্পন্ন না হওয়া পর্যন্ত backend বন্ধ রাখুন, যাতে ডেটাবেস রো ডাম্প করার পর নতুন কোনো ফাইল লেখা না হয়।

cd ~/livecontext-ce
mkdir -p ~/backups
docker compose --env-file docker/.env.ce stop livecontext frontend
docker compose --env-file docker/.env.ce exec -T postgres \
  pg_dump -U postgres -d livecontext --clean --if-exists \
  | gzip > ~/backups/livecontext-db-$(date +%F).sql.gz

আপনি যদি DB_USERNAME পরিবর্তন করে থাকেন, তবে postgres-এর পরিবর্তে সেটি ব্যবহার করুন। এরপর docker volume ls যে প্রিফিক্সড নাম দেখিয়েছে তা ব্যবহার করে অবজেক্ট স্টোর ভলিউমটি কপি করুন:

docker run --rm \
  -v livecontext-ce_livecontext_minio:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-minio-$(date +%F).tgz -C /data .
docker compose --env-file docker/.env.ce start livecontext frontend
cp docker/.env.ce ~/backups/env.ce.$(date +%F)

ডাম্প ফাইলটি বিশ্বাস করার আগে নিশ্চিত করুন যে এটি খালি নয়: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 কমান্ডটি চালালে সেখানে CREATE TABLE এবং DROP TABLE স্টেটমেন্টগুলো দেখা উচিত, কোনো এক লাইনের এরর মেসেজ নয়। এরপর তিনটি ফাইলই সার্ভার থেকে বাইরে কপি করে নিন। যে মেশিনের ডেটা ব্যাকআপ নেওয়া হচ্ছে, সেই একই মেশিনে ব্যাকআপ ফাইল রাখা কোনো কার্যকর ব্যাকআপ পদ্ধতি নয়।

একটি নতুন সার্ভারে রিস্টোর করার জন্য, একই ট্যাগ ইনস্টল করুন, সংরক্ষিত docker/.env.ce ফাইলটি যথাস্থানে রাখুন যাতে ক্রেডেনশিয়াল এনক্রিপশন পাসওয়ার্ড এবং সল্ট মিলে যায়। এরপর স্ট্যাকটি একবার চালু করুন যাতে ভলিউমগুলো তৈরি হয়, তারপর backend বন্ধ করে ডাম্প ফাইলটি লোড করুন:

gunzip -c livecontext-db-2026-08-10.sql.gz \
  | docker compose --env-file docker/.env.ce exec -T postgres psql -U postgres -d livecontext

আপগ্রেড এবং কোনো সমস্যা হলে পূর্বের অবস্থায় ফিরে আসা

প্রতিবার কাজ শুরুর আগে অবশ্যই একটি dump নিয়ে নিন। backend স্টার্টআপের সময় তার schema migration প্রয়োগ করে এবং এই migration শুধুমাত্র সামনের দিকেই অগ্রসর হয়। তাই একটি ব্যর্থ আপগ্রেডের পর পুরনো tag-এ ফিরে গেলে নতুন schema-এর বিপরীতে পুরনো কোড চলতে থাকে। rollback করার অর্থ হলো dump থেকে ডেটা পুনরুদ্ধার করা, আর এজন্যই dump নেওয়াটা সবার আগে জরুরি।

cd ~/livecontext-ce
git fetch --tags
git tag --list 'v*' | tail -5
TAG=v0.2.11
git checkout "$TAG"
docker compose --env-file docker/.env.ce pull
docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce logs -f livecontext

তৃতীয় কমান্ডটি যে তালিকা প্রিন্ট করেছে, সেখান থেকে আপনার বেছে নেওয়া tag-টি TAG-এ সেট করুন। health endpoint পুনরায় সাড়া না দেওয়া পর্যন্ত backend লগ পর্যবেক্ষণ করুন। আপনার docker-compose.override.yml ফাইলটি untracked, তাই git checkout কমান্ডটি চালালে এটি আগের জায়গাতেই থেকে যাবে। তবে tag-গুলোর মধ্যে docker-compose.yml-এর diff অবশ্যই পড়ে দেখুন, কারণ নতুন কোনো service বা নাম পরিবর্তন করা service আপনার override-কে কোনো error message ছাড়াই অকেজো করে দিতে পারে।

ব্যর্থতার ধরন এবং যে বার্তাগুলো আপনি দেখবেন

একটি কন্টেইনার বারবার রিস্টার্ট হচ্ছে এবং docker compose ps-এ exited (137) দেখাচ্ছে। এটি কার্নেলের out-of-memory killer, এবং docker inspect livecontext-app নিশ্চিত করে যে state ব্লকে "OOMKilled": true রয়েছে। ব্যাকএন্ড তার 1536M সীমা অতিক্রম করেছে, অথবা হোস্টের মেমরি শেষ হয়ে গেছে। কোনো সীমা বাড়ানোর আগে free -m পরীক্ষা করুন, কারণ পর্যাপ্ত মেমরি না থাকলে কন্টেইনারের সীমা বাড়ালে তা কেবল অন্য কোনো কন্টেইনারের ওপর প্রভাব ফেলবে।

পুল করার সময় no matching manifest for linux/arm64/v8 in the manifest list entries ত্রুটি দেখাচ্ছে। ইমেজগুলো শুধুমাত্র linux/amd64-এর জন্য প্রকাশ করা হয়েছে। একটি Arm VPS এই প্রকাশিত ইমেজগুলো থেকে স্ট্যাকটি চালাতে পারবে না, এবং QEMU-এর মাধ্যমে এমুলেশন JVM ও Chromium-এর জন্য অত্যন্ত ধীরগতির। একটি x86 প্ল্যানে স্থানান্তর করুন।

Bind for 0.0.0.0:3000 failed: port is already allocated। হোস্টের অন্য কোনো সার্ভিস ইতিমধ্যে সেই পোর্টটি ব্যবহার করছে। docker/.env.ce-এ FRONTEND_PORT পরিবর্তন করুন, অথবা উপরের ওভাররাইড প্রয়োগ করুন এবং কোনো পোর্ট পাবলিশ করবেন না।

UI সচল আছে কিন্তু প্রক্সি যোগ করার পর লগইন অনুরোধ ব্যর্থ হচ্ছে। ব্রাউজার এমন একটি অরিজিনে ব্যাকএন্ডকে কল করছে যা আপনার প্রক্সি সার্ভ করে না। ব্রাউজারের নেটওয়ার্ক ট্যাব খুলুন এবং ব্যর্থ হওয়া অনুরোধের হোস্টটি দেখুন। GATEWAY_PUBLIC_URL-কে পাবলিক ব্যাকএন্ড URL-এ সেট করুন এবং ফ্রন্টএন্ড কন্টেইনারটি পুনরায় তৈরি করুন, কারণ এই মানটি স্টার্টআপের সময় পড়া হয়।

সবকিছু ঠিকঠাক আছে কিন্তু ওয়ার্কফ্লোতে আপলোড করা ফাইলগুলো হারিয়ে যাচ্ছে। পরীক্ষা করে দেখুন minio-init-এ নন-জিরো কোডের পরিবর্তে exited (0) দেখাচ্ছে কি না। যদি workflow-files বাকেটটি তৈরি করা না হয়ে থাকে, তবে ব্যাকএন্ডের অবজেক্ট রাখার কোনো জায়গা নেই।

LiveContext অথবা n8n বেছে নিন

যখন এজেন্টই মূল বিষয় হয় তখন LiveContext বেছে নিন: আপনি চান মডেলটি অটোমেশন তৈরি ও পরিচালনা করুক এবং এর বিনিময়ে আপনি 8 জিবি র‍্যামের সার্ভার ও একটি Java সার্ভিস ব্যবহার করতে রাজি আছেন। যখন আপনি সুনির্দিষ্ট (deterministic) ওয়ার্কফ্লো, বিশাল নোড লাইব্রেরি এবং এমন একটি ফুটপ্রিন্ট চান যা অন্যান্য সার্ভিসের সাথে একই VPS শেয়ার করতে পারে, তখন n8n বেছে নিন। 2026 সালের আগস্ট মাস অনুযায়ী v0.2.11 এই ভার্সন নম্বরগুলো নতুন, তাই প্রতিটি আপগ্রেডের আগে আপনার ট্যাগ পিন করুন এবং রিলিজ নোটগুলো পড়ুন। এই দুই অবস্থানের মাঝামাঝি থাকা টুলগুলোসহ বৃহত্তর পরিসরের জন্য, শুধুমাত্র এই দুটির তুলনা না পড়ে আমাদের self-hosted n8n বিকল্পগুলোর তালিকা দেখুন।

FAQ

LiveContext চালানোর জন্য কতটুকু RAM প্রয়োজন?

8 GB RAM রাখার পরিকল্পনা করুন। আপস্ট্রিম README-তে সর্বনিম্ন 4 GB এবং প্রস্তাবিত 8 GB RAM-এর কথা বলা হয়েছে, এবং প্রদত্ত compose ফাইলে সেটিই অনুসরণ করা হয়েছে: শুধুমাত্র backend-এর জন্য 1536 MB সীমা নির্ধারণ করা আছে এবং পাঁচটি বেস সার্ভিস মিলে 3 GB-এর কিছুটা কম জায়গা নেয়, যার সাথে আনলিমিটেড frontend কন্টেইনার যুক্ত থাকে। ব্রাউজার এজেন্ট প্রোফাইল সক্রিয় করলে Chromium এবং SearXNG কন্টেইনারের জন্য আরও 2048 MB RAM প্রয়োজন হয়, তাই সেই পর্যায়ে 8 GB RAM থাকা বাধ্যতামূলক হয়ে পড়ে।

আমি কি Arm VPS-এ LiveContext চালাতে পারব?

না। প্রতিটি প্রকাশিত ইমেজ linux/amd64-এর জন্য তৈরি করা হয়েছে, তাই Arm প্ল্যানে docker compose up চালালে no matching manifest for linux/arm64/v8 in the manifest list entries এর কারণে pull ব্যর্থ হবে। তাত্ত্বিকভাবে QEMU ইমুলেশন ব্যবহার করে এটি চালানো সম্ভব হলেও, JVM ওয়ার্কলোডের ক্ষেত্রে এটি ব্যবহারযোগ্য নয়। তাই x86 প্ল্যান বেছে নিন।

আমার মডেল API key কোথায় রাখব?

প্রথমবার চালু করার আগে docker/.env.ce ফাইলে, ANTHROPIC_API_KEY, OPENAI_API_KEY অথবা GOOGLE_API_KEY হিসেবে এটি রাখুন। backend এবং bridge স্টার্টআপের সময় এটি পড়ে নেয় এবং এটি কোনো নির্দিষ্ট ব্যবহারকারীর পরিবর্তে পুরো ইনস্ট্যান্সের জন্য কার্যকর হয়। ফাইলটির মোড 600 রাখুন, শুধুমাত্র এই সার্ভারের জন্য তৈরি করা একটি key ব্যবহার করুন যাতে প্রয়োজনে সেটি আলাদাভাবে বাতিল করা যায় এবং প্রোভাইডার কনসোলে একটি খরচের সীমা (spend cap) নির্ধারণ করুন, কারণ মেশিনের বাইরে এটিই একমাত্র কার্যকর সীমা।

আমি কীভাবে LiveContext-এর ব্যাকআপ নেব?

তিনটি বিষয়: livecontext ডাটাবেসের একটি pg_dump, MinIO ভলিউমের একটি কপি এবং docker/.env.ce ফাইল। প্রথম দুটি ব্যাকআপ নেওয়ার সময় livecontext এবং frontend সার্ভিসগুলো বন্ধ রাখুন যাতে ডাটাবেস এবং অবজেক্ট স্টোর একে অপরের সাথে সামঞ্জস্যপূর্ণ থাকে। env ফাইলটি গুরুত্বপূর্ণ কারণ আপনার ওয়ার্কফ্লোতে সংরক্ষিত ক্রেডেনশিয়ালগুলো CREDENTIAL_ENCRYPTION_PASSWORD এবং CREDENTIAL_ENCRYPTION_SALT দিয়ে এনক্রিপ্ট করা থাকে; তাই এই ভ্যালুগুলো ছাড়া রিস্টোর করলে ক্রেডেনশিয়াল রো-গুলো নতুন বক্সে পড়া সম্ভব হবে না।

বুট হওয়ার পর backend কেন কয়েক মিনিট health: starting অবস্থায় থাকে?

compose হেলথচেক start_period: 120s সেট করে এবং /actuator/health পোল করে, তাই স্কিমা মাইগ্রেশন এবং টুল রেজিস্ট্রেশন চলাকালীন Docker সার্ভিসটিকে starting হিসেবে দেখায়। প্রথমবার বুট হওয়ার সময় দুই থেকে তিন মিনিট সময় লাগা স্বাভাবিক। যদি এটি কখনোই healthy অবস্থায় না আসে, তবে docker compose logs -f livecontext পড়ুন। যে স্ট্যাক মাইগ্রেশন ধাপে আটকে থাকে, সেটি সাধারণত নতুন কোনো রিলিজের ডাটাবেস ভলিউমের দিকে নির্দেশ করা থাকে।