LiveContext ను సొంతంగా హోస్ట్ చేయడం ఎలా?

LiveContext అంటే ఏమిటి మరియు దానిని నడపడానికి అయ్యే ఖర్చు

LiveContext ను self-host చేయడానికి మీకు సుమారు 8 GB RAM కలిగిన VPS అవసరం. LiveContext CE అనేది ఒక open source automation platform. ఇది automation లోపలే AI agents ను నడుపుతుంది. ఇది Java backend ఆధారంగా నిర్మించిన ఆరు containers కలిగిన Docker Compose stack గా విడుదలవుతుంది (ships). Upstream README ప్రకారం కనీసం 4 GB RAM అవసరం, కానీ 8 GB RAM సిఫార్సు చేయబడింది. ఆ మెమరీ ఎక్కడ వినియోగించబడుతుందో compose file చూపిస్తుంది.

ఈ ప్రాజెక్ట్ GitHub లో livecontext-ai/livecontext-ce వద్ద ఉంది మరియు AGPL-3.0 లైసెన్స్ కలిగి ఉంది. ఆగస్టు 2026 నాటికి ప్రస్తుత release v0.2.11, ఇది 3 ఆగస్టు 2026న ప్రచురించబడింది. ప్రతి image కేవలం linux/amd64 కోసం మాత్రమే నిర్మించబడింది, దీనివల్ల తక్కువ ధరలో లభించే Arm plans దీనికి పనికిరావు. ఈ గైడ్ ఆ tag ను pin చేస్తుంది, stack ను ఒక reverse proxy వెనుక ఉంచుతుంది మరియు upstream docs లో లేని backup విధానాన్ని వివరిస్తుంది.

LiveContext ను self-host చేసే ముందు VPS పరిమాణాన్ని నిర్ణయించడం

షిప్ చేసిన compose ఫైల్‌లోని ప్రతి సేవకు స్పష్టమైన మెమరీ పరిమితి ఉంటుంది, కాబట్టి మీరు VPS ను అద్దెకు తీసుకునే ముందే దాని పరిమాణాన్ని నిర్ణయించుకోవచ్చు. ఇవి 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
  }
]

backend మాత్రమే 1536 MB కి పరిమితం చేయబడింది. ఈ పరిమితి Java 21 ప్రాసెస్‌పై ఉంటుంది, కాబట్టి JVM అందులో ఎక్కువ భాగాన్ని ఆక్రమించి అలాగే ఉంటుంది. ఐదు బేస్ సేవలు కలిపి 3 GB కంటే కొంచెం తక్కువగా ఉంటాయి, మరియు frontend కు ఎటువంటి పరిమితి లేదు, కాబట్టి Node ఎంత అడిగితే అంత తీసుకుంటుంది. 4 GB VPS లో kernel మరియు page cache కోసం దాదాపు ఏమీ మిగలదు, అందుకే 4 GB ని సిఫార్సుగా కాకుండా కనిష్ట అవసరంగా పేర్కొన్నాము.

ఐచ్ఛిక ప్రొఫైల్‌లు (optional profiles) బాక్స్‌ను 8 GB కి పెంచుతాయి. browser agent ప్రొఫైల్, SearXNG సెర్చ్ ఇన్‌స్టెన్స్‌తో పాటు 2048 MB కి పరిమితం చేయబడిన Chromium కంటైనర్‌ను జోడిస్తుంది, మరియు renderer ప్రొఫైల్ స్క్రీన్‌షాట్‌లు మరియు PDFల కోసం మరో 1024 MB ని జోడిస్తుంది. మీరు ప్రొఫైల్‌ను enable చేసే వరకు ఏవీ ప్రారంభం కావు, కాబట్టి మీకు అవసరమయ్యే వరకు రెండింటినీ off లో ఉంచండి.

