ஆல் LiveContext-ஐ நீங்களே host செய்வது எப்படி?
LiveContext CE-ஐ உங்கள் சர்வரில் நிறுவுவதற்கான முழுமையான வழிகாட்டி. 8 GB RAM தேவைப்படும் இந்த 6-container Docker stack-ஐ Traefik உடன் இணைத்து பாதுகாப்பாக பேக்கப் எடுப்பது எப்படி?
LiveContext என்றால் என்ன மற்றும் அதை இயக்குவதற்கான செலவு
LiveContext-ஐ நீங்களே 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 என்று குறிப்பிடுகிறது. இந்த memory எங்கே செலவாகிறது என்பதை compose file காட்டுகிறது.
இந்தத் திட்டம் GitHub-ல் livecontext-ai/livecontext-ce என்ற இடத்தில் உள்ளது மற்றும் AGPL-3.0 உரிமம் பெற்றது. ஆகஸ்ட் 2026 நிலவரப்படி தற்போதைய release v0.2.11 ஆகும், இது 3 ஆகஸ்ட் 2026 அன்று வெளியிடப்பட்டது. ஒவ்வொரு image-ம் linux/amd64-க்காக மட்டுமே உருவாக்கப்பட்டுள்ளது, இது மலிவான Arm திட்டங்களை இதில் பயன்படுத்த முடியாது என்பதை உறுதிப்படுத்துகிறது. இந்த வழிகாட்டி அந்த tag-ஐ pin செய்கிறது, stack-ஐ ஒரு reverse proxy-க்கு பின்னால் வைக்கிறது, மேலும் upstream ஆவணங்களில் இல்லாத backup நடைமுறைகளையும் விளக்குகிறது.
LiveContext-ஐ self-host செய்வதற்கு முன் VPS-ன் அளவைத் தீர்மானித்தல்
வழங்கப்பட்ட compose file-ல் உள்ள ஒவ்வொரு service-க்கும் ஒரு குறிப்பிட்ட memory limit உள்ளது. எனவே, நீங்கள் VPS-ஐ வாடகைக்கு எடுப்பதற்கு முன்பே அதன் அளவைத் தீர்மானிக்க முடியும். இவை v0.2.11 compose file-ல் குறிப்பிடப்பட்டுள்ள வரம்புகள்; இவை பயன்பாட்டின் அளவீடுகள் அல்ல.
The data behind this chart
[
{
"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 அந்த நினைவகத்தின் பெரும்பகுதியை எடுத்துக்கொண்டு அங்கேயே நிலைத்திருக்கும். ஐந்து அடிப்படை service-களும் சேர்ந்து 3 GB-க்கும் சற்று குறைவாகவே இருக்கும். Frontend-க்கு எந்த வரம்பும் இல்லை, எனவே Node எவ்வளவு கேட்கிறதோ அவ்வளவு நினைவகத்தை அது எடுத்துக்கொள்ளும். 4 GB VPS-ல் kernel மற்றும் page cache-க்கு இடமே இருக்காது என்பதால், 4 GB என்பது பரிந்துரை அல்ல, குறைந்தபட்சத் தேவையாகவே குறிப்பிடப்பட்டுள்ளது.
விருப்பத்தேர்வாக உள்ள profiles-ஐப் பயன்படுத்தினால், VPS-ன் தேவை 8 GB வரை உயரும். Browser agent profile, SearXNG search instance-க்கு அருகில் 2048 MB வரம்பு கொண்ட ஒரு Chromium container-ஐச் சேர்க்கிறது. Renderer profile, screenshots மற்றும் PDFs-க்காக மேலும் 1024 MB-ஐச் சேர்க்கிறது. நீங்கள் profile-ஐ enable செய்யாதவரை இவை தொடங்காது, எனவே தேவைப்படும் வரை இரண்டையும் off-ல் வைக்கவும்.
நீங்கள் ஏற்கனவே n8n-ஐப் பயன்படுத்துகிறீர்கள் என்றால், அதை LiveContext-உடன் சேர்ப்பதற்குப் பதிலாக, அதை மாற்றுவதைப் பற்றித் திட்டமிடுங்கள். Docker மற்றும் HTTPS மூலம் VPS-ல் n8n-ஐ இயக்குவதற்கான எங்கள் வழிகாட்டி-ல் உள்ள stack, Postgres-க்கு அருகில் ஒரு Node process-ஐ மட்டுமே கொண்டுள்ளது, இது சிறிய VPS-ல் சிறப்பாக இயங்கும். LiveContext-ன் backend மட்டுமே அந்த முழு stack-ஐ விட அதிக நினைவகத்தை ஒதுக்குகிறது. ஒரே 8 GB VPS-ல் இரண்டு automation தளங்களை இயக்கினால், இரண்டும் ஒரே நேரத்தில் வேலை செய்யும்போது சிக்கல் ஏற்படும். நீங்கள் ஒரே host-ஐப் பகிர்ந்துகொள்வதாக இருந்தால், Docker Compose-ல் memory limits அமைப்பது குறித்த எங்கள் பதிவு-ல் உள்ள முறையைப் பயன்படுத்தி மற்ற அனைத்திற்கும் வரம்புகளை நிர்ணயித்துக்கொள்ளுங்கள். அப்போதுதான், ஒரு workflow கட்டுப்பாட்டை மீறினாலும் அது முழு machine-ஐயும் முடக்காது.
Docker Compose மூலம் LiveContext-ஐ நிறுவுதல், ஒரு குறிப்பிட்ட tag-ல் நிலைநிறுத்துதல்
Docker Engine 24 அல்லது அதற்கு மேற்பட்ட பதிப்பு மற்றும் Compose v2 கொண்ட சுத்தமான Ubuntu 24.04 VPS-ல் தொடங்கவும். Docker இன்னும் நிறுவப்படவில்லை என்றால், முதலில் எங்கள் Docker Compose அடிப்படை வழிகாட்டியை பின்பற்றிவிட்டு, பிறகு இங்கே திரும்பவும்.
README கோப்பில் npx livecontext என்ற கட்டளை ஒரு வரியில் தொடங்குவதற்கு வழங்கப்பட்டுள்ளது. இது மடிக்கணினிகளுக்கு ஏற்றது. சர்வரில், நீங்கள் கட்டுப்படுத்தும் ஒரு கோப்பகத்தில் (directory) compose கோப்பை வைத்திருப்பது சிறந்தது. அப்போதுதான், மேம்படுத்தல் (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 கோப்பு ஏற்கனவே ஒவ்வொரு image-ஐயும் அதன் release tag-உடன் இணைத்துள்ளது, உதாரணமாக ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. பொருத்தமான git tag-ஐ checkout செய்வதுதான் compose கோப்பையும் image-களையும் சீராக வைத்திருக்க உதவும், ஏனெனில் v0.2.11-க்கான compose கோப்பு அந்த image-களுக்காகவே எழுதப்பட்டது. tag-களை latest என மாற்ற வேண்டாம். ஒரு latest tag அடிக்கடி மாறக்கூடியது, மேலும் backend ஒவ்வொரு தொடக்கத்திலும் அதன் database migrations-ஐ இயக்கும். எனவே, தற்செயலாக ஒரு pull செய்வது உங்கள் database schema-வை அதிகாலை 3 மணிக்கு மாற்றக்கூடும், அதை மீண்டும் பழைய நிலைக்குக் கொண்டுவர backup-ஐ மீட்டெடுப்பதைத் தவிர வேறு வழியில்லை.
முதல் முறை தொடங்குவதற்கு முன் docker/.env.ce கோப்பைத் திருத்தவும் (அடுத்த பகுதியில் எதை மாற்ற வேண்டும் என்பது பட்டியலிடப்பட்டுள்ளது), பிறகு stack-ஐ இயக்கவும்.
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-ஐ வெளியிடக்கூடும்.
Backend healthcheck-க்கு start_period 120s ஆக உள்ளது மற்றும் அது /actuator/health-ஐத் தொடர்ந்து சோதிக்கும். எனவே, schema migrations மற்றும் tool registration நடக்கும் முதல் இரண்டு நிமிடங்களுக்கு docker compose ps கட்டளை livecontext service-ஐ health: starting என்று காட்டும். இது சாதாரணமானது. சர்வரிலிருந்து ஒரு விரைவான சோதனை:
curl -s localhost:8080/actuator/healthஇது {"status":"UP"} என்று காட்ட வேண்டும். அது வந்தவுடன், port 3000-ல் web UI-ஐத் திறக்கவும். நீங்கள் உருவாக்கும் முதல் கணக்கே admin கணக்காகும், எனவே மற்றவர்கள் அந்த port-ஐ அணுகும் முன்பே உங்கள் கணக்கை உருவாக்கிவிடுங்கள். முதல் நாளிலேயே port 3000-ஐ இணையத்தில் பொதுவெளியில் திறக்கக்கூடாது என்பதற்கு இதுவே மிக முக்கியமான காரணமாகும்.
நீங்கள் மாற்ற வேண்டிய env மதிப்புகள்
இந்த stack ஒரு laptop-ல் இயங்குவதற்காக, மாதிரி கோப்பு (example file) சில இயல்புநிலை அமைப்புகளுடன் (defaults) வருகிறது. பொது இணையத்தில் உள்ள 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 மூலம் உருவாக்கவும். கவனிக்க வேண்டியவை:
POSTGRES_PASSWORDமற்றும்MINIO_ROOT_PASSWORDஆகியவைpostgresமற்றும்minioadminஎன வருகின்றன. எந்த database port-ம் host-க்கு வெளியிடப்படவில்லை (published), எனவே அவை நேரடியாக வெளிப்படுவதில்லை. ஆனால், அதே network-ல் நீங்கள் இணைக்கும் எந்த container-ம் ஆவணப்படுத்தப்பட்ட இயல்புநிலை மதிப்புகளைக் கொண்டு அவற்றை அணுக முடியும்.CREDENTIAL_ENCRYPTION_PASSWORDமற்றும்CREDENTIAL_ENCRYPTION_SALTகாலியாக இருந்தால் தானாகவே உருவாக்கப்படும். அவற்றை நீங்களே அமைப்பது சிறந்தது. உங்கள் workflows சேமிக்கும் நற்சான்றுகள் (credentials) அந்த ஜோடியைக் கொண்டு குறியாக்கம் (encrypted) செய்யப்படுகின்றன. எனவே, அதே password மற்றும் salt இல்லாமல் ஒரு புதிய server-ல் database dump-ஐ மீட்டெடுத்தால், உங்களால் அந்த credential வரிசைகளை வாசிக்க முடியாது. இவற்றை ஒருமுறை அமைத்துவிட்டு,docker/.env.ce-ஐ உங்கள் backup-ன் ஒரு பகுதியாகக் கருதவும்.FRONTEND_PORTமற்றும்BACKEND_PORTஆகியவை port mappings-ல்${FRONTEND_PORT:-3000}:3000மற்றும்${BACKEND_PORT:-8080}:8080என மாற்றப்படுகின்றன. மாதிரி env கோப்பு இரண்டையும் வெளிப்படையாக அமைக்கிறது, மேலும் அதன் மதிப்புகள் எப்போதும் 3000 மற்றும் 8080 ஆக இருப்பதில்லை. எனவே, ஊகிப்பதற்குப் பதிலாக உங்கள் கோப்பை வாசித்துப் பார்க்கவும்.GATEWAY_PUBLIC_URLஎன்பது backend-ன் browser-க்குத் தெரியும் origin ஆகும். reverse proxy பயன்படுத்தப்படும்போது இது முக்கியமானது. அடுத்த பகுதியைப் பார்க்கவும்.- model keys (
ANTHROPIC_API_KEY,OPENAI_API_KEY,GOOGLE_API_KEY, மற்றும் விருப்பத்தேர்வாகMISTRAL_API_KEYஅல்லதுDEEPSEEK_API_KEY) இங்கே plain text-ல் உள்ளன. நீங்கள் பயன்படுத்தும் provider-க்கு மட்டும் மதிப்புகளை நிரப்பவும்.
ஆறு container-களின் செயல்பாடுகள்
postgresஎன்பதுpgvector/pgvector:pg16-ஐlivecontext-dbஎன்ற container-ஆக இயக்குகிறது, இதுlivecontextஎன்று பெயரிடப்பட்ட database-ஐக் கொண்டுள்ளது. Embedding search-க்காக இதில் pgvector extension உள்ளது, எனவே சாதாரணpostgres:16image-ஐ இதற்குப் பயன்படுத்த முடியாது.redisஎன்பதுredis:7-alpine-ஐappendonly yesமற்றும்--maxmemory-policy noevictionஆகியவற்றுடன் இயக்குகிறது. இந்த policy வேண்டுமென்றே அமைக்கப்பட்டது: Redis இங்கே queue மற்றும் run state-ஐக் கையாளுகிறது, எனவே இது அதன் memory உச்சத்தை அடையும் போது, தரவுகளை அமைதியாக நீக்குவதற்குப் பதிலாக, எழுதுபவருக்கு (writer) ஒரு error-ஐத் திருப்பி அனுப்பும். மறைந்துபோகும் வேலையை விட, நீங்கள் காணக்கூடிய ஒரு error சிறந்தது.minioஎன்பது workflows-ல் நகரும் கோப்புகளுக்கான S3-compatible object store ஆகும். ஒரு one-shotminio-initcontainer, தொடக்கத்தின் போதுmc mb myminio/workflow-files --ignore-existing-ஐ இயக்கி, bucket-ஐ உருவாக்கிவிட்டு வெளியேறும்.docker compose ps-ல்minio-initஎன்பதுexited (0)ஆகத் தெரிவதுதான் சரியான நிலை.bridgeஎன்பது CLI adapters மற்றும் MCP (model context protocol) கருவிகளைக் கொண்டுள்ளது. இது Docker network-க்குள் 8093 port-ல் இயங்குகிறது மற்றும் host-க்கு வெளியிடப்படவில்லை (not published).livecontextஎன்பது backend ஆகும், இது port 8080-ல் இயங்கும் ஒரு Java 21 monolith ஆகும். இது workflow engine, schedulers மற்றும் agents ஆகியவற்றை இயக்குகிறது.frontendஎன்பது port 3000-ல் இயங்கும் Next.js web UI ஆகும். இந்த கடைசி இரண்டு மட்டுமே host-க்கு வெளியிடப்பட்டுள்ளன.
தரவுகள் ஐந்து named volumes-ல் சேமிக்கப்படுகின்றன: Postgres-க்காக livecontext_data, மற்றும் livecontext_redis, livecontext_minio, livecontext_keys, livecontext_logs. Compose இவற்றை project பெயருடன் முன்னொட்டாக (prefix) சேர்க்கும், இது இயல்பாக directory பெயராக இருக்கும், எனவே வட்டில் உள்ள உண்மையான volume பெயர் livecontext-ce_livecontext_minio போன்ற வடிவில் இருக்கும். docker volume ls-ஐ இயக்கி, அவற்றுக்கான backup script-ஐ எழுதும் முன் சரியான பெயர்களை நகலெடுத்துக் கொள்ளவும்.
docker compose down -vஎன்பது அந்த ஐந்து volumes-ஐயும் நீக்கிவிடும். இது மீண்டும் தொடங்குவதற்கான ஆவணப்படுத்தப்பட்ட வழியாகும், அதே சமயம் நீங்கள் உருவாக்கிய அனைத்து workflows-களையும் இழப்பதற்கான மிக வேகமான வழியாகவும் இது அமையும். அந்த-vதான் எல்லாவற்றிற்கும் உள்ள வித்தியாசம்.
Port 3000-ஐ வெளியிடுவதற்குப் பதிலாக Traefik-ன் பின்னால் வைக்கவும்
பொது VPS-ல் port 3000 மற்றும் 8080-ஐ வெளியிடுவது, TLS (transport layer security) இல்லாமலும், admin registration-க்கு முன்னால் எந்தத் தடுப்பும் இல்லாமலும் application-ஐ வெளிப்படுத்துகிறது. ஒரு ufw விதி மட்டும் போதாது, ஏனெனில் Docker தான் வெளியிடும் ports-களுக்காக ufw நிர்வகிக்கும் chain-க்கு முன்னதாகவே சொந்தமாக iptables விதிகளைச் சேர்க்கிறது. எனவே, 0.0.0.0-க்கு வெளியிடப்பட்ட ஒரு port, ufw அந்த port-ஐ மறுத்தாலும் அணுகக்கூடியதாகவே இருக்கும்.
இதற்கான சரியான தீர்வு, எதையும் வெளியிடாமல், பகிரப்பட்ட Docker network வழியாக proxy-ஐ 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 பட்டியலை இணைப்பதற்குப் பதிலாக மாற்றீடு செய்கிறது, இதற்கு Compose v2.24 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை: docker compose version மூலம் இதைச் சரிபார்க்கவும், ஏனெனில் பழைய Compose பதிப்புகளில் இரண்டு பட்டியல்களும் இணைந்து ports தொடர்ந்து வெளியிடப்பட்டிருக்கும். மேலும், default ஒவ்வொரு networks பட்டியலிலும் இருக்க வேண்டும், ஏனெனில் ஏதேனும் ஒரு network-ஐக் குறிப்பிடுவது default network-ஐ நீக்கிவிடும், எனவே அதைத் தவிர்த்தால் frontend-க்கும் Postgres மற்றும் Redis-க்கும் இடையிலான தொடர்பு துண்டிக்கப்படும். எதையும் தொடங்கும் முன் இணைக்கப்பட்ட முடிவை உறுதிப்படுத்தவும்:
docker compose --env-file docker/.env.ce configRouters, certificate resolver மற்றும் HTTP to HTTPS redirect ஆகியவை மற்ற அனைத்து applications-க்கும் இருப்பது போலவே இருக்கும், எனவே புதிய TLS configuration-ஐ எழுதுவதற்குப் பதிலாக ஒரே VPS-ல் பல applications-ஐ இயக்க எங்களது Traefik reverse proxy வழிகாட்டியைப் பின்பற்றவும். ஒரு hostname-ஐ port 3000-ல் உள்ள frontend-க்கும், இரண்டாவது hostname-ஐ port 8080-ல் உள்ள livecontext-க்கும் route செய்யவும்.
இரண்டாவது hostname கட்டாயமானது. Web UI ஆனது browser-லிருந்து backend-ஐ அழைக்கிறது, எனவே backend-க்கு browser அணுகக்கூடிய சொந்த origin தேவை. docker/.env.ce-ல் GATEWAY_PUBLIC_URL-ஐ அந்த backend URL-க்கு அமைக்கவும், உதாரணமாக https://lc-api.example.com. இதைத் தவிர்த்தால், பக்கம் சாதாரணமாகத் திறக்கும் ஆனால் ஒவ்வொரு செயலும் தோல்வியடையும், ஏனெனில் UI நீங்கள் திறந்த முகவரியிலிருந்து backend origin-ஐத் தீர்மானித்து, உங்கள் proxy வெளியிடாத ஒரு port-ஐ அழைக்கும்.
Sign-up பக்கம் முதலில் வருபவர்களுக்குத் திறந்திருப்பதால், frontend router-ல் forward auth-ஐச் சேர்ப்பது நல்லது. இதன் மூலம் proxy-ல் authenticate செய்யாமல் யாரும் அந்தப் பக்கத்தைப் பார்க்க முடியாது. Authentik-ஐ உங்கள் சொந்த SSO layer-ஆக இயக்குவது இதே Traefik அமைப்பின் மேல் கூடுதல் பாதுகாப்பை வழங்குகிறது.
Model key எங்கே வைக்கப்பட வேண்டும், மற்றும் idle instance ஏன் இன்னும் கட்டணத்தை வசூலிக்கிறது
இங்குள்ள automation-க்குள் agents இயங்குகின்றன, இது ஒரு சாதாரண workflow கருவியுடன் ஒப்பிடும்போது பொருளாதாரத்தை மாற்றுகிறது. Provider key docker/.env.ce-ல் ANTHROPIC_API_KEY அல்லது OPENAI_API_KEY ஆக வைக்கப்படுகிறது, இது startup-ன் போது backend மற்றும் bridge-ஆல் வாசிக்கப்பட்டு, முழு instance-க்கும் பொருந்தும். இது பயனர் வாரியாக வரையறுக்கப்படவில்லை. உங்கள் instance-ல் கணக்கு வைத்திருக்கும் மற்றும் agent-ஐ உருவாக்கக்கூடிய எவரும் அந்த key-ஐப் பயன்படுத்துகிறார்கள், மேலும் முதலில் பதிவு செய்யும் நபர் admin ஆவார்.
மூன்று பழக்கவழக்கங்கள் கட்டணத்தை முன்கூட்டியே கணிக்க உதவும். இந்த VPS-க்காக ஒரு தனி provider key-ஐ உருவாக்கவும், இதன் மூலம் மற்ற எதையும் பாதிக்காமல் அதை revoke செய்ய முடியும். Provider console-ல் ஒரு கடினமான spend cap-ஐ அமைக்கவும், ஏனெனில் நீங்கள் பாதுகாக்கும் machine-க்கு வெளியே உள்ள ஒரே கட்டுப்பாடு அந்த வரம்புதான். பிறகு, LiveContext வெளிப்படுத்தும் per-agent credit budgets மற்றும் per-agent metrics-ஐப் பயன்படுத்தவும், இதனால் ஒரு single loop நீங்கள் கவனிக்கும் முன்பே key-ன் இருப்பைக் காலி செய்யாது.
ஒரு agent schedule-ல் இருக்கும்போது idle cost பூஜ்ஜியமாக இருக்காது. யாராவது கவனிக்கிறார்களோ இல்லையோ, ஒரு schedule trigger இயங்கும், ஒவ்வொரு இயக்கமும் tokens-ஐ அனுப்பும். ஐந்து நிமிட schedule என்பது ஒரு நாளைக்கு 288 இயக்கங்கள் ஆகும், மேலும் ஒரு பக்கத்தை வாசித்துவிட்டு எதுவும் செய்ய வேண்டாம் என்று முடிவு செய்யும் ஒரு agent கூட அந்தப் பக்கத்தை வாசித்ததற்காகக் கட்டணம் செலுத்துகிறது. உங்கள் முதல் agents-ஐ webhook அல்லது chat trigger-ல் வைக்கவும், ஒரு வாரம் உண்மையான செலவைக் கவனிக்கவும், ஒரு இயக்கத்திற்கான செலவு தெரிந்த பிறகு schedule-க்கு மாறவும்.
Postgres மற்றும் object store-ஐ பேக்கப் எடுத்தல்
இதில் இரண்டு தரவு சேமிப்பகங்களும் (data stores) ஒரு ரகசியமும் (secret) உள்ளன. இவை மூன்றில் எதை இழந்தாலும் உங்கள் instance-ஐ இழக்க நேரிடும். Database மற்றும் bucket ஆகிய இரண்டையும் ஒரே நேரத்தில் பேக்கப் எடுக்கவும். அப்போது backend-ஐ நிறுத்தி வைக்கவும்; இதனால் database row dump செய்யப்பட்ட பிறகு புதிய கோப்புகள் எழுதப்படுவது தவிர்க்கப்படும்.
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)Dump கோப்பு காலியாக இல்லை என்பதை உறுதிப்படுத்திய பின்பே அதை நம்பவும்: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 கட்டளையை இயக்கும்போது, அது ஒரே வரி பிழை செய்தியைக் காட்டாமல், CREATE TABLE மற்றும் DROP TABLE அறிக்கைகளைக் காட்ட வேண்டும். அதன் பிறகு, அந்த மூன்று கோப்புகளையும் server-லிருந்து வெளியே நகலெடுக்கவும். எந்த server-ஐ பாதுகாக்கிறதோ, அதே server-ல் மட்டும் சேமிக்கப்படும் பேக்கப் உண்மையான பேக்கப் ஆகாது.
புதிய server-ல் restore செய்ய, அதே tag-ஐ install செய்யவும். சேமித்து வைக்கப்பட்ட docker/.env.ce-ஐ மீண்டும் அதன் இடத்தில் வைக்கவும், அப்போதுதான் credential encryption password மற்றும் salt ஆகியவை சரியாகப் பொருந்தும். volumes உருவாக்கப்படுவதற்காக stack-ஐ ஒருமுறை தொடங்கி, பின் backend-ஐ நிறுத்தவும். அதன் பிறகு dump-ஐ ஏற்றவும்:
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-ஐ தொடங்கும்போதே செயல்படுத்தும்; இந்த மாற்றங்கள் முன்னோக்கி மட்டுமே செல்லும். எனவே, ஒரு தவறான மேம்படுத்தலுக்குப் பிறகு பழைய tag-க்கு மாறினால், புதிய schema-வுடன் பழைய code இயங்கும். 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-ல் அமைக்கவும். Health endpoint மீண்டும் பதிலளிக்கும் வரை backend log-ஐ கவனிக்கவும். உங்கள் docker-compose.override.yml கண்காணிக்கப்படாதது (untracked), எனவே git checkout அதை அப்படியே வைத்திருக்கும். இருப்பினும், tag-களுக்கு இடையே உள்ள docker-compose.yml-ல் உள்ள மாற்றங்களை (diff) கவனமாகப் படிக்கவும். ஏனெனில், புதிய service அல்லது பெயர் மாற்றப்பட்ட service, எந்தவித பிழைச் செய்தியும் இன்றி உங்கள் override-ஐ பயனற்றதாக மாற்றக்கூடும்.
தோல்வி முறைகள் மற்றும் நீங்கள் காணும் செய்திகள்
ஒரு 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-ன் வரம்பை அதிகரிப்பது, அந்த kill செயலை மற்றொரு container-க்கு மாற்றும்.
no matching manifest for linux/arm64/v8 in the manifest list entries பிழையுடன் pull தோல்வியடைகிறது. இந்த images linux/amd64-க்காக மட்டுமே வெளியிடப்பட்டுள்ளன. ஒரு Arm VPS-ல் இந்த stack-ஐ வெளியிடப்பட்ட images மூலம் இயக்க முடியாது, மேலும் QEMU மூலமான emulation ஒரு JVM மற்றும் Chromium-க்கு மிகவும் மெதுவாக இருக்கும். x86 திட்டத்திற்கு மாறவும்.
Bind for 0.0.0.0:3000 failed: port is already allocated. host-ல் உள்ள வேறொரு service ஏற்கனவே அந்த port-ஐப் பயன்படுத்துகிறது. docker/.env.ce-ல் உள்ள FRONTEND_PORT-ஐ மாற்றவும் அல்லது மேலே குறிப்பிட்டுள்ள override-ஐப் பயன்படுத்தி எதையும் publish செய்யாமல் விடவும்.
UI இயங்குகிறது, ஆனால் proxy-ஐச் சேர்த்த பிறகு login கோரிக்கை தோல்வியடைகிறது. உங்கள் proxy சேவை செய்யாத ஒரு origin-க்கு browser கோரிக்கையை அனுப்புகிறது. browser-ன் network tab-ஐத் திறந்து தோல்வியடையும் கோரிக்கையின் host-ஐப் பார்க்கவும். GATEWAY_PUBLIC_URL-ஐ public backend URL-க்கு அமைத்து frontend container-ஐ மீண்டும் உருவாக்கவும், ஏனெனில் அந்த மதிப்பு தொடக்கத்தின்போதே (startup) படிக்கப்படும்.
அனைத்தும் சரியாக உள்ளது, ஆனால் workflow-ல் பதிவேற்றப்பட்ட கோப்புகள் காணவில்லை. minio-init-ல் பூஜ்ஜியம் அல்லாத குறியீட்டிற்குப் பதிலாக exited (0) காட்டுகிறதா என்று சரிபார்க்கவும். workflow-files bucket உருவாக்கப்படவில்லை என்றால், backend-ஆல் பொருட்களைச் சேமிக்க முடியாது.
LiveContext அல்லது n8n-ஐத் தேர்ந்தெடுத்தல்
ஏஜென்ட் (agent) செயல்பாடே முதன்மையானது என்றால் LiveContext-ஐத் தேர்ந்தெடுக்கவும்: மாடல் (model) தானியங்கி முறையை உருவாக்கி இயக்க வேண்டும் என்று நீங்கள் விரும்பினால், அதற்காக 8 GB RAM கொண்ட சர்வர் மற்றும் Java service-ஐப் பயன்படுத்த நீங்கள் தயாராக இருக்க வேண்டும். தீர்மானிக்கப்பட்ட பணிப்பாய்வுகள் (deterministic workflows), அதிகப்படியான நோட் லைப்ரரிகள் (node library) மற்றும் பிற சேவைகளுடன் ஒரு VPS-ஐப் பகிர்ந்து கொள்ளும் திறன் தேவைப்பட்டால் n8n-ஐத் தேர்ந்தெடுக்கவும். v0.2.11 ஆகஸ்ட் 2026 நிலவரப்படி, இங்குள்ள பதிப்பு எண்கள் புதியவை என்பதால், ஒவ்வொரு முறை upgrade செய்வதற்கு முன்பும் உங்கள் tag-ஐ pin செய்து, release notes-ஐப் படிக்கவும். இந்த இரண்டுக்கும் இடைப்பட்ட கருவிகள் உட்பட விரிவான தகவல்களுக்கு, இந்த இரண்டை மட்டும் ஒப்பிட்டுப் பார்ப்பதற்குப் பதிலாக self-hosted n8n மாற்றுகளின் தொகுப்பைப் பார்க்கவும்.
FAQ
ஒரு self-hosted LiveContext-க்கு எவ்வளவு RAM தேவை?
8 GB RAM-ஐ திட்டமிடுங்கள். Upstream README-ல் குறைந்தபட்சம் 4 GB மற்றும் பரிந்துரைக்கப்படுவது 8 GB எனக் குறிப்பிடப்பட்டுள்ளது. வழங்கப்பட்ட compose file-ம் இதையே உறுதிப்படுத்துகிறது: backend மட்டும் 1536 MB ஆகக் கட்டுப்படுத்தப்பட்டுள்ளது. ஐந்து அடிப்படைச் சேவைகள் (base services) சேர்ந்து, வரம்பற்ற frontend container-க்கு முன்பாகவே 3 GB-க்கும் சற்று குறைவாகப் பயன்படுத்துகின்றன. Browser agent profile-ஐச் செயல்படுத்தினால், Chromium-க்காக மேலும் 2048 MB மற்றும் ஒரு SearXNG container தேவைப்படும். எனவே, அந்த நிலையில் 8 GB என்பது விருப்பத்தேர்வு அல்ல, அவசியமானது.
என்னால் Arm VPS-ல் LiveContext-ஐ இயக்க முடியுமா?
முடியாது. வெளியிடப்பட்ட ஒவ்வொரு 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-ஐ எங்கே வைக்க வேண்டும்?
முதல்முறை தொடங்குவதற்கு முன்பாக, docker/.env.ce-ல் ANTHROPIC_API_KEY, OPENAI_API_KEY அல்லது GOOGLE_API_KEY ஆகச் சேர்க்கவும். Backend மற்றும் bridge ஆகியவை தொடங்கும்போதே இதைப் படித்துக்கொள்ளும். இது ஒரு பயனருக்கு மட்டும் அல்லாமல், முழு instance-க்கும் பொருந்தும். கோப்பை 600 mode-ல் வைத்திருக்கவும். இந்த server-க்காக மட்டும் உருவாக்கப்பட்ட key-ஐப் பயன்படுத்தவும், அப்போதுதான் தேவைப்பட்டால் அதை மட்டும் தனியாக revoke செய்ய முடியும். Provider console-ல் ஒரு செலவு வரம்பை (spend cap) நிர்ணயிக்கவும், ஏனெனில் அந்த வரம்பு மட்டுமே machine-க்கு வெளியே இருக்கும் ஒரே பாதுகாப்பு ஆகும்.
LiveContext-ஐ எப்படி backup எடுப்பது?
மூன்று விஷயங்கள் தேவை: livecontext database-ன் ஒரு pg_dump, MinIO volume-ன் ஒரு நகல், மற்றும் docker/.env.ce கோப்பு. முதல் இரண்டையும் எடுக்கும்போது livecontext மற்றும் frontend சேவைகளை நிறுத்தி வைக்கவும், அப்போதுதான் database-ம் object store-ம் ஒன்றுடன் ஒன்று ஒத்துப்போகும். Env கோப்பு முக்கியமானது, ஏனெனில் உங்கள் workflows-ல் சேமிக்கப்பட்டுள்ள credentials CREDENTIAL_ENCRYPTION_PASSWORD மற்றும் CREDENTIAL_ENCRYPTION_SALT மூலம் encrypt செய்யப்பட்டுள்ளன. அந்த மதிப்புகள் இல்லாமல் restore செய்தால், புதிய machine-ல் உள்ள எந்தவொரு சேவையாலும் credential வரிசைகளைப் படிக்க முடியாது.
Boot செய்த பிறகு backend ஏன் சில நிமிடங்கள் health: starting நிலையிலேயே இருக்கிறது?
Compose healthcheck start_period: 120s-ஐ அமைத்து /actuator/health-ஐத் தொடர்ந்து சரிபார்க்கிறது. Schema migrations மற்றும் tool registration நடக்கும்போது, service தொடங்கும் நிலையில் (starting) இருப்பதாக Docker தெரிவிக்கும். முதல்முறை boot செய்யும்போது இரண்டு முதல் மூன்று நிமிடங்கள் வரை எடுப்பது இயல்பானது. அது ஒருபோதும் healthy நிலைக்கு வரவில்லை என்றால், docker compose logs -f livecontext-ஐப் படிக்கவும். Migration நிலையிலேயே நிற்கும் stack, பெரும்பாலும் புதிய release-ல் உள்ள database volume-ஐச் சுட்டிக்காட்டுகிறது.