Jinsi ya kujiendeshea LiveContext kwenye seva yako

LiveContext ni nini, na gharama zake za uendeshaji

Ili kujiendeshea LiveContext mwenyewe (self-host), unahitaji VPS yenye takriban 8 GB ya RAM. LiveContext CE ni jukwaa la otomatiki la chanzo huria (open source) linaloendesha mawakala wa AI ndani ya otomatiki yenyewe, na linasambazwa kama Docker Compose stack ya kontena sita zilizojengwa juu ya backend ya Java. README ya mradi huu inaomba angalau 4 GB na inapendekeza 8 GB, na faili la compose linaonyesha jinsi kumbukumbu hiyo inavyotumika.

Mradi huu unapatikana katika livecontext-ai/livecontext-ce kwenye GitHub, na una leseni ya AGPL-3.0. Toleo la sasa kufikia Agosti 2026 ni v0.2.11, lililochapishwa tarehe 3 Agosti 2026. Kila image imejengwa kwa ajili ya linux/amd64 pekee, jambo ambalo linaondoa uwezekano wa kutumia mipango ya bei nafuu ya Arm. Mwongozo huu unatumia tag hiyo mahususi, unaweka stack hii nyuma ya reverse proxy, na unaelezea utaratibu wa kuhifadhi nakala (backup) ambao nyaraka za mradi hazijauhusisha.

Kadiria ukubwa wa VPS kabla ya ku-self-host LiveContext

Kila huduma katika faili ya compose iliyosafirishwa ina kikomo cha kumbukumbu kilichobainishwa wazi, hivyo unaweza kukadiria ukubwa wa seva kabla ya kuikodisha. Hivi ni vikomo vilivyoandikwa ndani ya faili ya v0.2.11 compose, si matumizi yaliyopimwa.

