LiveContext کو self-host کرنے کا طریقہ اور لاگت

LiveContext کیا ہے، اور اسے چلانے کی لاگت کتنی ہے

LiveContext کو self-host کرنے کے لیے تقریباً 8 GB RAM والا VPS درکار ہے۔ LiveContext CE ایک open source automation platform ہے جو خود automation کے اندر AI agents چلاتا ہے۔ یہ Java backend پر مبنی چھ containers کے Docker Compose stack کے طور پر جاری کیا جاتا ہے۔ upstream README میں کم از کم 4 GB اور تجویز کردہ 8 GB RAM درکار بتائی گئی ہے، جبکہ compose file سے معلوم ہوتا ہے کہ یہ memory کہاں استعمال ہوتی ہے۔

یہ project GitHub پر livecontext-ai/livecontext-ce میں موجود ہے اور AGPL-3.0 کے تحت licensed ہے۔ August 2026 تک موجودہ release v0.2.11 ہے، جو 3 August 2026 کو published ہوئی۔ ہر image صرف linux/amd64 کے لیے build کی گئی ہے، اس لیے کم لاگت والے Arm plans استعمال نہیں کیے جا سکتے۔ اس guide میں اسی tag کو pin کیا گیا ہے، stack کو reverse proxy کے پیچھے رکھا گیا ہے، اور backup procedure شامل کیا گیا ہے جو upstream docs میں موجود نہیں۔

LiveContext کو self-host کرنے سے پہلے VPS کی گنجائش طے کریں

شپ کی گئی compose file میں ہر service کے لیے memory limit واضح طور پر مقرر ہے، اس لیے VPS کرائے پر لینے سے پہلے اس کی گنجائش طے کی جا سکتی ہے۔ یہ v0.2.11 compose file میں درج limits ہیں، ناپا گیا استعمال نہیں۔

[
  {
    "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
  }
]

صرف backend کی حد 1536 MB ہے۔ یہ حد Java 21 process پر لاگو ہوتی ہے، اس لیے JVM اس کا بیشتر حصہ استعمال کر کے اسی سطح پر رہتی ہے۔ پانچ base services کا مجموعی اضافہ 3 GB سے کچھ کم ہے، جبکہ frontend پر کوئی limit مقرر نہیں، اس لیے وہ Node کی طلب کے مطابق memory استعمال کرتا ہے۔ 4 GB VPS پر kernel اور page cache کے لیے تقریباً کچھ نہیں بچتا۔ اسی لیے 4 GB کو minimum لکھا گیا ہے، recommendation نہیں۔

اختیاری profiles ہی VPS کی ضرورت 8 GB تک بڑھاتے ہیں۔ browser agent profile ایک Chromium container شامل کرتا ہے جس کی حد 2048 MB ہے، اور اس کے ساتھ SearXNG search instance بھی چلتا ہے۔ renderer profile screenshots اور PDFs کے لیے مزید 1024 MB شامل کرتا ہے۔ دونوں profiles اس وقت تک start نہیں ہوتیں جب تک آپ انہیں enable نہ کریں، اس لیے ضرورت نہ ہو تو دونوں کو بند رکھیں۔ SearXNG container agent کے search backend کے طور پر کام کرتا ہے۔ اس سے واپس آنے والے صفحات آپ کے prompts میں untrusted text کے طور پر شامل ہوتے ہیں۔ یہی وہ trust boundary ہے جس کے ذریعے AI agent کو SearXNG web search دینا تفصیل سے کام کرتا ہے۔

اگر آپ پہلے سے n8n چلا رہے ہیں تو اسے ساتھ شامل کرنے کے بجائے تبدیل کرنے کا منصوبہ بنائیں۔ VPS پر Docker اور HTTPS کے ساتھ n8n چلانے کی ہماری guide میں ایک Node process، Postgres کے ساتھ چلتا ہے، اور یہ چھوٹے VPS پر آسانی سے چل جاتا ہے۔ LiveContext صرف اپنے backend کے لیے اس پورے stack سے زیادہ memory مختص کرتا ہے۔ ایک ہی 8 GB VPS پر دو automation platforms اس وقت تک چل جائیں گے جب تک دونوں ایک ہی منٹ میں job نہ چلائیں۔ اگر آپ ایک ہی host استعمال کریں تو باقی تمام services پر بھی واضح limits مقرر کریں۔ اس کے لیے Docker Compose میں memory limits مقرر کرنے والی ہماری post کا طریقہ استعمال کریں، تاکہ ایک بے قابو workflow پوری machine کو متاثر نہ کر سکے۔

