LiveContext स्वतःच्या सर्व्हरवर कसे इंस्टॉल करावे

LiveContext म्हणजे काय आणि ते चालवण्याचा खर्च

LiveContext स्वतःच्या सर्व्हरवर (self-host) चालवण्यासाठी तुम्हाला सुमारे 8 GB RAM असलेला VPS आवश्यक आहे. LiveContext CE हे एक source-available ऑटोमेशन प्लॅटफॉर्म आहे, जे ऑटोमेशनच्या आतच AI एजंट्स चालवते. हे सात कंटेनर्सच्या Docker Compose स्टॅकच्या स्वरूपात येते, जे Java बॅकएंडवर आधारित आहे. यातील एक कंटेनर 'one-shot job' आहे, जो सेटअप पूर्ण झाल्यावर बंद होतो. विक्रेत्याच्या self-hosting दस्तऐवजानुसार किमान 4 GB आणि शिफारस केलेली 8 GB RAM आवश्यक आहे. त्याच्या npm लाँचरच्या README मध्ये आता किमान 6 GB RAM नमूद केली आहे आणि compose फाईलमध्ये ही मेमरी कुठे वापरली जाते हे स्पष्ट होते.

हा प्रकल्प GitHub वर livecontext-ai/livecontext-ce म्हणून AGPL-3.0 अंतर्गत प्रकाशित केला होता, परंतु आता CE आवृत्ती AGPL नाही. सध्याच्या रिलीजसोबत मिळणारा परवाना 'LiveContext Sustainable Use License 1.1' हा आहे. हा एक source-available परवाना आहे जो तुम्हाला CE चालवण्याची आणि त्यात बदल करण्याची परवानगी देतो (तुमच्या व्यवसायात उत्पादनासाठी वापरण्यासह), परंतु LiveContext च्या सशुल्क आवृत्त्यांशी स्पर्धा करण्यासाठी तृतीय पक्षांना होस्टेड किंवा एम्बेडेड स्वरूपात सेवा देण्यास मनाई करतो. विक्रेत्याचा npm लाँचर हा बदल दर्शवतो: livecontext@0.2.11 ने AGPL-3.0-only घोषित केले आहे, तर livecontext@0.3.8 त्या परवाना फाईलकडे निर्देश करते. 13 ऑक्टोबर 2026 पर्यंत, GitHub रिपॉझिटरी आणि livecontext-ai संस्था दोन्ही 404 एरर दाखवत आहेत, जरी विक्रेत्याचे दस्तऐवज अजूनही ते क्लोन करण्यास सांगतात. त्यामुळे, हे मार्गदर्शक npm पॅकेजमधील रिलीज फाईल्सचा वापर करते. सध्याचे रिलीज v0.3.8 आहे, जे 9 ऑक्टोबर 2026 रोजी प्रकाशित झाले आहे. प्रत्येक LiveContext इमेज फक्त linux/amd64 साठी तयार केली आहे, ज्यामुळे स्वस्त Arm प्लॅन्स वापरता येत नाहीत. हे मार्गदर्शक त्या टॅगला पिन करते, स्टॅक एका reverse proxy च्या मागे ठेवते आणि अपस्ट्रीम बॅकअप सल्ल्याचे रूपांतर कमांड्समध्ये करते.

LiveContext self-host करण्यापूर्वी VPS चा आकार निश्चित करणे

शिप्ड compose फाईलमध्ये बहुतेक सेवांसाठी मेमरीची स्पष्ट मर्यादा दिलेली असते, त्यामुळे तुम्ही भाड्याने घेण्यापूर्वी सर्व्हरचा आकार ठरवू शकता. दोन सेवांना मर्यादा नाही: एक म्हणजे minio-init जॉब आणि दुसरी म्हणजे फ्रंटएंड. या मर्यादा v0.3.8 compose फाईलमध्ये लिहिलेल्या आहेत, प्रत्यक्ष वापरलेल्या मेमरीच्या नोंदी नाहीत.

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 2048
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "postgres",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "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
  }
]