మీరు ఇప్పటికే n8n రన్ చేస్తుంటే, దానికి అదనంగా కాకుండా దానిని భర్తీ చేయాలని ప్లాన్ చేసుకోండి. Docker మరియు HTTPS తో VPS పై n8n రన్ చేయడంపై మా గైడ్ లోని స్టాక్, Postgres పక్కన ఒక Node ప్రాసెస్‌ను కలిగి ఉంటుంది మరియు ఇది చిన్న బాక్స్‌లో సౌకర్యవంతంగా ఉంటుంది. LiveContext మొత్తం ఆ స్టాక్ ఉపయోగించే దానికంటే ఎక్కువ మెమరీని కేవలం దాని backend కోసమే రిజర్వ్ చేస్తుంది. ఒకే 8 GB VPS పై రెండు ఆటోమేషన్ ప్లాట్‌ఫారమ్‌లు అప్పటికప్పుడు రన్ అయ్యే వరకు సరిపోతాయి, కానీ ఒకే నిమిషంలో రెండు పనులు (jobs) రన్ అయితే సమస్య రావచ్చు. మీరు ఒకే హోస్ట్‌ను పంచుకుంటే, Docker Compose లో మెమరీ పరిమితులను సెట్ చేయడంపై మా పోస్ట్ లోని పద్ధతిని ఉపయోగించి మిగిలిన అన్నింటికీ స్పష్టమైన పరిమితులను విధించండి, తద్వారా ఒక అదుపులేని వర్క్‌ఫ్లో మెషీన్‌ను డౌన్ చేయకుండా ఉంటుంది.

Docker Compose ఉపయోగించి LiveContext ఇన్‌స్టాలేషన్, ఒక నిర్దిష్ట ట్యాగ్‌కు పిన్ చేయడం

Docker Engine 24 లేదా అంతకంటే కొత్త వెర్షన్ మరియు Compose v2 ఉన్న క్లీన్ Ubuntu 24.04 VPS తో ప్రారంభించండి. ఒకవేళ Docker ఇంకా ఇన్‌స్టాల్ చేయకపోతే, ముందుగా మా Docker Compose బేసిక్స్ ఫర్ VPS గైడ్‌ను అనుసరించి, ఆపై తిరిగి రండి.

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 ఫైల్ ఇప్పటికే ప్రతి ఇమేజ్‌ను దాని release ట్యాగ్‌కు పిన్ చేస్తుంది, ఉదాహరణకు ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. సంబంధిత git ట్యాగ్‌ను చెక్ అవుట్ చేయడం ద్వారా compose ఫైల్ మరియు ఇమేజ్‌లు ఒకే క్రమంలో ఉంటాయి, ఎందుకంటే v0.2.11 కోసం ఉన్న compose ఫైల్ ఆ ఇమేజ్‌ల కోసమే రూపొందించబడింది. ట్యాగ్‌లను latest కి మార్చవద్దు. latest ట్యాగ్ ఎప్పటికప్పుడు మారుతూ ఉంటుంది, మరియు బ్యాకెండ్ ప్రతిసారి ప్రారంభమైనప్పుడు డేటాబేస్ మైగ్రేషన్లను రన్ చేస్తుంది. కాబట్టి, పొరపాటున pull చేస్తే మీ స్కీమా అప్‌డేట్ అయిపోవచ్చు, అప్పుడు బ్యాకప్ రీస్టోర్ చేయడం తప్ప వేరే మార్గం ఉండదు.

మొదటిసారి ప్రారంభించే ముందు 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 ఫైల్‌లో ఉన్న డిఫాల్ట్ సెట్టింగ్‌లకు తిరిగి వెళ్తుంది, దీనివల్ల మీరు కాన్ఫిగర్ చేసిన పోర్ట్‌లకు బదులుగా వేరే పోర్ట్‌లు పబ్లిష్ అయ్యే అవకాశం ఉంది.

బ్యాకెండ్ హెల్త్‌చెక్‌కు 120s start_period ఉంటుంది మరియు అది /actuator/health ని పోల్ చేస్తుంది. కాబట్టి, స్కీమా మైగ్రేషన్లు మరియు టూల్ రిజిస్ట్రేషన్ పూర్తయ్యే వరకు, సుమారు మొదటి రెండు నిమిషాల పాటు docker compose ps, livecontext సర్వీస్‌ను health: starting గా చూపిస్తుంది. ఇది సాధారణం. సర్వర్ నుండి ఒక చిన్న చెక్:

curl -s localhost:8080/actuator/health

ఇది {"status":"UP"} అని ప్రింట్ చేయాలి. అది వచ్చినప్పుడు, పోర్ట్ 3000 లో వెబ్ UI ని ఓపెన్ చేయండి. మీరు క్రియేట్ చేసే మొదటి అకౌంట్ అడ్మిన్ అవుతుంది, కాబట్టి ఇతరులకు ఈ పోర్ట్ అందుబాటులోకి రాకముందే మీ అకౌంట్‌ను క్రియేట్ చేసుకోండి. మొదటి రోజునే పోర్ట్ 3000 ని ఇంటర్నెట్‌కు పబ్లిష్ చేయకూడదనడానికి ఇదే అతి ముఖ్యమైన కారణం.