Docker Compose کے ساتھ LiveContext انسٹال کریں اور اسے ایک tag پر مقرر رکھیں

ایک صاف Ubuntu 24.04 VPS سے آغاز کریں، جس پر Docker Engine 24 یا اس کے بعد کا ورژن اور Compose v2 موجود ہو۔ اگر Docker ابھی انسٹال نہیں ہے تو پہلے VPS کے لیے ہمارے Docker Compose basics پر عمل کریں، پھر یہاں واپس آئیں۔

README میں npx livecontext کو ایک سطری آغاز کے طور پر پیش کیا گیا ہے۔ لیپ ٹاپ پر یہ طریقہ مناسب ہے۔ سرور پر compose file ایسی directory میں رکھیں جسے آپ manage کرتے ہوں، کیونکہ اس صورت میں upgrade کے لیے 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 file میں ہر image پہلے ہی اس کے release tag پر مقرر ہے، مثلاً ghcr.io/livecontext-ai/livecontext-ce:v0.2.11۔ متعلقہ git tag کو checkout کرنے سے compose file اور images ہم آہنگ رہتی ہیں، کیونکہ v0.2.11 کے لیے compose file انہی images کو سامنے رکھ کر لکھی گئی تھی۔ tags کو latest پر تبدیل نہ کریں۔ latest tag آپ کی اجازت کے بغیر آگے بڑھ سکتا ہے، اور backend ہر start پر database migrations چلاتا ہے۔ اس لیے ایک accidental pull صبح 3 بجے آپ کا schema آگے منتقل کر سکتا ہے، جسے واپس لانے کا واحد طریقہ restore رہ جاتا ہے۔

پہلی بار start کرنے سے پہلے docker/.env.ce میں ترمیم کریں۔ اگلا section بتاتا ہے کہ کیا تبدیل کرنا ہے۔ اس کے بعد stack کو start کریں۔

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

اس guide میں ہر compose command کے ساتھ یہی --env-file flag استعمال کریں۔ Compose ہر invocation پر اس file کو دوبارہ پڑھتا ہے، اس لیے flag کے بغیر command compose file میں موجود defaults پر واپس چلی جاتی ہے اور آپ کی configured ports کے بجائے مختلف ports publish کر سکتی ہے۔

Backend healthcheck کا start_period 120s ہے اور یہ /actuator/health کو poll کرتا ہے۔ اس لیے docker compose ps تقریباً پہلے دو منٹ تک livecontext service کو health: starting ظاہر کرتا ہے، جبکہ schema migrations اور tool registration چل رہے ہوتے ہیں۔ یہ معمول کی بات ہے۔ سرور سے فوری جانچ:

curl -s localhost:8080/actuator/health

اس سے {"status":"UP"} print ہونا چاہیے۔ جب ایسا ہو جائے تو port 3000 پر web UI کھولیں۔ آپ جو پہلا account بناتے ہیں وہ admin بن جاتا ہے، اس لیے port کو کسی اور کے لیے قابل رسائی بنانے سے پہلے اپنا account بنائیں۔ پہلے دن port 3000 کو internet پر publish نہ کرنے کی یہی سب سے اہم وجہ ہے۔

وہ environment values جنہیں آپ کو تبدیل کرنا ضروری ہے

مثال کی فائل میں ایسے default values شامل ہیں جن سے stack لیپ ٹاپ پر شروع ہو جاتا ہے۔ ان میں سے کئی public server پر غیر محفوظ ہیں۔

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

ہر random value کو openssl rand -base64 32 کے ذریعے generate کریں۔ ان values کے متعلق اہم نکات یہ ہیں:

• POSTGRES_PASSWORD اور MINIO_ROOT_PASSWORD میں بالترتیب postgres اور minioadmin موجود ہوتے ہیں۔ دونوں database ports host پر publish نہیں کیے جاتے، اس لیے وہ براہِ راست exposed نہیں ہوتے۔ تاہم، بعد میں اسی network سے منسلک کیا جانے والا کوئی بھی container documented default کے ذریعے دونوں تک پہنچ سکتا ہے۔
• CREDENTIAL_ENCRYPTION_PASSWORD اور CREDENTIAL_ENCRYPTION_SALT خالی چھوڑنے پر خودکار طور پر generate ہوتے ہیں۔ اس کے بجائے انہیں خود set کریں۔ آپ کے workflows جن credentials کو محفوظ کرتے ہیں، وہ اسی جوڑے سے encrypted ہوتے ہیں۔ اس لیے نئے server پر restore کیے گئے database dump میں، اگر وہی password اور salt موجود نہ ہوں، تو credential rows کو decrypt نہیں کیا جا سکے گا۔ انہیں ایک بار set کریں، پھر docker/.env.ce کو backup کا حصہ سمجھیں۔
• FRONTEND_PORT اور BACKEND_PORT کو port mappings میں ${FRONTEND_PORT:-3000}:3000 اور ${BACKEND_PORT:-8080}:8080 کے طور پر substitute کیا جاتا ہے۔ مثال کی env فائل دونوں values واضح طور پر set کرتی ہے، اور اس میں موجود values ہمیشہ 3000 اور 8080 نہیں ہوتیں۔ فرض کرنے کے بجائے اپنی copy میں موجود values پڑھیں۔
• GATEWAY_PUBLIC_URL backend کا browser-facing origin ہے۔ reverse proxy استعمال ہوتے ہی یہ اہم ہو جاتا ہے۔ اگلے section میں دیکھیں۔
• model keys (ANTHROPIC_API_KEY، OPENAI_API_KEY، GOOGLE_API_KEY، اور اختیاری طور پر MISTRAL_API_KEY یا DEEPSEEK_API_KEY) یہاں plain text میں موجود ہوتی ہیں۔ صرف اسی provider کی key درج کریں جسے آپ واقعی استعمال کرتے ہیں۔

چھ containers کیا کام کرتے ہیں

• postgres، pgvector/pgvector:pg16 کو livecontext-db container کے طور پر چلاتا ہے اور livecontext نامی database رکھتا ہے۔ pgvector/pgvector:pg16 extension embedding search کے لیے موجود ہے، اس لیے سادہ postgres:16 image کافی نہیں ہوگی۔
• redis، redis:7-alpine کو appendonly yes اور --maxmemory-policy noeviction کے ساتھ چلاتا ہے۔ یہ policy جان بوجھ کر مقرر کی گئی ہے: یہاں Redis queue اور run state رکھتا ہے، اس لیے memory ceiling تک پہنچنے پر یہ keys کو خاموشی سے حذف کرنے کے بجائے writer کو error واپس کرتا ہے۔ ایسا error جسے آپ دیکھ سکیں، اس کام سے بہتر ہے جو غائب ہو جائے۔
• minio ان files کے لیے S3-compatible object store ہے جو workflows کے دوران منتقل ہوتی ہیں۔ ایک one-shot minio-init container startup کے وقت mc mb myminio/workflow-files --ignore-existing چلاتا ہے، bucket بناتا ہے، اور پھر exit ہو جاتا ہے۔ docker compose ps میں minio-init کو exited (0) کے طور پر دیکھنا healthy state ہے۔
• bridge CLI adapters اور MCP (model context protocol) tools رکھتا ہے۔ یہ Docker network کے اندر 8093 پر listen کرتا ہے اور host پر publish نہیں ہوتا۔
• livecontext backend ہے، یعنی port 8080 پر چلنے والا ایک Java 21 monolith۔ یہ workflow engine، schedulers اور agents چلاتا ہے۔
• frontend port 3000 پر Next.js web UI ہے۔ صرف یہی آخری دو containers host پر publish کیے جاتے ہیں۔