केवळ बॅकएंडसाठी 2048 MB ची मर्यादा आहे. ही मर्यादा Java 21 प्रोसेसवर आहे, ज्याचा हीप (heap) 1 GiB वर सेट केला आहे (-Xmx1024m आणि ZGC सह). compose फाईलच्या कमेंटनुसार हीप पूर्ण 1 GiB पर्यंत वाढतो आणि त्यावर JVM चा अतिरिक्त ओव्हरहेड असतो. मर्यादित असलेल्या पाच मूलभूत सेवांची एकूण मेमरी सुमारे 3.6 GB होते. फ्रंटएंडला कोणतीही मर्यादा नसल्यामुळे, Node जेवढी मेमरी मागेल तेवढी ती घेते. 4 GB च्या VPS वर या मर्यादांमुळे फ्रंटएंड, कर्नल आणि पेज कॅशेसाठी फक्त काहीशे MB शिल्लक राहतात. म्हणूनच लाँचरच्या README मध्ये आता किमान 6 GB ची शिफारस केली आहे, जरी सेल्फ-होस्टिंग दस्तऐवजात अजूनही 4 GB चा उल्लेख आहे.

पर्यायी प्रोफाइल्समुळे सर्व्हरची गरज 8 GB पर्यंत वाढते. ब्राउझर एजंट प्रोफाइलमध्ये Chromium कंटेनर जोडला जातो, ज्याची मर्यादा 2048 MB आहे आणि त्यासोबत SearXNG सर्च इन्स्टन्स असतो. रेंडरर प्रोफाइलमध्ये स्क्रीनशॉट आणि PDF साठी आणखी 1024 MB लागतात. जोपर्यंत तुम्ही हे प्रोफाइल इनेबल करत नाही, तोपर्यंत ते सुरू होत नाहीत, त्यामुळे गरज नसेल तोपर्यंत ते बंद ठेवा. Chromium कंटेनर स्थानिक पातळीवर websearch-service डिरेक्टरीमधून बिल्ड केला जातो, जी npm पॅकेजमध्ये नसते. त्यामुळे 13 ऑक्टोबर 2026 पर्यंत, GitHub रिपॉझिटरी उपलब्ध नसल्यास ब्राउझर एजंट प्रोफाइल पब्लिश केलेल्या फाईल्सवरून बिल्ड करता येत नाही. रेंडरर पब्लिश केलेली इमेज वापरतो, त्यामुळे त्यावर कोणताही परिणाम होत नाही. SearXNG कंटेनर एजंटचा सर्च बॅकएंड म्हणून काम करतो. त्याद्वारे मिळणारी माहिती तुमच्या प्रॉम्प्ट्समध्ये अनट्रस्टेड टेक्स्ट म्हणून येते. ही ट्रस्ट बाउंड्री AI एजंटला SearXNG वेब सर्च देणे या लेखात सविस्तर स्पष्ट केली आहे.

जर तुम्ही आधीच n8n चालवत असाल, तर त्यात भर घालण्याऐवजी ते बदलण्याचा विचार करा. Docker आणि HTTPS सह VPS वर n8n चालवण्याबाबतचे आमचे मार्गदर्शक मधील स्टॅक हा Postgres सोबत एक Node प्रोसेस आहे आणि तो लहान सर्व्हरवर आरामात चालतो. LiveContext केवळ बॅकएंडसाठीच त्या संपूर्ण स्टॅकपेक्षा जास्त मेमरी राखून ठेवते. 8 GB च्या एकाच VPS वर दोन ऑटोमेशन प्लॅटफॉर्म चालवणे शक्य आहे, जोपर्यंत दोन्ही एकाच वेळी जॉब रन करत नाहीत. जर तुम्ही एकाच होस्टचा वापर करत असाल, तर Docker Compose मध्ये मेमरी मर्यादा सेट करण्याबाबतची आमची पोस्ट मधील पद्धत वापरून इतर सर्व गोष्टींवर स्पष्ट मर्यादा घाला. यामुळे एखादा अनियंत्रित वर्कफ्लो संपूर्ण मशीन बंद पाडणार नाही.