[
  {
    "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 pekee imewekewa kikomo cha 1536 MB. Kikomo hicho kipo juu ya mchakato wa Java 21, kwa hivyo JVM itajaza sehemu kubwa ya nafasi hiyo na kubaki hapo. Huduma tano za msingi kwa pamoja zinachukua chini ya 3 GB, na frontend haina kikomo chochote, hivyo inachukua kile ambacho Node inahitaji. Kwenye VPS ya 4 GB, hii haibakishi chochote kwa ajili ya kernel na page cache, ndiyo maana 4 GB imeandikwa kama kiwango cha chini badala ya pendekezo.

Profaili za hiari ndizo zinazoisukuma seva kufikia 8 GB. Profaili ya browser agent inaongeza container ya Chromium yenye kikomo cha 2048 MB kando ya mfano wa utafutaji wa SearXNG, na profaili ya renderer inaongeza 1024 MB nyingine kwa ajili ya screenshots na PDFs. Hakuna kati ya hizi inayoanza isipokuwa ukiwasha profaili yake, kwa hivyo ziache zote zikiwa zimezimwa hadi utakapozihitaji.

Ikiwa tayari unaendesha n8n, panga kuibadilisha badala ya kuiongeza. Stack iliyo katika mwongozo wetu wa kuendesha n8n kwenye VPS kwa kutumia Docker na HTTPS ni mchakato mmoja wa Node kando ya Postgres, na inafanya kazi vizuri kwenye seva ndogo. LiveContext inatenga nafasi zaidi kwa ajili ya backend yake pekee kuliko stack hiyo yote inavyotumia. Mifumo miwili ya otomatiki kwenye VPS moja ya 8 GB itatoshea hadi pale zote mbili zitakapofanya kazi kwa wakati mmoja. Ikiwa utashiriki seva moja, weka vikomo wazi kwenye kila kitu kingine pia, kwa kutumia mbinu iliyo katika chapisho letu kuhusu kuweka vikomo vya kumbukumbu katika Docker Compose, ili workflow moja inayotoka nje ya udhibiti isishushe mashine nzima.

Sakinisha LiveContext kwa kutumia Docker Compose, ukiwa umefunga toleo (tag)

Anza na VPS safi ya Ubuntu 24.04 yenye Docker Engine 24 au mpya zaidi na Compose v2. Ikiwa Docker haijasakinishwa bado, fuata misingi yetu ya Docker Compose kwa VPS, kisha urudi hapa.

README inatoa npx livecontext kama njia ya kuanza kwa mstari mmoja. Hiyo inafaa kwenye kompyuta ya mkononi. Kwenye seva, unataka faili ya compose ikae kwenye saraka unayoimiliki, kwa sababu kufanya upgrade ni sawa na git checkout na unaweza kusoma hasa nini kimebadilika.

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

Faili ya compose tayari imefunga kila image kwenye tag yake ya release, kwa mfano ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Kufanya checkout ya git tag inayolingana ndiyo inayoweka faili ya compose na images katika mpangilio, kwa sababu faili ya compose ya v0.2.11 iliandikwa kwa ajili ya images hizo. Usibadilishe tags kuwa latest. Tag ya latest hubadilika bila wewe kujua, na backend huendesha database migrations zake kila inapoanza, kwa hivyo pull ya bahati mbaya inaweza kusogeza schema yako mbele saa 9 usiku bila njia ya kurudi nyuma isipokuwa kwa restore.

Hariri docker/.env.ce kabla ya kuanza kwa mara ya kwanza (sehemu inayofuata inaorodhesha nini cha kubadilisha), kisha uwashe stack.

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

Tumia flag ileile ya --env-file kwenye kila amri ya compose katika mwongozo huu. Compose husoma faili hiyo upya kila inapoitwa, kwa hivyo amri isiyo na flag hiyo itarejea kwenye defaults zilizowekwa ndani ya faili ya compose na inaweza kuchapisha ports tofauti na zile ulizosanidi.

Healthcheck ya backend ina start_period ya 120s na hupiga kura /actuator/health, kwa hivyo docker compose ps itaripoti huduma ya livecontext kama health: starting kwa takriban dakika mbili za kwanza wakati migrations za schema na usajili wa zana vikiendelea. Hiyo ni kawaida. Ukaguzi wa haraka kutoka kwa seva:

curl -s localhost:8080/actuator/health

Hii inapaswa kuchapisha {"status":"UP"}. Ikifanya hivyo, fungua web UI kwenye port 3000. Akaunti ya kwanza unayounda inakuwa ya admin, kwa hivyo unda yako kabla ya port hiyo kufikiwa na mtu mwingine yeyote. Hii ndiyo sababu muhimu zaidi ya kutochapisha port 3000 kwenye Internet siku ya kwanza.

Thamani za env unazopaswa kubadilisha

Faili la mfano linakuja na mipangilio chaguo-msingi inayofanya kazi ili stack iweze kuanza kwenye laptop. Baadhi ya mipangilio hiyo si salama kwenye seva ya umma.

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

Tengeneza kila thamani ya nasibu kwa kutumia openssl rand -base64 32. Maelezo kuhusu zile zinazosababisha changamoto:

• POSTGRES_PASSWORD na MINIO_ROOT_PASSWORD zinakuja kama postgres na minioadmin. Hakuna port ya database inayochapishwa kwenye host, kwa hivyo hazijafichuliwa moja kwa moja, lakini container yoyote utakayoiunganisha kwenye mtandao huo baadaye inaweza kufikia zote mbili kwa kutumia chaguo-msingi lililoandikwa.
• CREDENTIAL_ENCRYPTION_PASSWORD na CREDENTIAL_ENCRYPTION_SALT hutengenezwa kiotomatiki zikiachwa wazi. Ziweke wewe mwenyewe badala yake. Vitambulisho vinavyohifadhiwa na workflows zako husimbwa kwa njia fiche kwa kutumia jozi hiyo, kwa hivyo database dump inayorejeshwa kwenye mashine mpya bila password na salt ileile itakupa safu za vitambulisho ambazo hakuna kitu kinachoweza kuzisoma. Ziweke mara moja, kisha ichukulie docker/.env.ce kama sehemu ya backup.
• FRONTEND_PORT na BACKEND_PORT hubadilishwa kwenye ramani za port kama ${FRONTEND_PORT:-3000}:3000 na ${BACKEND_PORT:-8080}:8080. Faili la mfano la env huweka zote mbili kwa uwazi, na thamani zinazokuja nazo si mara zote 3000 na 8080. Soma nakala yako badala ya kudhani.
• GATEWAY_PUBLIC_URL ndiyo asili ya backend inayoelekea kwenye kivinjari. Ni muhimu mara tu reverse proxy inapohusika. Tazama sehemu inayofuata.
• Funguo za model (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, na kwa hiari MISTRAL_API_KEY au DEEPSEEK_API_KEY) hukaa hapa kwa maandishi ya kawaida (plain text). Jaza tu mtoa huduma unayemtumia kwa sasa.

Kazi za containers sita

• postgres huendesha pgvector/pgvector:pg16 kama container livecontext-db, ikihifadhi database yenye jina livecontext. Kiendelezi cha pgvector kipo kwa ajili ya utafutaji wa embedding, kwa hivyo image ya kawaida ya postgres:16 haitafaa.
• redis huendesha redis:7-alpine ikiwa na appendonly yes na --maxmemory-policy noeviction. Sera hiyo imekusudiwa: Redis hubeba foleni na hali ya uendeshaji hapa, kwa hivyo inapofikia kikomo cha kumbukumbu yake, inarudisha kosa kwa mwandishi badala ya kufuta funguo kimyakimya. Kosa unaloweza kuliona ni bora kuliko kazi inayopotea.
• minio ni hifadhi ya vitu inayooana na S3 kwa ajili ya faili zinazopita kwenye workflows. Container moja ya minio-init huendesha mc mb myminio/workflow-files --ignore-existing wakati wa kuanza, hutengeneza bucket, na kujifunga. Kuona minio-init kama exited (0) katika docker compose ps ndiyo hali ya kawaida.
• bridge inashikilia CLI adapters na zana za MCP (model context protocol). Inasikiliza kwenye 8093 ndani ya mtandao wa Docker na haijachapishwa kwenye host.
• livecontext ni backend, monolith moja ya Java 21 kwenye port 8080. Inaendesha injini ya workflow, schedulers, na mawakala.
• frontend ni Next.js web UI kwenye port 3000. Ni hizi mbili za mwisho pekee ndizo zilizochapishwa kwenye host.

Data huhifadhiwa katika volumes tano zenye majina: livecontext_data kwa ajili ya Postgres, livecontext_redis, livecontext_minio, livecontext_keys, na livecontext_logs. Compose huweka viambishi awali vya jina la mradi, ambalo kwa kawaida ni jina la saraka, kwa hivyo volume halisi kwenye diski huitwa kitu kama livecontext-ce_livecontext_minio. Endesha docker volume ls na unakili majina kamili kabla ya kuandika script yoyote ya backup dhidi yao.

docker compose down -v hufuta volumes zote tano. Hiyo ndiyo njia iliyoelekezwa ya kuanza upya, na pia ndiyo njia ya haraka zaidi ya kupoteza kila workflow uliyojenga. -v ndiyo tofauti nzima.

Iweke nyuma ya Traefik badala ya kuchapisha port 3000

Kuchapisha port 3000 na 8080 kwenye VPS ya umma hufichua programu bila TLS (transport layer security) na bila kizuizi chochote mbele ya usajili wa admin. Sheria ya ufw haitoshi yenyewe, kwa sababu Docker huingiza sheria zake za iptables kwa port zilizochapishwa mbele ya mnyororo unaosimamiwa na ufw, hivyo port iliyochapishwa kwenye 0.0.0.0 hubaki inafikika hata kama ufw inasema port hiyo imekataliwa.

Suluhisho safi ni kutochapisha chochote na kuruhusu proxy ifikie container kupitia mtandao wa Docker ulioshirikiwa. Unda docker-compose.override.yml kwenye mzizi wa repo:

services:
  frontend:
    ports: !override []
    networks:
      - default
      - proxy
  livecontext:
    ports: !override []
    networks:
      - default
      - proxy

networks:
  proxy:
    external: true

Maelezo mawili huamua kama hili litafanya kazi. !override huchukua nafasi ya orodha ya port badala ya kuungana nayo, jambo linalohitaji Compose v2.24 au mpya zaidi: thibitisha na docker compose version, kwa sababu kwenye Compose ya zamani orodha hizo mbili huungana na port hubaki zimechapishwa. Na default lazima ibaki katika kila orodha ya networks, kwa sababu kutaja mtandao wowote huchukua nafasi ya ule wa msingi, hivyo kuiacha nje kutatenganisha frontend na Postgres na Redis. Thibitisha matokeo yaliyounganishwa kabla ya kuanza chochote:

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

Router, certificate resolver na HTTP-to-HTTPS redirect ni sawa na kwa programu nyingine yoyote, kwa hivyo fuata mwongozo wetu wa Traefik reverse proxy wa kuendesha programu nyingi kwenye VPS moja badala ya kuandika usanidi mpya wa TLS hapa. Elekeza hostname moja kwenye frontend kwenye port 3000 na ya pili kwenye livecontext kwenye port 8080.

Hostname ya pili si ya hiari. Web UI huita backend kutoka kwenye kivinjari, kwa hivyo backend inahitaji asili (origin) yake yenyewe ambayo kivinjari kinaweza kuifikia. Weka GATEWAY_PUBLIC_URL katika docker/.env.ce kwenye URL hiyo ya backend, kwa mfano https://lc-api.example.com. Ukiiruka, ukurasa utapakia kawaida lakini kila kitendo kitashindwa, kwa sababu UI ilitatua asili ya backend kutoka kwenye anwani uliyofungulia na inaita port ambayo proxy yako haijawahi kuichapisha.

Kwa kuwa ukurasa wa kujisajili uko wazi kwa yeyote anayefika kwanza, inafaa kuweka auth mbele ya router ya frontend ili hakuna mtu anayeona ukurasa huo bila kuhakikiwa kwenye proxy, jambo ambalo kuendesha Authentik kama safu yako ya SSO huongeza juu ya usanidi uleule wa Traefik.

Mahali pa kuweka ufunguo wa model, na kwa nini instance iliyo idle bado inagharimu pesa

Agents huendeshwa ndani ya automation hapa, jambo linalobadilisha uchumi ikilinganishwa na zana ya kawaida ya workflow. Ufunguo wa provider huwekwa katika docker/.env.ce kama ANTHROPIC_API_KEY au OPENAI_API_KEY, husomwa na backend na bridge wakati wa kuanza, na hutumika kwa instance nzima. Haina wigo kwa kila mtumiaji. Mtu yeyote aliye na akaunti kwenye instance yako na anayeweza kujenga agent anatumia ufunguo huo, na mtu wa kwanza kujisajili ndiye admin.

Tabia tatu huifanya bili kuwa ya kutabirika. Tengeneza ufunguo wa provider tofauti kwa ajili ya VPS hii ili uweze kuubatilisha bila kugusa kitu kingine chochote. Weka kikomo cha matumizi (hard spend cap) katika console ya provider, kwa sababu kikomo hicho ndicho pekee kilicho nje ya mashine unayoilinda. Kisha tumia bajeti za mikopo kwa kila agent na metrics za kila agent ambazo LiveContext hutoa, ili loop moja isimalize ufunguo kabla hujagundua.

Gharama ya idle si sifuri pindi agent anapokuwa kwenye ratiba. Trigger ya ratiba huwaka bila kujali kama kuna mtu anayeitazama au la, na kila kuwaka hutuma tokens. Ratiba ya dakika tano ni sawa na runs 288 kwa siku, na agent anayesoma ukurasa na kuamua kutofanya lolote bado hulipia kusoma ukurasa huo. Weka agents wako wa kwanza kwenye webhook au chat trigger, fuatilia matumizi halisi kwa wiki moja, na uende kwenye ratiba baada ya kujua gharama ya kila run.

Hifadhi nakala ya Postgres na object store

Kuna hifadhi mbili za data pamoja na siri moja, na kupoteza yoyote kati ya hizo tatu kutasababisha kupoteza instance yako. Hifadhi database na bucket katika dirisha moja, huku backend ikiwa imesimamishwa, ili faili lisiweze kuandikwa baada ya safu yake ya database kutolewa (dumped).

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

Tumia chochote ulichoweka kama DB_USERNAME badala ya postgres ikiwa ulibadilisha. Kisha nakili volume ya object store, kwa kutumia jina lenye prefix ambalo docker volume ls ilichapisha:

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)

Hakikisha dump si tupu kabla ya kuiamini: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 inapaswa kuonyesha taarifa za CREATE TABLE na DROP TABLE, si hitilafu ya mstari mmoja. Kisha nakili faili zote tatu nje ya seva. Nakala ya akiba inayokaa kwenye mashine inayoilinda pekee si nakala ya akiba.

Ili kurejesha kwenye mashine mpya, sakinisha tag ileile, rudisha docker/.env.ce uliyohifadhi ili nenosiri la usimbaji wa vitambulisho na salt vilingane, anzisha stack mara moja ili volumes ziwepo, simamisha backend, kisha pakia 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

Uboreshaji, na kurejesha hali ya awali wakati kitu kinapoharibika

Chukua dump kwanza, kila wakati. Backend hutumia schema migrations wakati wa kuanza na migrations husonga mbele pekee, kwa hivyo kurudi kwenye tag ya zamani baada ya uboreshaji mbaya kutasababisha code ya zamani kufanya kazi na schema mpya. Rollback inamaanisha kurejesha dump, ndiyo maana dump hufanyika kwanza.

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

Weka TAG kwenye tag uliyochagua kutoka kwenye orodha iliyochapishwa na amri ya tatu. Fuatilia log ya backend hadi endpoint ya health itakapojibu tena. docker-compose.override.yml yako haifuatiliwi (untracked), kwa hivyo git checkout huiacha kama ilivyo, lakini soma diff kwenye docker-compose.yml kati ya tags, kwa sababu huduma mpya au iliyobadilishwa jina inaweza kufanya override yako isifae bila ujumbe wowote wa hitilafu.

Njia za kushindwa, pamoja na ujumbe utakaouona

Container inaendelea kuanza upya na docker compose ps inaonyesha exited (137). Hiyo ni ishara ya kernel out-of-memory killer, na docker inspect livecontext-app inathibitisha hilo kwa "OOMKilled": true kwenye block ya state. Backend imefikia kikomo chake cha 1536M, au seva mwenyeji (host) imepungukiwa na kumbukumbu kwanza. Kagua free -m kabla ya kuongeza kikomo chochote, kwa sababu kuongeza kikomo cha container kwenye seva isiyo na nafasi ya ziada kutahamisha tu tatizo la kuzimwa kwa container nyingine.

Uvutaji (pull) unashindwa na no matching manifest for linux/arm64/v8 in the manifest list entries. Image hizi zimechapishwa kwa ajili ya linux/amd64 pekee. VPS ya Arm haiwezi kuendesha stack hii kutoka kwenye image zilizochapishwa, na uigaji (emulation) kupitia QEMU ni polepole mno kwa JVM pamoja na Chromium. Hamia kwenye mpango wa x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. Kitu kingine kwenye seva mwenyeji tayari kinatumia port hiyo. Badilisha FRONTEND_PORT katika docker/.env.ce, au tumia override iliyo hapo juu na usichapishe chochote.

UI inafanya kazi lakini ombi la kuingia (login request) linashindwa baada ya kuongeza proxy. Kivinjari kinaita backend kwenye asili (origin) ambayo proxy yako haihudumii. Fungua kichupo cha mtandao (network tab) cha kivinjari na uangalie host ya ombi linaloshindwa. Weka GATEWAY_PUBLIC_URL kwenye URL ya umma ya backend na uunde upya container ya frontend, kwa sababu thamani hiyo inasomwa wakati wa kuanza.

Kila kitu kiko sawa lakini faili zilizopakiwa kwenye workflow zinatoweka. Hakikisha kuwa minio-init inaonyesha exited (0) badala ya code isiyo ya sifuri. Ikiwa bucket workflow-files haikuwahi kuundwa, backend haina mahali pa kuweka vitu.

Chagua kati ya LiveContext au n8n

Chagua LiveContext ikiwa wakala ndiye kiini: unataka modeli ijenge na kuendesha otomatiki, na unakubali gharama ya seva ya 8 GB na huduma ya Java. Chagua n8n ikiwa unataka mtiririko wa kazi (workflows) unaotabirika, maktaba kubwa ya nodi, na matumizi ya rasilimali yanayoruhusu kushiriki VPS na huduma nyingine. Nambari za toleo hapa bado ni changa, v0.2.11 kufikia Agosti 2026, kwa hivyo funga (pin) tag yako na usome maelezo ya toleo (release notes) kabla ya kila uboreshaji. Kwa wigo mpana zaidi, ikijumuisha zana zilizopo katikati ya chaguzi hizi mbili, angalia muhtasari wetu wa njia mbadala za n8n zinazojiendesha (self-hosted) badala ya kusoma ulinganisho wa hizi mbili pekee.

FAQ

LiveContext inayojiendesha yenyewe inahitaji RAM kiasi gani?

Tenga 8 GB. README ya msanidi inaorodhesha 4 GB kama kiwango cha chini na 8 GB kama pendekezo, na faili ya compose iliyopo inalingana na hilo: backend pekee imewekewa kikomo cha 1536 MB, na huduma tano za msingi kwa pamoja zinatumia chini kidogo ya 3 GB kabla ya kuhesabu container ya frontend isiyo na kikomo. Kuwezesha wasifu wa browser agent kunaongeza 2048 MB nyingine kwa ajili ya Chromium pamoja na container ya SearXNG, kwa hivyo 8 GB inakuwa hitaji la lazima katika hatua hiyo.

Je, ninaweza kuendesha LiveContext kwenye Arm VPS?

Hapana. Kila image iliyochapishwa imejengwa kwa ajili ya linux/amd64, kwa hivyo docker compose up kwenye mpango wa Arm inashindwa wakati wa pull ikiwa na no matching manifest for linux/arm64/v8 in the manifest list entries. Kuiendesha chini ya emulation ya QEMU inawezekana kinadharia lakini haifai kwa matumizi ya vitendo kwa mzigo wa kazi wa JVM. Chagua mpango wa x86.

Ninaweka wapi API key ya model yangu?

Ndani ya docker/.env.ce, kama ANTHROPIC_API_KEY, OPENAI_API_KEY au GOOGLE_API_KEY, kabla ya kuanza kwa mara ya kwanza. Backend na bridge huisoma wakati wa kuanza, na inatumika kwa mfumo mzima badala ya mtumiaji mmoja. Weka faili hiyo katika mode 600, tumia key iliyoundwa kwa ajili ya seva hii pekee ili uweze kuifuta yenyewe ikihitajika, na uweke kikomo cha matumizi (spend cap) kwenye console ya mtoa huduma, kwa sababu kikomo hicho ndicho pekee kilicho nje ya mashine.

Ninafanyaje backup ya LiveContext?

Mambo matatu: pg_dump ya database ya livecontext, nakala ya volume ya MinIO, na faili ya docker/.env.ce. Simamisha huduma za livecontext na frontend wakati unachukua nakala hizo mbili za kwanza ili database na object store viwe na data zinazolingana. Faili ya env ni muhimu kwa sababu credentials zilizohifadhiwa kwenye workflows zako zimesimbwa kwa CREDENTIAL_ENCRYPTION_PASSWORD na CREDENTIAL_ENCRYPTION_SALT, kwa hivyo kurejesha data (restore) bila thamani hizo kutasababisha safu za credential ambazo hakuna kitu kwenye mashine mpya kitakachoweza kuzisoma.

Kwa nini backend inakaa kwenye health: starting kwa dakika kadhaa baada ya boot?

Healthcheck ya compose huweka start_period: 120s na kupiga kura /actuator/health, kwa hivyo Docker inaripoti huduma kama inayoanza wakati migrations za schema na usajili wa zana (tool registration) vikiendelea. Dakika mbili hadi tatu wakati wa boot ya kwanza ni jambo la kawaida. Ikiwa haitawahi kuwa "healthy", soma docker compose logs -f livecontext. Stack inayokwama kwenye hatua ya migration kwa kawaida inaelekeza kwenye volume ya database kutoka toleo jipya zaidi.