State پانچ named volumes میں محفوظ رہتی ہے: Postgres کے لیے livecontext_data، livecontext_redis، livecontext_minio، livecontext_keys، اور livecontext_logs۔ Compose ان کے نام کے شروع میں project name شامل کرتا ہے، جو default طور پر directory name ہوتا ہے، اس لیے disk پر اصل volume کا نام کچھ اس طرح ہوگا: livecontext-ce_livecontext_minio۔ docker volume ls چلائیں اور ان کے exact names copy کریں، پھر ان کے خلاف کوئی backup script لکھیں۔

docker compose down -v تمام پانچ volumes حذف کر دیتا ہے۔ دوبارہ شروع کرنے کا یہ documented طریقہ ہے، اور آپ کے بنائے ہوئے ہر workflow کو ضائع کرنے کا تیز ترین طریقہ بھی ہے۔ -v ہی پورا فرق ہے۔

اسے port 3000 شائع کرنے کے بجائے Traefik کے پیچھے چلائیں

public VPS پر ports 3000 اور 8080 شائع کرنے سے ایپ TLS (transport layer security) کے بغیر اور admin registration کے سامنے کسی حفاظتی دروازے کے بغیر دستیاب ہو جاتی ہے۔ ufw rule اکیلا کافی نہیں، کیونکہ Docker شائع شدہ ports کے لیے اپنی iptables rules اس chain سے پہلے داخل کرتا ہے جسے ufw manage کرتا ہے۔ اس لیے 0.0.0.0 پر شائع کیا گیا port اس وقت بھی قابل رسائی رہتا ہے جب ufw کے مطابق یہ port denied ہو۔

درست حل یہ ہے کہ کوئی port شائع نہ کریں اور proxy کو shared Docker network کے ذریعے containers تک پہنچنے دیں۔ repo root میں docker-compose.override.yml بنائیں:

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

networks:
  proxy:
    external: true

دو تفصیلات طے کرتی ہیں کہ یہ طریقہ کام کرے گا یا نہیں۔ !override ports list کو موجودہ list کے ساتھ merge کرنے کے بجائے replace کرتا ہے۔ اس کے لیے Compose v2.24 یا اس کے بعد کا ورژن درکار ہے۔ docker compose version سے جانچ کریں، کیونکہ پرانے Compose میں دونوں lists merge ہو جاتی ہیں اور ports شائع شدہ رہتے ہیں۔ اسی طرح default کو ہر networks list میں موجود رہنا چاہیے، کیونکہ کسی بھی network کا نام دینے سے default network replace ہو جاتا ہے۔ اسے چھوڑنے سے frontend کا Postgres اور Redis سے رابطہ منقطع ہو جاتا ہے۔ کچھ شروع کرنے سے پہلے merged نتیجے کی تصدیق کریں:

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

routers، certificate resolver اور HTTP سے HTTPS redirect کسی بھی دوسری ایپ جیسے ہی ہیں۔ اس لیے یہاں نئی TLS configuration لکھنے کے بجائے ایک VPS پر متعدد ایپس چلانے کے لیے ہماری Traefik reverse proxy گائیڈ پر عمل کریں۔ ایک hostname کو port 3000 پر frontend اور دوسرے hostname کو port 8080 پر livecontext تک route کریں۔

دوسرا hostname اختیاری نہیں ہے۔ web UI browser سے backend کو call کرتا ہے، اس لیے backend کو اپنا ایسا origin درکار ہوتا ہے جس تک browser پہنچ سکے۔ GATEWAY_PUBLIC_URL کو docker/.env.ce میں اس backend URL پر set کریں، مثلاً https://lc-api.example.com۔ اسے چھوڑنے پر page معمول کے مطابق load ہوتا ہے، لیکن ہر action ناکام ہو جاتا ہے، کیونکہ UI نے backend origin اس address سے حاصل کیا جسے آپ نے کھولا تھا اور اب ایسے port کو call کر رہا ہے جسے آپ کے proxy نے شائع نہیں کیا۔

