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 license के अंतर्गत है। अगस्त 2026 तक का वर्तमान release v0.2.11 है, जिसे 3 अगस्त 2026 को प्रकाशित किया गया था। प्रत्येक image केवल linux/amd64 के लिए build की गई है, जो सस्ते Arm plans को बाहर कर देता है। यह guide उस tag को pin करती है, stack को reverse proxy के पीछे रखती है, और backup प्रक्रिया को कवर करती है जिसे upstream docs में शामिल नहीं किया गया है।

LiveContext को self-host करने से पहले VPS का आकार निर्धारित करें

shipped compose file में प्रत्येक service के लिए एक स्पष्ट memory limit दी गई है, ताकि आप VPS किराए पर लेने से पहले उसका आकार तय कर सकें। ये सीमाएं v0.2.11 compose file में लिखी गई हैं, न कि मापा गया उपयोग।

[
  {
    "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 पर कोई सीमा नहीं है, इसलिए वह उतना ही उपयोग करता है जितना Node मांगता है। 4 GB के VPS पर kernel और page cache के लिए लगभग कुछ नहीं बचता है, इसीलिए 4 GB को अनुशंसा के बजाय न्यूनतम आवश्यकता के रूप में लिखा गया है।

वैकल्पिक profiles ही VPS को 8 GB तक ले जाती हैं। Browser agent profile में एक Chromium container जुड़ता है जिसकी सीमा 2048 MB है, जो एक SearXNG search instance के साथ चलता है, और renderer profile screenshots तथा PDFs के लिए अतिरिक्त 1024 MB जोड़ता है। जब तक आप इनका profile enable नहीं करते, ये start नहीं होते, इसलिए जब तक आवश्यकता न हो, दोनों को off रखें। वह SearXNG container agent के search backend के रूप में कार्य करता है, इसलिए इसके द्वारा लौटाए गए pages आपके prompts में untrusted text के रूप में आते हैं। यह वही trust boundary है जिसे AI agent को SearXNG web search देना में विस्तार से समझाया गया है।

यदि आप पहले से ही n8n चला रहे हैं, तो उसे इसमें जोड़ने के बजाय बदलने की योजना बनाएं। Docker और HTTPS के साथ VPS पर n8n चलाने के लिए हमारी मार्गदर्शिका में दिया गया stack एक Postgres के साथ एक Node process है, जो एक छोटे VPS पर आसानी से चलता है। LiveContext केवल अपने backend के लिए ही उस पूरे stack से अधिक memory आरक्षित करता है। एक ही 8 GB VPS पर दो automation platforms तब तक ठीक चलेंगे जब तक कि दोनों एक ही मिनट में कोई job न चलाएं। यदि आप एक ही host साझा करते हैं, तो Docker Compose में memory limits सेट करने पर हमारी पोस्ट में दी गई विधि का उपयोग करके अन्य सभी चीजों पर भी स्पष्ट सीमाएं लगाएं, ताकि कोई एक अनियंत्रित workflow पूरी machine को down न कर सके।

Docker Compose के साथ LiveContext इंस्टॉल करें, एक विशिष्ट tag पर पिन करें

एक साफ-सुथरे 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 फाइल पहले से ही हर image को उसके release tag पर पिन करती है, उदाहरण के लिए ghcr.io/livecontext-ai/livecontext-ce:v0.2.11। मेल खाते git tag को checkout करना ही वह तरीका है जिससे compose फाइल और images तालमेल में रहती हैं, क्योंकि v0.2.11 के लिए compose फाइल उन images के आधार पर ही लिखी गई थी। tags को latest में न बदलें। एक latest tag आपके नियंत्रण के बिना बदल सकता है, और backend हर start पर अपने database migrations चलाता है, इसलिए एक अनपेक्षित pull आपके schema को रात के 3 बजे आगे बढ़ा सकता है, जिसे restore के अलावा वापस लाने का कोई तरीका नहीं होगा।

पहली बार start करने से पहले docker/.env.ce को edit करें (अगला सेक्शन बताता है कि क्या बदलना है), फिर stack को up करें।

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

इस गाइड में हर compose कमांड पर उसी --env-file flag का उपयोग करें। Compose हर बार बुलाए जाने पर उस फाइल को नए सिरे से पढ़ता है, इसलिए बिना flag वाली कमांड compose फाइल में मौजूद defaults पर वापस चली जाती है और आपके द्वारा कॉन्फ़िगर किए गए ports के बजाय अलग ports पब्लिश कर सकती है।

Backend healthcheck का start_period 120s का है और यह /actuator/health को poll करता है, इसलिए docker compose ps लगभग पहले दो मिनट तक livecontext सर्विस को health: starting के रूप में रिपोर्ट करेगा, जब तक कि schema migrations और tool registration चल रहे होते हैं। यह सामान्य है। सर्वर से एक त्वरित जांच:

curl -s localhost:8080/actuator/health

इसे {"status":"UP"} प्रिंट करना चाहिए। जब यह हो जाए, तो port 3000 पर web UI खोलें। आपके द्वारा बनाया गया पहला अकाउंट admin बन जाता है, इसलिए अपना अकाउंट तब बनाएं जब port किसी और के लिए सुलभ न हो। यही एकमात्र सबसे महत्वपूर्ण कारण है कि पहले दिन port 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 के साथ आते हैं। कोई भी डेटाबेस पोर्ट होस्ट पर पब्लिश नहीं होता है, इसलिए वे सीधे एक्सपोज़ नहीं होते हैं, लेकिन बाद में उसी नेटवर्क से जुड़ने वाला कोई भी कंटेनर दस्तावेज़ में दिए गए डिफ़ॉल्ट मानों के साथ उन तक पहुँच सकता है।
• यदि 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 यहाँ कतार (queue) और रन स्टेट को संभालता है, इसलिए जब यह अपनी मेमोरी सीमा तक पहुँचता है, तो यह चुपचाप कीज़ (keys) को हटाने के बजाय राइटर को एक एरर भेजता है। काम के गायब हो जाने से बेहतर है कि आपको एरर दिखाई दे।
• minio उन फाइलों के लिए S3-संगत ऑब्जेक्ट स्टोर है जो वर्कफ़्लो के माध्यम से मूव होती हैं। एक वन-शॉट minio-init कंटेनर स्टार्टअप पर mc mb myminio/workflow-files --ignore-existing चलाता है, बकेट बनाता है और फिर बंद हो जाता है। docker compose ps में exited (0) के रूप में minio-init को देखना एक स्वस्थ स्थिति है।
• 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 पब्लिश किए गए पोर्ट्स के लिए अपने स्वयं के iptables नियम ufw द्वारा प्रबंधित चेन से पहले डाल देता है। इसलिए, 0.0.0.0 पर पब्लिश किया गया पोर्ट तब भी पहुंच योग्य रहता है जब ufw कहता है कि पोर्ट डिनाइड है।

इसका सही समाधान यह है कि कुछ भी पब्लिश न करें और प्रॉक्सी को साझा 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 सेटअप के ऊपर जोड़ता है।

मॉडल की (model key) कहाँ रखी जाती है, और एक idle instance के लिए पैसे क्यों देने पड़ते हैं

Agents यहाँ automation के भीतर चलते हैं, जो एक साधारण workflow tool की तुलना में इसके economics को बदल देता है। Provider key docker/.env.ce में ANTHROPIC_API_KEY या OPENAI_API_KEY के रूप में रखी जाती है, जिसे startup के समय backend और bridge द्वारा पढ़ा जाता है, और यह पूरे instance पर लागू होती है। यह प्रति-उपयोगकर्ता (per-user) सीमित नहीं है। आपके instance पर जिस किसी के पास भी account है और जो agent बना सकता है, वह उस key का उपयोग कर रहा है, और register करने वाला पहला व्यक्ति admin होता है।

तीन आदतें बिल को अनुमानित रखती हैं। इस VPS के लिए एक अलग provider key बनाएँ ताकि आप किसी और चीज़ को प्रभावित किए बिना इसे revoke कर सकें। Provider console में एक hard spend cap सेट करें, क्योंकि मशीन के बाहर केवल वही एक सीमा है जिसे आप सुरक्षित कर रहे हैं। इसके बाद, LiveContext द्वारा प्रदान किए गए per-agent credit budgets और per-agent metrics का उपयोग करें, ताकि कोई एक loop आपके ध्यान में आने से पहले ही key का balance खत्म न कर दे।

एक बार जब कोई agent schedule पर सेट हो जाता है, तो idle cost शून्य नहीं रहती। Schedule trigger चाहे कोई उसे देख रहा हो या न हो, fire होता है, और हर बार fire होने पर tokens खर्च होते हैं। पाँच मिनट का schedule दिन में 288 बार चलता है, और एक agent जो केवल एक page पढ़ता है और कुछ न करने का निर्णय लेता है, वह भी उस page को पढ़ने के लिए भुगतान करता है। अपने पहले agents को webhook या chat trigger पर रखें, एक सप्ताह तक वास्तविक खर्च पर नज़र रखें, और प्रति-run लागत जानने के बाद ही schedule पर जाएँ।

Postgres और object store का बैकअप लें

इसमें दो डेटा स्टोर और एक secret शामिल हैं। इनमें से किसी एक के भी खोने का मतलब है आपकी पूरी instance का खो जाना। डेटाबेस और bucket का बैकअप एक ही समय पर लें, और इस दौरान 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

यदि आपने DB_USERNAME को बदला है, तो postgres की जगह उसका उपयोग करें। इसके बाद, docker volume ls द्वारा प्रिंट किए गए prefixed नाम का उपयोग करके object store volume को कॉपी करें:

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 statements दिखने चाहिए, न कि केवल एक लाइन की error। इसके बाद तीनों फाइलों को सर्वर से बाहर कहीं और कॉपी करें। जो बैकअप केवल उसी मशीन पर मौजूद है जिसकी वह सुरक्षा कर रहा है, वह वास्तव में बैकअप नहीं है।

किसी नए सर्वर पर restore करने के लिए, वही tag install करें, सहेजे गए docker/.env.ce को वापस रखें ताकि credential encryption password और salt मेल खा सकें, stack को एक बार start करें ताकि volumes बन जाएँ, 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 migrations लागू करता है और migrations केवल आगे बढ़ते हैं, इसलिए खराब अपग्रेड के बाद पुराने tag पर जाने से नया schema और पुराना code एक साथ चलने लगते हैं। 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 पर सेट करें जिसे आपने तीसरी command द्वारा प्रिंट की गई सूची से चुना है। Backend log को तब तक monitor करें जब तक health endpoint फिर से जवाब न देने लगे। आपकी docker-compose.override.yml फाइल untracked है, इसलिए git checkout उसे अपनी जगह पर छोड़ देता है, लेकिन tags के बीच docker-compose.yml पर diff जरूर पढ़ें, क्योंकि कोई नई या rename की गई service बिना किसी error message के आपके override को पुराना (stale) बना सकती है।

विफलता के प्रकार और वे संदेश जो आपको दिखाई देंगे

एक container बार-बार restart हो रहा है और docker compose ps में exited (137) दिखाई देता है। यह kernel का out-of-memory killer है, और docker inspect livecontext-app इसे state block में "OOMKilled": true के साथ स्पष्ट करता है। Backend अपनी 1536M की सीमा तक पहुँच गया है, या host की memory पहले समाप्त हो गई है। किसी भी सीमा को बढ़ाने से पहले free -m की जाँच करें, क्योंकि अतिरिक्त memory न होने पर host पर container की सीमा बढ़ाने से केवल यह समस्या किसी दूसरे container में स्थानांतरित हो जाएगी।

Pull प्रक्रिया no matching manifest for linux/arm64/v8 in the manifest list entries के साथ विफल हो जाती है। ये images केवल linux/amd64 के लिए प्रकाशित की गई हैं। एक Arm VPS इन प्रकाशित images से इस stack को नहीं चला सकता, और QEMU के माध्यम से emulation एक JVM और Chromium के लिए बहुत धीमा है। किसी x86 plan पर जाएँ।

Bind for 0.0.0.0:3000 failed: port is already allocated। host पर कोई अन्य प्रक्रिया पहले से ही उस port का उपयोग कर रही है। docker/.env.ce में FRONTEND_PORT को बदलें, या ऊपर दिए गए override को लागू करें और कुछ भी publish न करें।

UI चालू है लेकिन proxy जोड़ने के बाद login अनुरोध विफल हो जाता है। browser उस origin पर backend को call कर रहा है जिसे आपका proxy serve नहीं करता है। browser के network tab को खोलें और विफल अनुरोध के host को देखें। GATEWAY_PUBLIC_URL को public backend URL पर set करें और frontend container को फिर से बनाएँ, क्योंकि यह मान startup के समय पढ़ा जाता है।

सब कुछ ठीक है लेकिन workflow में upload की गई फाइलें गायब हो जाती हैं। जाँचें कि minio-init में non-zero code के बजाय exited (0) दिखाई दे रहा है। यदि bucket workflow-files कभी नहीं बनाई गई थी, तो backend के पास objects रखने के लिए कोई स्थान नहीं है।

LiveContext या n8n का चयन करें

LiveContext तब चुनें जब एजेंट मुख्य केंद्र हो: यदि आप चाहते हैं कि मॉडल ऑटोमेशन बनाए और चलाए, और आप 8 GB RAM वाले सर्वर तथा Java सर्विस की आवश्यकता को स्वीकार करते हैं। n8n तब चुनें जब आपको deterministic workflows, nodes की एक विशाल लाइब्रेरी और ऐसा footprint चाहिए जो अन्य सर्विसेज के साथ एक ही VPS पर चल सके। यहाँ दिए गए version numbers अभी नए हैं, v0.2.11 अगस्त 2026 के अनुसार, इसलिए अपने tag को pin करें और हर upgrade से पहले release notes जरूर पढ़ें। व्यापक क्षेत्र के लिए, जिसमें इन दोनों के बीच स्थित टूल्स भी शामिल हैं, हमारे self-hosted n8n विकल्पों के राउंडअप को देखें, बजाय केवल इन दोनों की तुलना पढ़ने के।

FAQ

self-hosted LiveContext के लिए कितनी RAM की आवश्यकता होती है?

8 GB की योजना बनाएँ। अपस्ट्रीम README में 4 GB को न्यूनतम और 8 GB को अनुशंसित बताया गया है, और शिप किया गया compose file भी इसी के अनुरूप है: केवल backend को 1536 MB पर सीमित किया गया है, और पाँचों base services मिलकर unlimited frontend container से पहले 3 GB से थोड़ा कम उपयोग करती हैं। Browser agent profile को enable करने पर Chromium के लिए अतिरिक्त 2048 MB और एक SearXNG container जुड़ जाता है, इसलिए उस स्थिति में 8 GB अनिवार्य हो जाता है।

क्या मैं Arm VPS पर LiveContext चला सकता हूँ?

नहीं। प्रत्येक प्रकाशित image को linux/amd64 के लिए build किया गया है, इसलिए 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 पर लागू होता है। फ़ाइल को mode 600 पर रखें, केवल इस सर्वर के लिए बनाई गई key का उपयोग करें ताकि आप इसे अलग से revoke कर सकें, और provider console में spend cap सेट करें, क्योंकि वही एकमात्र सीमा है जो मशीन के बाहर मौजूद रहती है।

मैं LiveContext का बैकअप कैसे लूँ?

तीन चीजें: livecontext database का एक pg_dump, MinIO volume की एक प्रति, और docker/.env.ce फ़ाइल। पहली दो चीजें लेते समय livecontext और frontend services को रोक दें ताकि database और object store एक-दूसरे के साथ sync रहें। Env फ़ाइल महत्वपूर्ण है क्योंकि आपके workflows में संग्रहीत credentials CREDENTIAL_ENCRYPTION_PASSWORD और CREDENTIAL_ENCRYPTION_SALT के साथ encrypted होते हैं, इसलिए उन values के बिना restore करने पर ऐसी credential rows बचेंगी जिन्हें नए box पर कोई भी read नहीं कर पाएगा।

boot के बाद backend मिनटों तक health: starting पर क्यों अटका रहता है?

Compose healthcheck start_period: 120s सेट करता है और /actuator/health को poll करता है, इसलिए Docker service को starting के रूप में रिपोर्ट करता है जबकि schema migrations और tool registration चल रहे होते हैं। पहली बार boot करने पर दो से तीन मिनट का समय लगना सामान्य है। यदि यह कभी healthy नहीं होता है, तो docker compose logs -f livecontext पढ़ें। जो stack migration step पर रुक जाता है, वह आमतौर पर किसी नए release के database volume की ओर इंगित कर रहा होता है।