మీరు మార్చవలసిన env విలువలు

ఈ ఉదాహరణ ఫైల్ పని చేసే డిఫాల్ట్ విలువలతో వస్తుంది, కాబట్టి ఈ stack ఒక ల్యాప్‌టాప్‌పై ప్రారంభమవుతుంది. వీటిలో కొన్ని పబ్లిక్ సర్వర్‌పై సురక్షితం కావు.

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 విలువను openssl rand -base64 32 ఉపయోగించి రూపొందించండి. ఇబ్బంది కలిగించే వాటిపై గమనికలు:

• POSTGRES_PASSWORD మరియు MINIO_ROOT_PASSWORD లు postgres మరియు minioadmin గా వస్తాయి. ఏ database port కూడా హోస్ట్‌కు పబ్లిష్ చేయబడదు, కాబట్టి అవి నేరుగా బయటకు కనిపించవు. కానీ, మీరు తర్వాత అదే నెట్‌వర్క్‌కు అనుసంధానించే ఏ container అయినా డాక్యుమెంట్ చేయబడిన డిఫాల్ట్ విలువలతో వాటిని చేరుకోగలదు.
• CREDENTIAL_ENCRYPTION_PASSWORD మరియు CREDENTIAL_ENCRYPTION_SALT ఖాళీగా ఉంచినప్పుడు ఆటోమేటిక్‌గా జనరేట్ అవుతాయి. వాటిని మీరే సెట్ చేయండి. మీ workflows నిల్వ చేసే credentials ఆ జంటతో ఎన్‌క్రిప్ట్ చేయబడతాయి. కాబట్టి, అదే password మరియు salt లేకుండా కొత్త సర్వర్‌లో restore చేసిన database dump లోని credential అడ్డు వరుసలను ఏదీ చదవలేదు. వాటిని ఒకసారి సెట్ చేసి, ఆపై docker/.env.ce ను బ్యాకప్‌లో భాగంగా పరిగణించండి.
• FRONTEND_PORT మరియు BACKEND_PORT లు port mappings లో ${FRONTEND_PORT:-3000}:3000 మరియు ${BACKEND_PORT:-8080}:8080 గా ప్రతిక్షేపించబడతాయి. ఉదాహరణ env ఫైల్ రెండింటినీ స్పష్టంగా సెట్ చేస్తుంది, మరియు అందులో ఉండే విలువలు ఎల్లప్పుడూ 3000 మరియు 8080 కాకపోవచ్చు. ఊహించుకోకుండా మీ కాపీని చదవండి.
• GATEWAY_PUBLIC_URL అనేది backend యొక్క బ్రౌజర్-ఫేసింగ్ ఆరిజిన్. reverse proxy ఉన్నప్పుడు ఇది చాలా ముఖ్యం. తదుపరి విభాగాన్ని చూడండి.
• మోడల్ కీలు (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, మరియు ఐచ్ఛికంగా MISTRAL_API_KEY లేదా DEEPSEEK_API_KEY) ఇక్కడ plain text లో ఉంటాయి. మీరు వాస్తవానికి ఉపయోగించే ప్రొవైడర్‌ను మాత్రమే పూరించండి.

ఆరు కంటైనర్లు ఏమి చేస్తాయి

