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

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

LiveContext स्वतःच्या सर्व्हरवर (self-host) चालवण्यासाठी तुम्हाला सुमारे 8 GB RAM असलेला VPS आवश्यक आहे. LiveContext CE हे एक ओपन सोर्स ऑटोमेशन प्लॅटफॉर्म आहे जे ऑटोमेशनच्या आतच AI एजंट्स चालवते. हे Java बॅकएंडवर आधारित सहा कंटेनर्सच्या Docker Compose स्टॅकच्या स्वरूपात उपलब्ध (ships) आहे. अपस्ट्रीम README नुसार किमान 4 GB आणि शिफारस केलेली 8 GB RAM आवश्यक आहे, आणि compose फाईलमध्ये ही मेमरी कुठे वापरली जाते हे स्पष्ट होते.

हा प्रकल्प GitHub वर livecontext-ai/livecontext-ce येथे उपलब्ध असून तो AGPL-3.0 लायसन्स अंतर्गत आहे. ऑगस्ट 2026 पर्यंतची सध्याची आवृत्ती v0.2.11 आहे, जी 3 ऑगस्ट 2026 रोजी प्रकाशित झाली आहे. प्रत्येक इमेज फक्त linux/amd64 साठी तयार केली आहे, त्यामुळे स्वस्त Arm प्लॅन्सवर हे चालणार नाही. हे मार्गदर्शक त्या टॅगला पिन करते, स्टॅक एका reverse proxy च्या मागे ठेवते आणि बॅकअप प्रक्रिया कव्हर करते जी अपस्ट्रीम दस्तऐवजात समाविष्ट केलेली नाही.

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

दिलेल्या compose फाईलमधील प्रत्येक सेवेसाठी मेमरीची स्पष्ट मर्यादा (memory limit) निश्चित केलेली आहे, त्यामुळे भाड्याने घेण्यापूर्वीच तुम्ही सर्व्हरचा आकार ठरवू शकता. या मर्यादा 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 ची भर घालते. जोपर्यंत तुम्ही हे प्रोफाइल्स enable करत नाही, तोपर्यंत ते सुरू होत नाहीत, त्यामुळे गरज पडल्याशिवाय दोन्ही बंद ठेवा. तो SearXNG कंटेनर एजंटचा सर्च बॅकएंड म्हणून काम करतो, त्यामुळे त्याद्वारे मिळणारी माहिती तुमच्या प्रॉम्प्ट्समध्ये 'अविश्वसनीय मजकूर' (untrusted text) म्हणून येते. हीच ती ट्रस्ट बाउंड्री आहे ज्याबद्दल 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 ही कमांड वन-लाइन स्टार्ट म्हणून दिली आहे. लॅपटॉपवर हे ठीक आहे. सर्व्हरवर मात्र, 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 टॅग तुमच्या नकळत बदलू शकतो आणि बॅकएंड प्रत्येक स्टार्टला डेटाबेस मायग्रेशन्स रन करते, त्यामुळे चुकून झालेला 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 फाईलमध्ये असलेल्या डीफॉल्ट सेटिंग्जवर अवलंबून राहते आणि तुम्ही कॉन्फिगर केलेल्या पोर्ट्सपेक्षा वेगळे पोर्ट्स पब्लिश करू शकते.