چونکہ sign-up page پہلے پہنچنے والے ہر شخص کے لیے کھلا ہے، اس لیے frontend router پر forward auth لگانا مفید ہے۔ اس طرح proxy پر authentication کے بغیر کوئی شخص یہ page نہیں دیکھ سکے گا۔ یہی سہولت اپنی SSO layer کے طور پر Authentik چلانا اسی Traefik setup کے اوپر فراہم کرتی ہے۔

ماڈل key کہاں شامل ہوتی ہے، اور idle instance پر بھی خرچ کیوں آتا ہے

Agents یہاں automation کے اندر چلتے ہیں، اس لیے plain workflow tool کے مقابلے میں لاگت کا حساب مختلف ہوتا ہے۔ Provider key docker/.env.ce میں ANTHROPIC_API_KEY یا OPENAI_API_KEY کے طور پر رکھی جاتی ہے، startup کے وقت backend اور bridge اسے پڑھتے ہیں، اور یہ پوری instance پر لاگو ہوتی ہے۔ یہ ہر user کے لیے الگ محدود نہیں ہوتی۔ آپ کی instance پر account رکھنے والا ہر شخص، جو agent بنا سکتا ہے، اس key کو استعمال کر رہا ہوتا ہے، اور سب سے پہلے register کرنے والا شخص admin ہوتا ہے۔

تین عادتیں bill کو قابلِ پیش گوئی رکھتی ہیں۔ اس VPS کے لیے الگ provider key بنائیں تاکہ کسی اور چیز کو متاثر کیے بغیر اسے revoke کیا جا سکے۔ Provider console میں hard spend cap مقرر کریں، کیونکہ آپ جس machine کو secure کر رہے ہیں، اس کے باہر یہی واحد حد ہے۔ پھر LiveContext کی فراہم کردہ per-agent credit budgets اور per-agent metrics استعمال کریں، تاکہ آپ کے نوٹس میں آنے سے پہلے کوئی ایک loop پوری key ختم نہ کر دے۔

جب agent schedule پر چل رہا ہو تو idle cost صفر نہیں ہوتی۔ Schedule trigger اس وقت بھی fire ہوتا ہے جب کوئی اسے دیکھ نہیں رہا ہوتا، اور ہر firing tokens بھیجتی ہے۔ پانچ منٹ کا schedule روزانہ 288 runs ہوتا ہے، اور جو agent کوئی page پڑھ کر کچھ نہ کرنے کا فیصلہ کرے، اس page کو پڑھنے کی لاگت پھر بھی ادا کرنا پڑتی ہے۔ اپنے پہلے agents کو webhook یا chat trigger پر چلائیں، ایک ہفتے تک حقیقی خرچ monitor کریں، اور per-run cost معلوم ہونے کے بعد schedule استعمال کریں۔

Postgres اور object store کا backup لیں

یہاں دو data stores اور ایک secret ہے، اور ان میں سے کوئی بھی ضائع ہو جائے تو آپ کی instance ضائع ہو جاتی ہے۔ database اور bucket کا backup ایک ہی window میں لیں۔ اس دوران backend بند ہو، تاکہ اس کی database row dump ہونے کے بعد file نہ لکھی جا سکے۔

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 کی value تبدیل کی ہے تو postgres کی جگہ وہی value استعمال کریں۔ پھر object store volume کو copy کریں۔ اس کے لیے docker volume ls کی ظاہر کردہ prefix والی name استعمال کریں:

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)

اعتماد کرنے سے پہلے دیکھیں کہ dump خالی نہیں ہے: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 میں CREATE TABLE اور DROP TABLE statements نظر آنے چاہییں، صرف ایک سطری error نہیں۔ پھر تینوں files سرور سے باہر copy کریں۔ جو backup صرف اسی machine پر موجود ہو جسے وہ محفوظ کرتا ہے، وہ backup نہیں ہوتا۔