• postgres అనేది pgvector/pgvector:pg16 ను livecontext-db కంటైనర్‌గా నడుపుతుంది, ఇది livecontext అనే డేటాబేస్‌ను కలిగి ఉంటుంది. ఎంబెడ్డింగ్ సెర్చ్ కోసం ఇందులో pgvector ఎక్స్‌టెన్షన్ ఉంది, కాబట్టి సాధారణ postgres:16 ఇమేజ్ సరిపోదు.
• redis అనేది redis:7-alpine ను appendonly yes మరియు --maxmemory-policy noeviction తో నడుపుతుంది. ఈ పాలసీ ఉద్దేశపూర్వకమైనది: Redis ఇక్కడ క్యూ మరియు రన్ స్టేట్‌ను నిర్వహిస్తుంది, కాబట్టి ఇది మెమరీ పరిమితిని చేరుకున్నప్పుడు కీలను సైలెంట్‌గా తొలగించకుండా రైటర్‌కు ఎర్రర్‌ను పంపుతుంది. కనిపించే ఎర్రర్, మాయమైపోయే పని కంటే మెరుగైనది.
• minio అనేది వర్క్‌ఫ్లోల ద్వారా కదిలే ఫైళ్ల కోసం S3-అనుకూల ఆబ్జెక్ట్ స్టోర్. ఒక వన్-షాట్ minio-init కంటైనర్ స్టార్టప్‌లో mc mb myminio/workflow-files --ignore-existing ను రన్ చేసి, బకెట్‌ను సృష్టించి, ఆగిపోతుంది. docker compose ps లో minio-init ను exited (0) గా చూడటం ఆరోగ్యకరమైన స్థితి.
• bridge అనేది CLI అడాప్టర్లు మరియు MCP (మోడల్ కాంటెక్స్ట్ ప్రోటోకాల్) టూల్స్‌ను కలిగి ఉంటుంది. ఇది Docker నెట్‌వర్క్ లోపల 8093 పోర్ట్‌లో వింటుంది మరియు హోస్ట్‌కు పబ్లిష్ చేయబడదు.
• livecontext అనేది బ్యాకెండ్, ఇది 8080 పోర్ట్‌లో నడిచే ఒక Java 21 మోనోలిత్. ఇది వర్క్‌ఫ్లో ఇంజిన్, షెడ్యూలర్లు మరియు ఏజెంట్లను నడుపుతుంది.
• frontend అనేది 3000 పోర్ట్‌లో ఉండే Next.js వెబ్ UI. వీటిలో చివరి రెండు మాత్రమే హోస్ట్‌కు పబ్లిష్ చేయబడతాయి.

స్టేట్ ఐదు నేమ్డ్ వాల్యూమ్‌లలో ఉంటుంది: Postgres కోసం livecontext_data, మరియు livecontext_redis, livecontext_minio, livecontext_keys, livecontext_logs. Compose వీటి ముందు ప్రాజెక్ట్ పేరును చేరుస్తుంది, ఇది డిఫాల్ట్‌గా డైరెక్టరీ పేరుగా ఉంటుంది, కాబట్టి డిస్క్‌పై ఉన్న అసలు వాల్యూమ్ పేరు livecontext-ce_livecontext_minio వంటిదిగా ఉంటుంది. ఏదైనా బ్యాకప్ స్క్రిప్ట్ రాసే ముందు docker volume ls రన్ చేసి, ఖచ్చితమైన పేర్లను కాపీ చేసుకోండి.

docker compose down -v అనేది ఐదు వాల్యూమ్‌లను తొలగిస్తుంది. ఇది మళ్ళీ మొదటి నుండి ప్రారంభించడానికి డాక్యుమెంట్ చేయబడిన మార్గం, మరియు మీరు నిర్మించిన ప్రతి వర్క్‌ఫ్లోను కోల్పోవడానికి ఇది అత్యంత వేగవంతమైన మార్గం. -v అనేది మొత్తం వ్యత్యాసాన్ని కలిగిస్తుంది.

పోర్ట్ 3000ను పబ్లిష్ చేసే బదులు Traefik వెనుక ఉంచండి

పబ్లిక్ VPSలో పోర్ట్ 3000 మరియు 8080లను పబ్లిష్ చేయడం వల్ల, TLS (transport layer security) లేకుండా మరియు అడ్మిన్ రిజిస్ట్రేషన్ ముందు ఎటువంటి అడ్డుగోడ లేకుండా అప్లికేషన్ బయటపడుతుంది. కేవలం ఒక ufw నియమం సరిపోదు, ఎందుకంటే Docker పబ్లిష్ చేసిన పోర్ట్‌ల కోసం ufw నిర్వహించే chain కంటే ముందే దాని స్వంత iptables నియమాలను చేరుస్తుంది. కాబట్టి, ufw ద్వారా పోర్ట్ నిరాకరించబడినప్పటికీ, 0.0.0.0కి పబ్లిష్ చేసిన పోర్ట్ అందుబాటులోనే ఉంటుంది.

దీనికి సరైన పరిష్కారం ఏమిటంటే, దేనినీ పబ్లిష్ చేయకుండా, షేర్డ్ Docker నెట్‌వర్క్ ద్వారా proxy కంటైనర్‌లను చేరుకునేలా చేయడం. రిపోజిటరీ రూట్‌లో 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 వెర్షన్లలో రెండు జాబితాలు విలీనమై పోర్ట్‌లు పబ్లిష్ చేయబడతాయి. అలాగే, ప్రతి networks జాబితాలో default తప్పనిసరిగా ఉండాలి, ఎందుకంటే ఏదైనా నెట్‌వర్క్‌కు పేరు పెట్టడం వల్ల డిఫాల్ట్ నెట్‌వర్క్ భర్తీ చేయబడుతుంది, కాబట్టి దానిని వదిలేస్తే frontend కు Postgres మరియు Redis అందుబాటులో ఉండవు. ఏదైనా ప్రారంభించే ముందు విలీనం చేసిన ఫలితాన్ని నిర్ధారించుకోండి:

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