Docker Compose वापरून LiveContext इंस्टॉल करणे आणि विशिष्ट टॅगवर पिन करणे

Ubuntu 24.04 VPS वरून सुरुवात करा, ज्यावर Docker Engine 24 किंवा त्यापुढील आवृत्ती आणि Compose v2 इंस्टॉल केलेले असावे. जर Docker अद्याप इंस्टॉल नसेल, तर आधी आमच्या Docker Compose बेसिक्स फॉर VPS मार्गदर्शिकेचे पालन करा आणि त्यानंतर येथे परत या.

लाँचरच्या README मध्ये npx livecontext@latest ही एक ओळीची कमांड दिली आहे. लॅपटॉपवर हे ठीक आहे, परंतु लाँचर प्रत्येक वेळी रन केल्यावर त्याची compose फाईल पुन्हा कॉपी करतो आणि त्यात नमूद केलेल्या इमेजेस latest टॅग केलेल्या असतात. सर्व्हरवर तुम्हाला compose फाईल तुमच्या नियंत्रणाखालील डिरेक्टरीमध्ये हवी असते, जी एका विशिष्ट रिलीजवर पिन केलेली असावी, जेणेकरून अपग्रेड करताना तुम्ही फाईलमध्ये काय बदल झाले आहेत ते diff द्वारे पाहू शकाल. व्हेंडरचे डॉक्युमेंटेशन यासाठी अजूनही GitHub रिपॉझिटरीच्या git clone चा उल्लेख करते, परंतु 13 ऑक्टोबर 2026 रोजी ती रिपॉझिटरी 404 एरर दाखवत आहे. त्यामुळे, तुम्हाला हव्या असलेल्या रिलीजच्या npm पॅकेजमधून compose फाईल आणि उदाहरण म्हणून दिलेली env फाईल घ्या.

sudo apt update && sudo apt install -y npm
npm view livecontext version
mkdir -p ~/livecontext-ce/docker ~/livecontext-ce/catalog-seeds
cd ~/livecontext-ce
npm pack livecontext@0.3.8
tar xzf livecontext-0.3.8.tgz
cp package/assets/docker-compose.yml .
cp package/assets/.env.example docker/.env.ce
chmod 600 docker/.env.ce

Compose फाईल ./catalog-seeds ला बॅकएंडमध्ये bind-mount करते, म्हणूनच वरती ती डिरेक्टरी तयार केली आहे. npm लाँचर सुरुवातीला डाउनलोड केलेल्या मॉडेल कॅटलॉग बंडलने ती भरतो, आणि स्टॅक सुरू होताना ती रिकामी असते.

npm पॅकेजमधील compose फाईल प्रत्येक LiveContext इमेजला latest टॅगने दर्शवते, उदाहरणार्थ ghcr.io/livecontext-ai/livecontext-ce:latest, जरी त्याच्या हेडर कमेंटमध्ये टॅग रिलीजवर पिन केलेला असल्याचे म्हटले आहे. पहिल्यांदा सुरू करण्यापूर्वी तो स्वतः पिन करा. व्हेंडर Docker Hub वर livecontext नेमस्पेस अंतर्गत समान रिलीज टॅग प्रकाशित करतो, जिथे 13 ऑक्टोबर 2026 रोजी बॅकएंड, फ्रंटएंड, ब्रिज आणि रेंडरर इमेजेससाठी v0.3.8 सूचीबद्ध होते, म्हणून चारही इमेजेसना तिथे पॉइंट करा:

sed -i -E 's#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v0.3.8#' docker-compose.yml
grep -n 'image:' docker-compose.yml

इमेजेसच्या त्याच रिलीजची compose फाईल वापरल्यामुळे दोन्ही गोष्टी सुसंगत राहतात, कारण v0.3.8 साठीची 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 मूल्ये

उदाहरण फाईलमध्ये कार्यक्षम डीफॉल्ट मूल्ये दिलेली असतात, जेणेकरून स्टॅक लॅपटॉपवर सुरू होऊ शकेल. त्यातील अनेक मूल्ये सार्वजनिक सर्व्हरवर असुरक्षित असतात.

DB_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
PUBLIC_BASE_URL=https://lc.example.com
GATEWAY_PUBLIC_URL=https://lc-api.example.com

प्रत्येक यादृच्छिक (random) मूल्य openssl rand -base64 32 वापरून तयार करा. ज्या गोष्टींमुळे समस्या उद्भवू शकतात, त्याबद्दलच्या नोंदी खालीलप्रमाणे आहेत:

• DB_PASSWORD आणि MINIO_ROOT_PASSWORD हे postgres आणि minioadmin म्हणून येतात. compose फाईल DB_PASSWORD ला Postgres कडे त्याचे POSTGRES_PASSWORD म्हणून पाठवते. कोणताही डेटाबेस पोर्ट होस्टवर पब्लिश केलेला नसतो, त्यामुळे ते थेट उघड होत नाहीत, परंतु नंतर तुम्ही त्याच नेटवर्कला जोडलेल्या कोणत्याही कंटेनरद्वारे दस्तऐवजीकरण केलेल्या डीफॉल्ट मूल्यांसह त्या दोन्हीपर्यंत पोहोचता येते.
• CREDENTIAL_ENCRYPTION_PASSWORD आणि CREDENTIAL_ENCRYPTION_SALT हे कमेंट केलेले असतात आणि रिकामे ठेवल्यास पहिल्या बूटच्या वेळी ते आपोआप तयार होतात. त्याऐवजी ती स्वतः सेट करा. तुमच्या वर्कफ्लोमध्ये साठवलेली क्रेडेन्शियल्स त्या जोडीने एनक्रिप्ट केलेली असतात, त्यामुळे समान पासवर्ड आणि सॉल्टशिवाय नवीन बॉक्सवर रिस्टोर केलेला डेटाबेस डंप तुम्हाला अशा क्रेडेन्शियल ओळी देईल ज्या कोणीही वाचू शकणार नाही. ती एकदा सेट करा आणि त्यानंतर docker/.env.ce ला बॅकअपचा भाग म्हणून जपा.
• FRONTEND_PORT आणि BACKEND_PORT हे पोर्ट मॅपिंगमध्ये ${FRONTEND_PORT:-3000}:3000 आणि ${BACKEND_PORT:-8080}:8080 म्हणून बदलले जातात. उदाहरण env फाईलमध्ये दोन्ही # FRONTEND_PORT=3000 आणि # BACKEND_PORT=8080 म्हणून कमेंट केलेले असतात, त्यामुळे जोपर्यंत तुम्ही ओव्हरराइड करण्यासाठी ओळ अनकमेंट करत नाही, तोपर्यंत 3000 आणि 8080 हे डीफॉल्ट पोर्ट लागू राहतात.
• PUBLIC_BASE_URL हा वेब UI चा ब्राउझर-फेसिंग पत्ता आहे आणि उदाहरण फाईल सर्व्हर इन्स्टॉलेशनसाठी तो GATEWAY_PUBLIC_URL सोबत सेट करण्यास सांगते. दोन्हीच्या शेवटी स्लॅश (/) न लावता लिहा, कारण उदाहरण फाईलमध्ये इशारा दिला आहे की तसे केल्यास OAuth कॉलबॅक खंडित होतात.
• 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 मध्ये 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_bridge_secret, livecontext_cli_home, व livecontext_logs. Compose त्यांना प्रोजेक्टच्या नावाने प्रीफिक्स करते, जे compose फाइलमध्ये livecontext-ce म्हणून सेट केलेले असते, त्यामुळे डिस्कवरील प्रत्यक्ष व्हॉल्यूमचे नाव livecontext-ce_livecontext_minio सारखे असते. npm लाँचर त्या नावाला -p livecontext ने ओव्हरराइड करते, त्यामुळे ज्या बॉक्सवर एकदा npx livecontext चालले होते, त्यावर livecontext_ ने प्रीफिक्स केलेले दुसरे संच तयार होतात. कोणतीही बॅकअप स्क्रिप्ट लिहिण्यापूर्वी 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.yml च्या शेजारी 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 रिव्हर्स प्रॉक्सी मार्गदर्शक फॉलो करा. एका होस्टनेमला पोर्ट 3000 वरील frontend कडे आणि दुसऱ्याला पोर्ट 8080 वरील livecontext कडे राउट करा.