نئے box پر restore کرنے کے لیے وہی tag install کریں، محفوظ کیا ہوا docker/.env.ce واپس رکھیں تاکہ credential encryption password اور salt یکساں رہیں، stack کو ایک بار start کریں تاکہ volumes بن جائیں، backend کو stop کریں، پھر dump load کریں:

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 startup کے وقت اپنی schema migrations لاگو کرتا ہے، اور migrations صرف آگے بڑھتی ہیں۔ اس لیے خراب اپ گریڈ کے بعد پرانا tag checkout کرنے سے پرانا code نئی 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 پر set کریں جو تیسری command کے دکھائے گئے listing سے منتخب کیا تھا۔ backend log کو monitor کریں، یہاں تک کہ health endpoint دوبارہ جواب دینے لگے۔ آپ کا docker-compose.override.yml untracked ہے، اس لیے git checkout اسے اپنی جگہ رہنے دیتا ہے۔ تاہم tags کے درمیان docker-compose.yml کا diff ضرور پڑھیں، کیونکہ نئی service یا کسی service کا نیا نام آپ کے override کو بغیر کسی error message کے stale بنا سکتا ہے۔

ناکامی کی صورتیں اور نظر آنے والے strings

ایک container بار بار restart ہوتا ہے اور docker compose ps میں exited (137) دکھائی دیتا ہے۔ یہ kernel کا out-of-memory killer ہے، اور state block میں "OOMKilled": true کے ساتھ docker inspect livecontext-app اس کی تصدیق کرتا ہے۔ Backend اپنی 1536M limit تک پہنچ گیا ہے، یا host میں پہلے ہی memory ختم ہو گئی ہے۔ کوئی بھی limit بڑھانے سے پہلے free -m دیکھیں، کیونکہ ایسی host پر container limit بڑھانے سے جہاں اضافی memory موجود نہیں، kill صرف کسی دوسرے container کی طرف منتقل ہو جائے گا۔

Pull no matching manifest for linux/arm64/v8 in the manifest list entries کے ساتھ ناکام ہو جاتا ہے۔ Images صرف linux/amd64 کے لیے publish کی گئی ہیں۔ Arm VPS پر published images سے یہ stack نہیں چل سکتا، اور JVM کے ساتھ Chromium کے لیے QEMU کے ذریعے emulation بہت سست ہے۔ x86 plan استعمال کریں۔

Bind for 0.0.0.0:3000 failed: port is already allocated۔ Host پر کوئی دوسری چیز پہلے ہی اس port کو استعمال کر رہی ہے۔ docker/.env.ce میں FRONTEND_PORT تبدیل کریں، یا اوپر دیا گیا override لاگو کریں اور کچھ بھی publish نہ کریں۔

Proxy شامل کرنے کے بعد UI چل رہا ہے، لیکن login request ناکام ہو جاتی ہے۔ Browser backend کو ایسے origin پر call کر رہا ہے جسے آپ کا proxy serve نہیں کرتا۔ Browser کا network tab کھولیں اور ناکام request کا host دیکھیں۔ GATEWAY_PUBLIC_URL کو public backend URL پر set کریں اور frontend container دوبارہ create کریں، کیونکہ یہ value startup کے وقت پڑھی جاتی ہے۔

سب کچھ healthy ہے، لیکن workflow میں upload کی گئی files غائب ہو جاتی ہیں۔ تصدیق کریں کہ minio-init میں non-zero code کے بجائے exited (0) دکھائی دیتا ہے۔ اگر bucket workflow-files کبھی create ہی نہیں کیا گیا تو backend کے پاس objects رکھنے کی کوئی جگہ نہیں ہے۔

LiveContext یا n8n منتخب کریں

LiveContext اس وقت منتخب کریں جب agent مرکزی کردار ہو: آپ چاہتے ہیں کہ model automation تیار اور چلائے، اور اس مقصد کے لیے 8 GB کی machine اور Java service قابل قبول ہوں۔ n8n اس وقت منتخب کریں جب آپ deterministic workflows، nodes کی بڑی library، اور ایسا کم resource footprint چاہتے ہوں جو دیگر services کے ساتھ VPS پر چل سکے۔ یہاں دیے گئے version numbers ابھی نئے ہیں، v0.2.11 August 2026 تک؛ اس لیے اپنا tag pin کریں اور ہر upgrade سے پہلے release notes پڑھیں۔ وسیع تر منظرنامے کے لیے، جن tools میں ان دونوں کے درمیان کی خصوصیات شامل ہیں، صرف ان دونوں کا تقابلی جائزہ پڑھنے کے بجائے self-hosted n8n alternatives کا ہمارا جائزہ دیکھیں۔