Routers, certificate resolver మరియు HTTP నుండి HTTPSకి మళ్లించే విధానం ఇతర అప్లికేషన్ల మాదిరిగానే ఉంటాయి, కాబట్టి కొత్త TLS కాన్ఫిగరేషన్‌ను ఇక్కడ రాసే బదులు ఒకే VPSలో అనేక అప్లికేషన్లను నడపడానికి మా Traefik reverse proxy గైడ్‌ను అనుసరించండి. ఒక hostnameను పోర్ట్ 3000లో ఉన్న frontendకి, రెండవ దానిని పోర్ట్ 8080లో ఉన్న livecontextకి route చేయండి.

రెండవ hostname తప్పనిసరి. వెబ్ UI బ్రౌజర్ నుండి backendని పిలుస్తుంది, కాబట్టి backendకు బ్రౌజర్ చేరుకోగల దాని స్వంత origin అవసరం. docker/.env.ceలో GATEWAY_PUBLIC_URLని ఆ backend URLకి సెట్ చేయండి, ఉదాహరణకు https://lc-api.example.com. దీన్ని విస్మరిస్తే, పేజీ సాధారణంగా లోడ్ అవుతుంది కానీ ప్రతి చర్య విఫలమవుతుంది, ఎందుకంటే UI మీరు తెరిచిన అడ్రస్ నుండి backend originని రిజాల్వ్ చేసుకుని, మీ proxy పబ్లిష్ చేయని పోర్ట్‌ను పిలుస్తుంది.

సైన్-అప్ పేజీ ఎవరైనా యాక్సెస్ చేసేలా ఉంటుంది కాబట్టి, frontend routerపై forward authని ఉంచడం మంచిది. దీనివల్ల proxy వద్ద authenticate అవ్వకుండా ఎవరూ ఆ పేజీని చూడలేరు. దీని కోసం Authentikని మీ స్వంత SSO లేయర్‌గా నడపడం అనే పద్ధతిని పైన పేర్కొన్న Traefik సెటప్‌కు జోడించవచ్చు.

మోడల్ కీని ఎక్కడ ఉంచాలి మరియు ఖాళీగా ఉన్న ఇన్‌స్టెన్స్ ఎందుకు ఖర్చుతో కూడుకున్నది

ఇక్కడ ఆటోమేషన్ లోపల ఏజెంట్లు నడుస్తాయి, ఇది సాధారణ వర్క్‌ఫ్లో టూల్‌తో పోలిస్తే ఆర్థికాంశాలను మారుస్తుంది. ప్రొవైడర్ కీ docker/.env.ce లో ANTHROPIC_API_KEY లేదా OPENAI_API_KEY గా ఉంటుంది, ఇది స్టార్టప్ సమయంలో బ్యాకెండ్ మరియు బ్రిడ్జ్ ద్వారా చదవబడుతుంది మరియు మొత్తం ఇన్‌స్టెన్స్‌కు వర్తిస్తుంది. ఇది ప్రతి వినియోగదారుకు విడిగా ఉండదు. మీ ఇన్‌స్టెన్స్‌లో ఖాతా కలిగి ఉండి, ఏజెంట్‌ను రూపొందించగలిగే ఎవరైనా ఆ కీని ఉపయోగిస్తారు, మరియు మొదట రిజిస్టర్ అయిన వ్యక్తి అడ్మిన్‌గా ఉంటారు.

మూడు అలవాట్లు బిల్లును అంచనా వేయదగినవిగా ఉంచుతాయి. ఈ VPS కోసం ప్రత్యేకమైన ప్రొవైడర్ కీని సృష్టించండి, తద్వారా మీరు దేనినీ ప్రభావితం చేయకుండానే దానిని రద్దు చేయవచ్చు. ప్రొవైడర్ కన్సోల్‌లో ఖర్చుపై గరిష్ట పరిమితిని (hard spend cap) సెట్ చేయండి, ఎందుకంటే మీరు భద్రపరిచే మెషీన్ వెలుపల ఉన్న ఏకైక పరిమితి అదే. ఆపై LiveContext అందించే ఏజెంట్-వారీ క్రెడిట్ బడ్జెట్‌లు మరియు ఏజెంట్-వారీ మెట్రిక్‌లను ఉపయోగించండి, తద్వారా ఒకే లూప్ మీరు గమనించేలోపే కీలోని బ్యాలెన్స్‌ను ఖాళీ చేయదు.