दुसरे होस्टनेम ऐच्छिक नाही. वेब UI ब्राउझरमधून बॅकएंडला कॉल करते, त्यामुळे बॅकएंडला स्वतःचे ओरिजिन असणे आवश्यक आहे जिथे ब्राउझर पोहोचू शकेल. docker/.env.ce मध्ये GATEWAY_PUBLIC_URL हे त्या बॅकएंड URL वर सेट करा, उदाहरणार्थ https://lc-api.example.com, आणि PUBLIC_BASE_URL हे फ्रंटएंड URL वर सेट करा. हे न केल्यास पेज लोड होईल पण कोणतीही कृती अयशस्वी होईल, कारण UI ने बॅकएंड ओरिजिन तुम्ही उघडलेल्या ॲड्रेसवरून शोधले आहे आणि ते अशा पोर्टला कॉल करत आहे जो तुमच्या प्रॉक्सीने कधीही पब्लिश केलेला नाही.

साइन-अप पेज जो कोणी आधी पोहोचेल त्याच्यासाठी खुले असल्याने, फ्रंटएंड राउटरवर फॉरवर्ड ऑथ (forward auth) लावणे फायदेशीर ठरते. यामुळे प्रॉक्सीवर ऑथेंटिकेट झाल्याशिवाय कोणालाही ते पेज दिसणार नाही, जे तुमच्या स्वतःच्या SSO लेयर म्हणून Authentik चालवणे या सेटअपमध्ये अतिरिक्त सुरक्षा म्हणून जोडता येते.

मॉडेल की (key) कुठे ठेवायची आणि आयडल (idle) इन्स्टन्ससाठी पैसे का लागतात

येथे automation च्या आत agents चालतात. त्यामुळे साध्या workflow tool च्या तुलनेत खर्चाची रचना वेगळी असते. Provider key docker/.env.ce मध्ये ANTHROPIC_API_KEY किंवा OPENAI_API_KEY या स्वरूपात ठेवली जाते. Backend आणि bridge ही key startup वेळी वाचतात आणि ती संपूर्ण instance ला लागू होते. तिचा scope प्रत्येक user साठी स्वतंत्र नसतो. तुमच्या instance वर account असलेली आणि agent तयार करू शकणारी कोणतीही व्यक्ती ही key वापरून खर्च करू शकते. नोंदणी करणारी पहिली व्यक्ती admin असते. प्रत्येक व्यक्तीसाठी स्वतंत्र agents आणि एखाद्या सहकाऱ्याशी प्रत्यक्ष जोडता येणारा खर्च हवा असल्यास, प्रत्येक व्यक्तीसाठी एक agent असलेले harness म्हणून OneCLI self-host करणे हा त्याच key समस्येचा दुसऱ्या पद्धतीने उपाय करतो. यात प्रत्येक model key कोण call करत आहे हे ओळखणाऱ्या gateway मागे ठेवली जाते.