FAQ

خود میزبانی والے LiveContext کو کتنی RAM درکار ہوتی ہے؟

8 GB کے لیے منصوبہ بنائیں۔ upstream README میں 4 GB کو کم از کم اور 8 GB کو تجویز کردہ مقدار بتایا گیا ہے، اور فراہم کردہ compose file بھی اسی سے مطابقت رکھتی ہے: صرف backend کی حد 1536 MB ہے، جبکہ پانچ بنیادی services مجموعی طور پر unlimited frontend container سے پہلے تقریباً 3 GB استعمال کرتی ہیں۔ browser agent profile فعال کرنے سے Chromium کے لیے مزید 2048 MB اور ایک SearXNG container شامل ہوتا ہے، اس لیے اس مرحلے پر 8 GB اختیاری نہیں رہتی۔

کیا میں Arm VPS پر LiveContext چلا سکتا ہوں؟

نہیں۔ ہر published image linux/amd64 کے لیے بنائی گئی ہے، اس لیے Arm plan پر docker compose up pull کے مرحلے میں no matching manifest for linux/arm64/v8 in the manifest list entries کے ساتھ ناکام ہو جاتی ہے۔ نظری طور پر اسے QEMU emulation کے تحت چلایا جا سکتا ہے، لیکن JVM workload کے لیے عملی طور پر یہ ناقابلِ استعمال ہے۔ x86 plan منتخب کریں۔

اپنی model API key کہاں رکھوں؟

پہلی بار start کرنے سے پہلے اسے docker/.env.ce میں ANTHROPIC_API_KEY، OPENAI_API_KEY یا GOOGLE_API_KEY کے طور پر رکھیں۔ backend اور bridge اسے startup کے وقت پڑھتے ہیں، اور یہ کسی ایک user کے بجائے پوری instance پر لاگو ہوتی ہے۔ file کا mode 600 رکھیں، ایسی key استعمال کریں جو صرف اس server کے لیے بنائی گئی ہو تاکہ اسے الگ سے revoke کیا جا سکے، اور provider console میں spend cap مقرر کریں، کیونکہ machine سے باہر نافذ ہونے والی واحد حد یہی cap ہے۔

LiveContext کا backup کیسے لوں؟

تین چیزیں درکار ہیں: livecontext database کا pg_dump، MinIO volume کی ایک copy، اور docker/.env.ce file۔ پہلی دو چیزیں لیتے وقت livecontext اور frontend services روک دیں، تاکہ database اور object store ایک دوسرے سے مطابقت رکھتے ہوں۔ env file اہم ہے، کیونکہ آپ کے workflows میں محفوظ credentials کو CREDENTIAL_ENCRYPTION_PASSWORD اور CREDENTIAL_ENCRYPTION_SALT کے ذریعے encrypt کیا جاتا ہے۔ ان values کے بغیر restore کرنے پر credential rows موجود رہیں گی، لیکن نئی machine پر کوئی چیز انہیں پڑھ نہیں سکے گی۔

boot کے بعد backend کئی منٹ تک health: starting پر کیوں رہتا ہے؟

compose healthcheck start_period: 120s set کرتا ہے اور /actuator/health کو poll کرتا ہے، اس لیے Docker schema migrations اور tool registration کے دوران service کو starting حالت میں دکھاتا ہے۔ پہلے boot پر 2 سے 3 منٹ لگنا معمول ہے۔ اگر یہ کبھی healthy نہ ہو، تو docker compose logs -f livecontext پڑھیں۔ جو stack migration step پر رک جائے، وہ عموماً ایسے database volume کی طرف اشارہ کر رہا ہوتا ہے جو کسی نئے release سے تعلق رکھتا ہے۔