ఒక ఏజెంట్ షెడ్యూల్‌లో ఉన్నప్పుడు ఖాళీగా ఉన్నా (idle) ఖర్చు సున్నా కాదు. ఎవరైనా చూస్తున్నా లేదా చూడకపోయినా షెడ్యూల్ ట్రిగ్గర్ పనిచేస్తుంది మరియు ప్రతిసారీ టోకెన్‌లను వినియోగిస్తుంది. ఐదు నిమిషాల షెడ్యూల్ అంటే రోజుకు 288 రన్‌లు, మరియు ఒక పేజీని చదివి ఏమీ చేయకూడదని నిర్ణయించుకునే ఏజెంట్ కూడా ఆ పేజీని చదివినందుకు ఖర్చు చెల్లించాల్సి ఉంటుంది. మీ మొదటి ఏజెంట్లను వెబ్‌హుక్ (webhook) లేదా చాట్ ట్రిగ్గర్‌పై ఉంచండి, ఒక వారం పాటు అసలు ఖర్చును గమనించండి, ఆపై ప్రతి రన్‌కు అయ్యే ఖర్చు తెలిసిన తర్వాత షెడ్యూల్‌కు మారండి.

Postgres మరియు ఆబ్జెక్ట్ స్టోర్‌ను బ్యాకప్ చేయడం

ఇక్కడ రెండు డేటా స్టోర్లు మరియు ఒక రహస్య సమాచారం (secret) ఉంటాయి. వీటిలో ఏ ఒక్కటి పోయినా మీ instance కోల్పోతారు. డేటాబేస్ మరియు బకెట్‌ను ఒకే సమయంలో బ్యాకప్ తీసుకోండి. బ్యాకప్ తీసుకునేటప్పుడు backend ను ఆపివేయండి, తద్వారా డేటాబేస్ రో (row) డంప్ అయిన తర్వాత ఫైల్‌లో కొత్త మార్పులు జరగకుండా ఉంటాయి.

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

మీరు postgres ను మార్చినట్లయితే, దానికి బదులుగా మీరు DB_USERNAME గా సెట్ చేసిన దానిని ఉపయోగించండి. ఆ తర్వాత, 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 స్టేట్‌మెంట్‌లను చూపాలి, కేవలం ఒక లైన్ ఎర్రర్ మెసేజ్ రాకూడదు. ఆ తర్వాత, ఆ మూడు ఫైళ్లను సర్వర్ నుండి బయటకు కాపీ చేయండి. ఏ సర్వర్‌ను అయితే రక్షించాలో, అదే సర్వర్‌పై మాత్రమే ఉండే బ్యాకప్ నిజమైన బ్యాకప్ కాదు.

కొత్త సర్వర్‌పై రీస్టోర్ చేయడానికి, అదే tag ను ఇన్‌స్టాల్ చేయండి. సేవ్ చేసిన docker/.env.ce ను తిరిగి ఉంచండి, తద్వారా credential encryption పాస్‌వర్డ్ మరియు salt సరిపోలుతాయి. వాల్యూమ్‌లు సిద్ధం కావడానికి stack ను ఒకసారి ప్రారంభించి, ఆపై 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 తీసుకోండి. బ్యాకెండ్ స్టార్టప్ సమయంలో దాని schema migrations ను అమలు చేస్తుంది మరియు migrations కేవలం ముందుకు మాత్రమే వెళ్తాయి. కాబట్టి, అప్‌గ్రేడ్ విఫలమైన తర్వాత పాత tag కు మారితే, పాత కోడ్ కొత్త schema తో నడుస్తుంది. Rollback అంటే dump ను restore చేయడం, అందుకే 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 మళ్ళీ స్పందించే వరకు బ్యాకెండ్ log ను గమనించండి. మీ docker-compose.override.yml ట్రాక్ చేయబడదు, కాబట్టి git checkout దానిని అలాగే ఉంచుతుంది. అయితే, tags మధ్య docker-compose.yml లో ఉన్న diff ను చదవండి, ఎందుకంటే కొత్త సేవ లేదా పేరు మార్చబడిన సేవ మీ override ను ఎటువంటి error message లేకుండానే పాతదిగా (stale) మార్చవచ్చు.