तीन सवयींमुळे बिल मर्यादेत राहते. या VPS साठी एक स्वतंत्र प्रोव्हायडर की तयार करा, जेणेकरून इतर कशालाही धक्का न लावता तुम्ही ती रद्द करू शकाल. प्रोव्हायडर कन्सोलमध्ये खर्चाची एक निश्चित मर्यादा (hard spend cap) सेट करा, कारण मशीनच्या बाहेर तीच एकमेव मर्यादा आहे जी तुम्ही सुरक्षित करू शकता. त्यानंतर, LiveContext द्वारे उपलब्ध करून दिलेले प्रति-एजंट क्रेडिट बजेट आणि प्रति-एजंट मेट्रिक्स वापरा, जेणेकरून एखादे लूप तुमच्या लक्षात येण्याआधीच सर्व क्रेडिट्स संपवू शकणार नाही.

एजंट एकदा शेड्यूलवर सेट झाला की त्याचा आयडल खर्च शून्य राहत नाही. शेड्यूल ट्रिगर कोणी पाहत असो वा नसो, तो कार्यान्वित होतो आणि प्रत्येक वेळी टोकन्स खर्च होतात. पाच मिनिटांचे शेड्यूल म्हणजे दिवसाला 288 वेळा रन होणे. एखादा एजंट जो पेज वाचतो आणि काहीही न करण्याचा निर्णय घेतो, तरीही त्याला पेज वाचण्यासाठी पैसे मोजावे लागतात. तुमचे पहिले एजंट्स वेबहूक (webhook) किंवा चॅट ट्रिगरवर ठेवा, एक आठवडा प्रत्यक्ष होणारा खर्च तपासा आणि प्रति-रन खर्च समजल्यानंतरच शेड्यूलवर जा.

Postgres आणि ऑब्जेक्ट स्टोअरचा बॅकअप घ्या

येथे दोन डेटा स्टोअर्स आणि सीक्रेट्स साठवणारी दोन ठिकाणे आहेत: env फाईल आणि livecontext_keys व्हॉल्यूम. व्हेंडरच्या दस्तऐवजानुसार, बॅकअप घेण्यासाठी आवश्यक असलेल्या व्हॉल्यूम्समध्ये याचा समावेश होतो. यापैकी कोणतीही गोष्ट गमावल्यास तुमची इन्स्टन्स नष्ट होईल. डेटाबेस आणि बकेटचा बॅकअप एकाच वेळी घ्या. हे करताना बॅकएंड बंद ठेवा, जेणेकरून डेटाबेस रो डंप झाल्यानंतर कोणतीही नवीन फाईल लिहिली जाणार नाही.

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 run --rm \
  -v livecontext-ce_livecontext_keys:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-keys-$(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-compose.yml आणि तुमची ओव्हरराइड फाईलसह सर्व चार फाईल्स सर्व्हरवरून बाहेर कॉपी करा. जो बॅकअप फक्त त्याच मशीनवर राहतो ज्याचे तो संरक्षण करतो, तो खरा बॅकअप नसतो.

नवीन सर्व्हरवर रिस्टोर करण्यासाठी, त्याच टॅगची स्थापना करा, सेव्ह केलेली docker/.env.ce फाईल परत ठेवा जेणेकरून क्रेडेंशियल एन्क्रिप्शन पासवर्ड आणि सॉल्ट जुळतील. स्टॅक एकदा सुरू करा जेणेकरून व्हॉल्यूम्स तयार होतील, त्यानंतर बॅकएंड बंद करा. कीज आर्काइव्ह ज्या पद्धतीने घेतली होती त्याच पद्धतीने कीज व्हॉल्यूममध्ये अनपॅक करा आणि त्यानंतर डंप लोड करा:

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) लागू करते आणि मायग्रेशन्स फक्त पुढेच जातात. त्यामुळे, चुकीच्या अपग्रेडनंतर जुन्या टॅगवर परतल्यास जुना कोड नवीन स्कीमावर चालतो. रोलबॅक (rollback) म्हणजे डंप रिस्टोअर करणे, म्हणूनच डंप घेणे सर्वात महत्त्वाचे आहे.