बॅकएंड हेल्थचेकमध्ये 120s चा 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 या स्वरूपात येतात. दोन्ही डेटाबेस पोर्ट होस्टवर पब्लिश केलेले नसतात, त्यामुळे ते थेट उघड होत नाहीत. परंतु, नंतर तुम्ही त्याच नेटवर्कला जोडलेल्या कोणत्याही कंटेनरद्वारे या डीफॉल्ट मूल्यांचा वापर करून तिथे पोहोचता येते.
• CREDENTIAL_ENCRYPTION_PASSWORD आणि CREDENTIAL_ENCRYPTION_SALT रिकामे सोडल्यास ते आपोआप तयार होतात. त्याऐवजी ती स्वतः सेट करा. तुमच्या वर्कफ्लोमध्ये साठवलेली क्रेडेन्शियल्स या जोडीने एनक्रिप्ट केलेली असतात. त्यामुळे, जर तुम्ही समान पासवर्ड आणि सॉल्टशिवाय नवीन सर्व्हरवर डेटाबेस डंप रिस्टोर केला, तर तुम्हाला त्यातील क्रेडेन्शियल ओळी वाचता येणार नाहीत. ही मूल्ये एकदाच सेट करा आणि त्यानंतर docker/.env.ce ला बॅकअपचा एक भाग म्हणून जपा.
• FRONTEND_PORT आणि BACKEND_PORT हे पोर्ट मॅपिंगमध्ये ${FRONTEND_PORT:-3000}:3000 आणि ${BACKEND_PORT:-8080}:8080 म्हणून वापरले जातात. उदाहरण फाईलमध्ये दोन्ही स्पष्टपणे सेट केलेले असतात आणि त्यात दिलेली मूल्ये नेहमीच 3000 किंवा 8080 नसतात. त्यामुळे गृहीत धरण्याऐवजी तुमच्या फाईलमध्ये काय आहे ते तपासा.
• GATEWAY_PUBLIC_URL हे बॅकएंडचे ब्राउझर-फेसिंग ओरिजिन आहे. जेव्हा तुम्ही रिव्हर्स प्रॉक्सी वापरता, तेव्हा हे महत्त्वाचे ठरते. पुढील विभाग पहा.
• मॉडेल कीज (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY आणि पर्यायी MISTRAL_API_KEY किंवा DEEPSEEK_API_KEY) येथे प्लेन टेक्स्टमध्ये असतात. तुम्ही जो प्रोव्हायडर वापरता, फक्त त्याचीच माहिती भरा.

सहा कंटेनर्सचे कार्य

• postgres हे pgvector/pgvector:pg16 ला livecontext-db या कंटेनर म्हणून चालवते, ज्यामध्ये livecontext नावाचा डेटाबेस असतो. एम्बेडिंग सर्चसाठी यामध्ये pgvector एक्स्टेंशन असते, त्यामुळे केवळ postgres:16 इमेज वापरून चालणार नाही.
• redis हे redis:7-alpine ला appendonly yes आणि --maxmemory-policy noeviction सह चालवते. हे धोरण जाणीवपूर्वक ठेवले आहे: 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) टूल्स असतात. हे 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 च्या नियमांच्या आधी जोडते. त्यामुळे, 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) कुठे ठेवायची आणि आयडल (idle) इन्स्टन्ससाठी पैसे का लागतात

येथे ऑटोमेशनमध्ये एजंट्स चालतात, ज्यामुळे साध्या वर्कफ्लो टूलच्या तुलनेत याचे आर्थिक गणित बदलते. प्रोव्हायडर की (provider key) docker/.env.ce मध्ये ANTHROPIC_API_KEY किंवा OPENAI_API_KEY म्हणून साठवली जाते. बॅकएंड आणि ब्रिज स्टार्टअपच्या वेळी ती वाचतात आणि ती संपूर्ण इन्स्टन्ससाठी लागू होते. ती प्रति-वापरकर्ता (per-user) मर्यादित नसते. तुमच्या इन्स्टन्सवर ज्याचे खाते आहे आणि जो एजंट तयार करू शकतो, तो त्या की (key) चा वापर करत असतो आणि नोंदणी करणारी पहिली व्यक्ती ॲडमिन असते.

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

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

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

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

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 फाईल पुन्हा ठेवा जेणेकरून क्रेडेंशियल एन्क्रिप्शन पासवर्ड आणि सॉल्ट जुळतील. त्यानंतर स्टॅक एकदा सुरू करा जेणेकरून व्हॉल्यूम्स तयार होतील, बॅकएंड थांबवा आणि मग डंप लोड करा:

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

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 मध्ये सेट करा. हेल्थ एंडपॉईंट (health endpoint) पुन्हा प्रतिसाद देईपर्यंत बॅकएंड लॉगवर लक्ष ठेवा. तुमची docker-compose.override.yml ही फाईल अनट्रॅक (untracked) असते, त्यामुळे git checkout केल्यास ती तशीच राहते. मात्र, टॅग्समधील बदलांसाठी docker-compose.yml वरील diff नक्की वाचा, कारण नवीन किंवा पुनर्नामांकित केलेली सेवा तुमच्या ओव्हरराईड (override) फाईलला कोणत्याही त्रुटी संदेशाशिवाय कालबाह्य (stale) बनवू शकते.

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