వైఫల్య రీతులు మరియు మీరు చూసే సందేశాలు

ఒక కంటైనర్ పదేపదే రీస్టార్ట్ అవుతూ docker compose ps లో exited (137) అని చూపిస్తోంది. ఇది కెర్నల్ యొక్క out-of-memory killer చర్య. docker inspect livecontext-app కమాండ్ ద్వారా స్టేట్ బ్లాక్‌లో "OOMKilled": true అని ఉండటం దీన్ని నిర్ధారిస్తుంది. బ్యాకెండ్ తన 1536M పరిమితిని చేరుకుంది, లేదా హోస్ట్ మెమరీ పూర్తిగా అయిపోయింది. ఏదైనా పరిమితిని పెంచే ముందు free -m ని తనిఖీ చేయండి. ఎందుకంటే, ఖాళీ మెమరీ లేని హోస్ట్‌లో ఒక కంటైనర్ పరిమితిని పెంచడం వల్ల, ఆ కిల్లింగ్ ప్రక్రియ మరొక కంటైనర్‌కు మారుతుంది తప్ప సమస్య పరిష్కారం కాదు.

no matching manifest for linux/arm64/v8 in the manifest list entries తో ఇమేజ్ పుల్ (pull) విఫలమవుతోంది. ఈ ఇమేజ్‌లు కేవలం 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 ని మార్చండి, లేదా పైన పేర్కొన్న override ని వర్తింపజేసి ఏ పోర్ట్‌ను పబ్లిష్ చేయకండి.

UI పనిచేస్తోంది కానీ ప్రాక్సీని జోడించిన తర్వాత లాగిన్ అభ్యర్థన విఫలమవుతోంది. మీ ప్రాక్సీ సర్వ్ చేయని ఆరిజిన్ (origin) నుండి బ్రౌజర్ బ్యాకెండ్‌ను పిలుస్తోంది. బ్రౌజర్ నెట్‌వర్క్ ట్యాబ్‌ను తెరిచి, విఫలమవుతున్న అభ్యర్థన యొక్క హోస్ట్‌ను చూడండి. GATEWAY_PUBLIC_URL ని పబ్లిక్ బ్యాకెండ్ URLకి సెట్ చేసి, ఫ్రంటెండ్ కంటైనర్‌ను మళ్ళీ క్రియేట్ చేయండి. ఎందుకంటే ఆ విలువ స్టార్టప్ సమయంలోనే రీడ్ చేయబడుతుంది.

అన్నీ సక్రమంగా ఉన్నా, వర్క్‌ఫ్లోలో అప్‌లోడ్ చేసిన ఫైళ్లు కనిపించడం లేదు. minio-init లో నాన్-జీరో కోడ్ కాకుండా exited (0) అని ఉందో లేదో తనిఖీ చేయండి. ఒకవేళ workflow-files బకెట్ క్రియేట్ చేయబడకపోతే, ఆబ్జెక్ట్‌లను దాచడానికి బ్యాకెండ్‌కు ఎటువంటి స్థలం ఉండదు.

LiveContext లేదా n8n ఎంచుకోండి

ఏజెంట్ ప్రధానమైనప్పుడు LiveContext ఎంచుకోండి: మోడల్ ఆటోమేషన్‌ను నిర్మించి, రన్ చేయాలని మీరు కోరుకుంటే, మరియు 8 GB బాక్స్, Java సర్వీస్ వంటి అవసరాలను మీరు అంగీకరిస్తే ఇది సరైనది. మీకు నిర్ణయాత్మకమైన (deterministic) వర్క్‌ఫ్లోలు, పెద్ద నోడ్ లైబ్రరీ మరియు ఇతర సర్వీసులతో కలిసి VPSలో నడిచే తక్కువ footprint కావాలంటే n8n ఎంచుకోండి. ఇక్కడ ఉన్న వెర్షన్ నంబర్లు కొత్తవి, v0.2.11 ఆగస్టు 2026 నాటికి, కాబట్టి ప్రతి అప్‌గ్రేడ్‌కు ముందు మీ ట్యాగ్‌ను పిన్ చేయండి మరియు రిలీజ్ నోట్స్ చదవండి. ఈ రెండింటి మధ్య ఉండే ఇతర సాధనాలతో సహా విస్తృతమైన సమాచారం కోసం, కేవలం ఈ రెండింటి పోలికను మాత్రమే చూడకుండా మా self-hosted n8n ప్రత్యామ్నాయాల జాబితాను చూడండి.