cd ~/livecontext-ce
npm view livecontext version
TAG=0.3.8
npm pack "livecontext@$TAG"
rm -rf package && tar xzf "livecontext-$TAG.tgz"
cp docker-compose.yml docker-compose.yml.prev
cp package/assets/docker-compose.yml .
sed -i -E "s#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v$TAG#" docker-compose.yml
diff docker-compose.yml.prev docker-compose.yml
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 वर सेट करा. हेल्थ एंडपॉइंट (health endpoint) पुन्हा प्रतिसाद देईपर्यंत बॅकएंड लॉगवर लक्ष ठेवा. तुमची docker-compose.override.yml ही पॅकेजचा भाग नसते, त्यामुळे नवीन compose फाईल कॉपी केल्यावर ती तिथेच राहते. परंतु, diff कमांडने प्रिंट केलेली diff नक्की वाचा, कारण नवीन किंवा पुनर्नामांकित केलेली सेवा तुमच्या ओव्हरराइडला (override) कोणत्याही त्रुटी संदेशाशिवाय निरुपयोगी बनवू शकते. docker/.env.ce ची तुलना package/assets/.env.example सोबत देखील करा, कारण नवीन सेटिंग्ज तिथे येतात.

अपयशाचे प्रकार आणि दिसणारे संदेश

कंटेनर वारंवार रीस्टार्ट होत आहे आणि docker compose ps मध्ये exited (137) दिसत आहे. हे कर्नलच्या out-of-memory killer मुळे घडते आणि docker inspect livecontext-app मध्ये "OOMKilled": true स्टेट ब्लॉकद्वारे याची पुष्टी होते. बॅकएंडने आपली 2048M ची मर्यादा ओलांडली आहे किंवा होस्टची मेमरी संपली आहे. कोणतीही मर्यादा वाढवण्यापूर्वी 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 मध्ये शून्य नसलेला कोड (non-zero code) नसून exited (0) दिसत असल्याची खात्री करा. जर workflow-files बकेट तयार केली नसेल, तर बॅकएंडकडे ऑब्जेक्ट्स साठवण्यासाठी जागा नसते.

LiveContext किंवा n8n निवडा

जेव्हा एजंट मुख्य असतो तेव्हा LiveContext निवडा: तुम्हाला मॉडेलने ऑटोमेशन तयार करावे आणि चालवावे असे वाटते, आणि त्यासाठी तुम्ही 8 GB रॅम असलेला सर्व्हर आणि Java सर्व्हिस वापरण्यास तयार असता. जेव्हा तुम्हाला निश्चित वर्कफ्लो, नोड्सची मोठी लायब्ररी आणि इतर सर्व्हिसेससोबत VPS शेअर करणारी सिस्टिम हवी असते, तेव्हा n8n निवडा. आता परवान्यांमुळे या दोघांमधील फरक उरलेला नाही. LiveContext CE हे AGPL-3.0 वरून LiveContext Sustainable Use License 1.1 वर स्थलांतरित झाले आहे. हा एक source-available परवाना असून तो n8n's Sustainable Use License प्रमाणेच fair-code कुटुंबातील आहे, त्यामुळे तुमच्या कंपनीबाहेरील कोणालाही हे देण्यापूर्वी त्यातील होस्टिंग निर्बंध वाचा. self-hosted n8n मध्ये काही फीचर्स केवळ सशुल्क ग्राहकांसाठी राखीव आहेत, त्यामुळे टीम वर्कफ्लो तयार करण्यापूर्वी n8n चे कोणते भाग मोफत आहेत आणि कोणासाठी लायसन्स की आवश्यक आहे हे तपासा. 13 ऑक्टोबर 2026 रोजी v0.3.8 नुसार येथील व्हर्जन नंबर्स नवीन आहेत आणि 0.3 लाईनमध्ये 22 सप्टेंबर ते 9 ऑक्टोबर 2026 दरम्यान नऊ releases आले आहेत, त्यामुळे तुमचे व्हर्जन पिन करा आणि प्रत्येक अपग्रेडपूर्वी काय बदलले आहे ते वाचा. या दोन पर्यायांच्या दरम्यान असलेल्या साधनांसह व्यापक क्षेत्रासाठी, केवळ या दोघांची तुलना वाचण्याऐवजी आमच्या self-hosted n8n पर्यायांचे संकलन पहा.