कंटेनर वारंवार रीस्टार्ट होत आहे आणि docker compose ps मध्ये exited (137) दिसत आहे. हे कर्नलच्या out-of-memory killer मुळे घडते आणि docker inspect livecontext-app मध्ये state ब्लॉक अंतर्गत "OOMKilled": true हा संदेश याची पुष्टी करतो. बॅकएंडने आपली 1536M ची मर्यादा ओलांडली आहे किंवा होस्टची मेमरी पूर्ण संपली आहे. कोणतीही मर्यादा वाढवण्यापूर्वी free -m तपासा, कारण अतिरिक्त मेमरी उपलब्ध नसताना कंटेनरची मर्यादा वाढवल्यास, मेमरी संपल्यामुळे होणारा बंद (kill) दुसऱ्या कंटेनरवर स्थलांतरित होईल.

इमेज पुल करताना 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 सुरू आहे पण प्रॉक्सी जोडल्यानंतर लॉगिन विनंती अयशस्वी होत आहे. ब्राउझर अशा ओरिजिनवर बॅकएंडला कॉल करत आहे जो तुमच्या प्रॉक्सीद्वारे सर्व्ह केला जात नाही. ब्राउझरचा network टॅब उघडा आणि अयशस्वी झालेल्या विनंतीचा होस्ट तपासा. GATEWAY_PUBLIC_URL ला पब्लिक बॅकएंड URL वर सेट करा आणि फ्रंटएंड कंटेनर पुन्हा तयार करा, कारण हे मूल्य स्टार्टअपच्या वेळी वाचले जाते.

सर्व काही व्यवस्थित आहे पण वर्कफ्लोमध्ये अपलोड केलेल्या फाइल्स गायब होत आहेत. minio-init मध्ये शून्य नसलेला कोड (non-zero code) नसून exited (0) दिसत आहे का ते तपासा. जर workflow-files ही बकेट तयार केली नसेल, तर बॅकएंडकडे ऑब्जेक्ट्स साठवण्यासाठी जागा नसते.

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

जेव्हा एजंट मुख्य असतो तेव्हा LiveContext निवडा: तुम्हाला मॉडेलने ऑटोमेशन तयार करावे आणि चालवावे असे वाटते, आणि त्यासाठी तुम्ही 8 GB चा सर्व्हर आणि Java सर्व्हिसची किंमत मोजण्यास तयार असता. जेव्हा तुम्हाला निश्चित (deterministic) वर्कफ्लो, नोड्सची मोठी लायब्ररी आणि इतर सर्व्हिसेससोबत VPS शेअर करणारी सिस्टिम हवी असते, तेव्हा n8n निवडा. ऑगस्ट 2026 पर्यंत v0.2.11 या आवृत्त्या नवीन आहेत, त्यामुळे तुमचे टॅग पिन करा आणि प्रत्येक अपग्रेडपूर्वी रिलीज नोट्स वाचा. या दोन पर्यायांच्या दरम्यान असलेल्या साधनांसह व्यापक माहितीसाठी, केवळ या दोघांची तुलना वाचण्याऐवजी आमच्या self-hosted n8n पर्यायांचे संकलन पहा.

FAQ

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

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

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

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

माझी मॉडेल API key मी कुठे टाकू?

docker/.env.ce मध्ये, ANTHROPIC_API_KEY, OPENAI_API_KEY किंवा GOOGLE_API_KEY म्हणून, पहिल्यांदा सुरू करण्यापूर्वी. backend आणि bridge स्टार्टअपच्या वेळी ही की वाचतात आणि ती एका वापरकर्त्याऐवजी संपूर्ण इन्स्टन्सला लागू होते. फाईलचा मोड 600 ठेवा, फक्त या सर्व्हरसाठी तयार केलेली की वापरा जेणेकरून ती स्वतंत्रपणे रद्द करता येईल, आणि प्रोव्हायडर कन्सोलमध्ये खर्चाची मर्यादा (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 वाचा. मायग्रेशन टप्प्यावर थांबलेला स्टॅक सहसा नवीन रिलीजच्या डेटाबेस व्हॉल्यूमवर पॉइंट केलेला असतो.