FAQ

self-hosted LiveContext కు ఎంత RAM అవసరం?

8 GB కోసం ప్రణాళిక సిద్ధం చేసుకోండి. అప్‌స్ట్రీమ్ README లో కనీసం 4 GB మరియు సిఫార్సు చేసినది 8 GB అని పేర్కొన్నారు, అందించిన compose ఫైల్ కూడా దీనికి అనుగుణంగానే ఉంది: backend ఒక్కటే 1536 MB కి పరిమితం చేయబడింది, మరియు ఐదు బేస్ సర్వీసులు కలిపి 3 GB లోపు ఉంటాయి (unlimited frontend కంటైనర్ కాకుండా). బ్రౌజర్ ఏజెంట్ ప్రొఫైల్‌ను ఎనేబుల్ చేస్తే Chromium మరియు SearXNG కంటైనర్ కోసం అదనంగా 2048 MB అవసరమవుతుంది, కాబట్టి ఆ దశలో 8 GB తప్పనిసరి అవుతుంది.

నేను 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 కీని ఎక్కడ ఉంచాలి?

మొదటిసారి ప్రారంభించడానికి ముందే docker/.env.ce లో, ANTHROPIC_API_KEY, OPENAI_API_KEY లేదా GOOGLE_API_KEY గా ఉంచాలి. backend మరియు bridge వీటిని స్టార్టప్ సమయంలో చదువుతాయి, మరియు ఇది ఒక వినియోగదారుకు మాత్రమే కాకుండా మొత్తం instance కు వర్తిస్తుంది. ఫైల్‌ను 600 మోడ్‌లో ఉంచండి, ఈ సర్వర్ కోసం మాత్రమే సృష్టించిన కీని ఉపయోగించండి (తద్వారా అవసరమైతే దాన్ని మాత్రమే revoke చేయవచ్చు), మరియు ప్రొవైడర్ కన్సోల్‌లో ఖర్చు పరిమితిని (spend cap) సెట్ చేయండి, ఎందుకంటే ఆ పరిమితి మాత్రమే మెషీన్ వెలుపల ఉండే ఏకైక నియంత్రణ.

LiveContext ను బ్యాకప్ చేయడం ఎలా?

మూడు విషయాలు ముఖ్యం: livecontext డేటాబేస్ యొక్క pg_dump, MinIO వాల్యూమ్ యొక్క కాపీ, మరియు docker/.env.ce ఫైల్. మొదటి రెండింటిని తీసుకునేటప్పుడు livecontext మరియు frontend సర్వీసులను ఆపివేయండి, అప్పుడే డేటాబేస్ మరియు ఆబ్జెక్ట్ స్టోర్ ఒకదానితో ఒకటి సమన్వయంతో ఉంటాయి. env ఫైల్ ముఖ్యం ఎందుకంటే మీ వర్క్‌ఫ్లోలలో నిల్వ చేయబడిన క్రెడెన్షియల్స్ CREDENTIAL_ENCRYPTION_PASSWORD మరియు CREDENTIAL_ENCRYPTION_SALT తో ఎన్‌క్రిప్ట్ చేయబడతాయి, కాబట్టి ఆ విలువలు లేకుండా restore చేస్తే, కొత్త బాక్స్‌లో ఏదీ చదవలేని క్రెడెన్షియల్ రోస్ మిగిలిపోతాయి.

బూట్ అయిన తర్వాత backend ఎందుకు నిమిషాల పాటు health: starting వద్ద ఉంటుంది?

compose హెల్త్‌చెక్ start_period: 120s ని సెట్ చేసి /actuator/health ని పోల్ చేస్తుంది, కాబట్టి స్కీమా మైగ్రేషన్లు మరియు టూల్ రిజిస్ట్రేషన్ జరుగుతున్నప్పుడు Docker ఆ సర్వీస్‌ను starting స్థితిలో చూపిస్తుంది. మొదటి బూట్‌లో రెండు నుండి మూడు నిమిషాలు పట్టడం సాధారణం. అది ఎప్పటికీ healthy స్థితికి రాకపోతే, docker compose logs -f livecontext ని చదవండి. మైగ్రేషన్ దశలో ఆగిపోయే స్టాక్ సాధారణంగా కొత్త వెర్షన్ నుండి వచ్చిన డేటాబేస్ వాల్యూమ్‌ను సూచిస్తుంటుంది.