FAQ

self-hosted LiveContext साठी किती RAM आवश्यक आहे?

8 GB RAM चे नियोजन करा. व्हेंडरच्या self-hosting दस्तऐवजानुसार 4 GB ही किमान आणि 8 GB ही शिफारस केलेली क्षमता आहे. लाँचरच्या README मध्ये आता किमान 6 GB चा उल्लेख आहे आणि सोबत दिलेल्या compose फाईलमध्ये याचे कारण स्पष्ट केले आहे: केवळ backend साठी 2048 MB ची मर्यादा आहे आणि पाच मूलभूत सेवांची एकत्रित मर्यादा 3.6 GB पर्यंत जाते, ज्यामध्ये अमर्यादित frontend कंटेनरचा समावेश नाही. ब्राउझर एजंट प्रोफाइल सुरू केल्यास Chromium साठी अतिरिक्त 2048 MB आणि एक SearXNG कंटेनर जोडला जातो, त्यामुळे 8 GB पेक्षा कमी RAM असणे तांत्रिकदृष्ट्या शक्य नाही.

मी LiveContext Arm VPS वर चालवू शकतो का?

नाही. v0.3.8 साठी प्रकाशित केलेली प्रत्येक LiveContext इमेज ही linux/amd64 साठी तयार केलेली आहे, त्यामुळे Arm प्लॅनवर docker compose up चालवताना pull करताना no matching manifest for linux/arm64/v8 in the manifest list entries एरर येते. QEMU इम्युलेशन वापरून हे चालवणे सैद्धांतिकदृष्ट्या शक्य असले तरी, JVM वर्कलोडसाठी ते व्यावहारिक नाही. x86 प्लॅनची निवड करा.

माझी model API key मी कुठे ठेवू?

docker/.env.ce मध्ये, ANTHROPIC_API_KEY, OPENAI_API_KEY किंवा GOOGLE_API_KEY म्हणून, पहिल्यांदा सुरू करण्यापूर्वी ठेवा. backend आणि bridge स्टार्टअपच्या वेळी ही की वाचतात आणि ती एका वापरकर्त्याऐवजी संपूर्ण इन्स्टन्ससाठी लागू होते. फाईलचा मोड 600 ठेवा, फक्त या सर्व्हरसाठी तयार केलेली की वापरा जेणेकरून तुम्ही ती स्वतंत्रपणे रद्द करू शकाल आणि प्रोव्हायडर कन्सोलमध्ये खर्चाची मर्यादा (spend cap) सेट करा, कारण ही मर्यादा मशीनच्या बाहेर अस्तित्वात असलेला एकमेव प्रतिबंध आहे.

मी LiveContext चा बॅकअप कसा घेऊ?

चार गोष्टी महत्त्वाच्या आहेत: livecontext डेटाबेसचा एक pg_dump, MinIO व्हॉल्यूमची प्रत, livecontext_keys व्हॉल्यूमची प्रत आणि 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 वाचा. मायग्रेशन टप्प्यावर थांबलेला स्टॅक सहसा नवीन रिलीजच्या डेटाबेस व्हॉल्यूमशी जोडलेला असतो.