Self-host LiveContext: Isang Alternatibo sa n8n

Ano ang LiveContext at magkano ang gastos sa pagpapatakbo nito

Para mag-self-host ng LiveContext, kailangan mo ng VPS na may humigit-kumulang 8 GB RAM. Ang LiveContext CE ay isang open source automation platform na nagpapatakbo ng AI agents sa loob mismo ng automation. Ipinapamahagi ito bilang Docker Compose stack na binubuo ng anim na container at nakasentro sa Java backend. Ayon sa upstream README, 4 GB ang minimum at 8 GB ang inirerekomenda. Ipinapakita ng compose file kung saan ginagamit ang memory na ito.

Makikita ang project sa livecontext-ai/livecontext-ce sa GitHub at lisensyado ito sa ilalim ng AGPL-3.0. Ang kasalukuyang release noong August 2026 ay v0.2.11, na inilabas noong 3 August 2026. Binuo ang bawat image para sa linux/amd64 lamang, kaya hindi magagamit ang murang Arm plans. Itinatakda ng guide na ito ang tag na iyon, inilalagay ang stack sa likod ng reverse proxy, at inilalarawan ang backup procedure na wala sa upstream docs.

Tukuyin ang laki ng VPS bago i-self-host ang LiveContext

Ang bawat service sa inilabas na compose file ay may tahasang memory limit, kaya matutukoy mo na ang laki ng server bago ito rentahan. Ang mga ito ang limit na nakasulat sa v0.2.11 compose file, hindi ang aktuwal na memory usage.

[
  {
    "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
  }
]

Ang backend lamang ay may limit na 1536 MB. Nakatakda ang limit na ito para sa isang Java 21 process, kaya gagamitin ng JVM ang malaking bahagi nito at mananatiling ganoon ang paggamit. Ang limang base service ay umaabot sa bahagyang mas mababa sa 3 GB, at walang limit ang frontend, kaya gagamit ito ng memory ayon sa hinihingi ng Node. Sa 4 GB VPS, halos wala nang matitira para sa kernel at page cache. Ito ang dahilan kung bakit 4 GB ang itinakdang minimum, hindi inirerekomendang laki.

Ang optional profiles ang nagtutulak sa kinakailangang laki ng server sa 8 GB. Nagdaragdag ang browser agent profile ng Chromium container na may limit na 2048 MB, kasama ng isang SearXNG search instance. Nagdaragdag naman ang renderer profile ng 1024 MB para sa screenshots at PDFs. Hindi magsisimula ang alinman sa mga ito maliban kung ie-enable mo ang profile nito, kaya panatilihing naka-off ang dalawa hanggang kailanganin mo ang mga ito.

Kung nagpapatakbo ka na ng n8n, planong palitan ito sa halip na idagdag ang LiveContext. Ang stack sa aming gabay sa pagpapatakbo ng n8n sa isang VPS gamit ang Docker at HTTPS ay binubuo ng isang Node process kasama ng Postgres, at maayos itong tumatakbo sa maliit na server. Mas malaking memory ang nirereserba ng LiveContext para sa backend lamang kaysa sa ginagamit ng buong stack na iyon. Magkakasya ang dalawang automation platform sa isang 8 GB VPS hanggang sa sabay silang magpatakbo ng job sa iisang minuto. Kung pagsasaluhan nila ang isang host, magtakda rin ng tahasang limits para sa lahat ng iba pang service, gamit ang paraan sa aming post tungkol sa pagtatakda ng memory limits sa Docker Compose, upang hindi mapabagsak ng isang runaway workflow ang buong machine.

Mag-install ng LiveContext gamit ang Docker Compose, naka-pin sa isang tag

Magsimula sa malinis na Ubuntu 24.04 VPS na may Docker Engine 24 o mas bago at Compose v2. Kung hindi pa naka-install ang Docker, sundin muna ang aming gabay sa mga pangunahing kaalaman ng Docker Compose para sa VPS, pagkatapos ay bumalik dito.

Nag-aalok ang README ng npx livecontext bilang one-line start. Ayos ito sa laptop. Sa server, dapat nasa directory na kontrolado mo ang compose file. Sa ganitong paraan, upgrade na ang pag-checkout ng git, at eksaktong makikita mo kung ano ang nagbago.

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

Naka-pin na ang bawat image ng compose file sa release tag nito, gaya ng ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Ang pag-checkout sa katugmang git tag ang nagpapanatiling tugma ng compose file at mga image, dahil ang compose file para sa v0.2.11 ay ginawa para sa mga image na iyon. Huwag baguhin ang mga tag sa latest. Nagbabago ang latest tag habang ginagamit mo ito, at pinapatakbo ng backend ang database migrations sa bawat start. Dahil dito, maaaring aksidenteng ma-pull ang bagong bersyon at maisulong ang schema mo alas-3 ng umaga, nang restore lamang ang paraan para makabalik.

I-edit ang docker/.env.ce bago ang unang start. Nasa susunod na seksyon ang mga kailangang baguhin. Pagkatapos, i-start ang stack.

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

Gamitin ang parehong --env-file flag sa bawat compose command sa gabay na ito. Binabasa muli ng Compose ang file sa bawat invocation. Kaya kapag walang flag ang isang command, gagamitin nito ang mga default na nasa compose file at maaaring mag-publish ng ibang ports kaysa sa mga na-configure mo.

May start_period na 120s ang backend healthcheck at tine-test nito ang /actuator/health. Dahil dito, iniuulat ng docker compose ps ang livecontext service bilang health: starting sa humigit-kumulang unang dalawang minuto habang tumatakbo ang schema migrations at tool registration. Normal ito. Isang mabilis na check mula sa server:

curl -s localhost:8080/actuator/health

Dapat nitong i-print ang {"status":"UP"}. Kapag lumabas ito, buksan ang web UI sa port 3000. Ang unang account na gagawin mo ang magiging admin, kaya gawin ito bago maging reachable ng iba ang port. Ito ang pinakamahalagang dahilan para huwag i-publish ang port 3000 sa internet sa unang araw.

Ang mga env value na kailangan mong baguhin

May gumaganang default ang example file upang magsimula ang stack sa isang laptop. Hindi ligtas ang ilan sa mga ito kapag public server ang gamit.

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

Bumuo ng bawat random value gamit ang openssl rand -base64 32. Mga dapat tandaan sa mga setting na maaaring magdulot ng problema:

• Ang POSTGRES_PASSWORD at MINIO_ROOT_PASSWORD ay may default na postgres at minioadmin. Hindi naka-publish sa host ang alinmang database port, kaya hindi direktang exposed ang mga ito. Gayunpaman, maa-access ng anumang container na ikokonekta mo sa parehong network ang dalawang port gamit ang documented default.
• Awtomatikong binubuo ang CREDENTIAL_ENCRYPTION_PASSWORD at CREDENTIAL_ENCRYPTION_SALT kapag iniwang walang laman. Ikaw mismo ang magtakda sa mga ito. Ini-encrypt ang credentials na sine-save ng iyong workflows gamit ang pares na iyon. Kaya kung ire-restore ang database dump sa bagong machine nang hindi ginagamit ang parehong password at salt, magkakaroon ka ng credential rows na walang makakabasa. Itakda ang mga ito nang isang beses, at ituring ang docker/.env.ce bilang bahagi ng backup.
• Ipinapasok ang FRONTEND_PORT at BACKEND_PORT sa port mappings bilang ${FRONTEND_PORT:-3000}:3000 at ${BACKEND_PORT:-8080}:8080. Tahasang itinatakda ng example env file ang dalawa, at hindi laging 3000 at 8080 ang mga value na kasama nito. Basahin ang sarili mong kopya sa halip na mag-assume.
• Ang GATEWAY_PUBLIC_URL ang origin ng backend na ginagamit ng browser. Mahalaga ito kapag may reverse proxy. Tingnan ang susunod na section.
• Nasa plain text dito ang mga model key (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY, at opsyonal na MISTRAL_API_KEY o DEEPSEEK_API_KEY). Ilagay lamang ang provider na aktuwal mong ginagamit.

Ano ang ginagawa ng anim na container

• postgres ang nagpapatakbo ng pgvector/pgvector:pg16 bilang container na livecontext-db. Dito nakaimbak ang database na livecontext. Ginagamit ang pgvector extension para sa embedding search, kaya hindi sapat ang plain na postgres:16 image.
• redis ang nagpapatakbo ng redis:7-alpine kasama ang appendonly yes at --maxmemory-policy noeviction. Sadyang ganoon ang policy na ito: naglalaman ang Redis ng queue at run state dito, kaya kapag umabot ito sa memory ceiling, nagbabalik ito ng error sa writer sa halip na tahimik na mag-drop ng mga key. Mas mabuti ang error na makikita mo kaysa sa trabahong nawawala nang walang abiso.
• minio ang S3-compatible object store para sa mga file na dumadaan sa workflows. Isang one-shot na minio-init container ang nagpapatakbo ng mc mb myminio/workflow-files --ignore-existing sa startup, gumagawa ng bucket, at lumalabas. Ang makita ang minio-init bilang exited (0) sa docker compose ps ang tamang healthy state.
• bridge ang naglalaman ng CLI adapters at mga MCP (model context protocol) tool. Nakikinig ito sa 8093 sa loob ng Docker network at hindi ito inilalabas sa host.
• livecontext ang backend: isang Java 21 monolith sa port 8080. Pinapatakbo nito ang workflow engine, mga scheduler, at mga agent.
• frontend ang Next.js web UI sa port 3000. Ang dalawang ito lamang ang inilalabas sa host.

Nasa limang named volume ang state: livecontext_data para sa Postgres, livecontext_redis, livecontext_minio, livecontext_keys, at livecontext_logs. Nilalagyan ng Compose ng project name ang prefix ng mga ito. Bilang default, pangalan ito ng directory, kaya ang aktuwal na volume sa disk ay may pangalang gaya ng livecontext-ce_livecontext_minio. Patakbuhin ang docker volume ls at kopyahin ang eksaktong mga pangalan bago ka gumawa ng anumang backup script para sa mga ito.

Ide-delete ng docker compose down -v ang lahat ng limang volume. Ito ang dokumentadong paraan para magsimula muli, at ito rin ang pinakamabilis na paraan para mawala ang lahat ng workflow na ginawa mo. Ang -v ang buong kaibahan.

Ilagay ito sa likod ng Traefik sa halip na i-publish ang port 3000

Ang pag-publish ng mga port 3000 at 8080 sa isang public VPS ay naglalantad sa app nang walang TLS (transport layer security) at walang gate bago ang admin registration. Hindi sapat ang isang ufw rule, dahil naglalagay ang Docker ng sarili nitong iptables rules para sa mga published port bago ang chain na mina-manage ng ufw. Dahil dito, nananatiling reachable ang port na naka-publish sa 0.0.0.0 kahit sinasabi ng ufw na denied ang port.

Ang malinis na solusyon ay walang i-publish na port at hayaan ang proxy na maabot ang mga container sa shared Docker network. Gumawa ng docker-compose.override.yml sa repo root:

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

networks:
  proxy:
    external: true

Dalawang detalye ang tumutukoy kung gagana ito. Pinapalitan ng !override ang ports list sa halip na i-merge ito, at kailangan nito ang Compose v2.24 o mas bago: tingnan gamit ang docker compose version, dahil sa mas lumang Compose ay nami-merge ang dalawang list at nananatiling published ang mga port. Kailangan ding manatili ang default sa bawat networks list, dahil kapag pinangalanan ang isang network, pinapalitan nito ang default network. Kapag iniwan ito, mawawalan ng koneksyon ang frontend sa Postgres at Redis. Kumpirmahin ang merged result bago magsimula ng anuman:

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

Pareho ang routers, certificate resolver, at HTTP to HTTPS redirect sa ginagamit para sa ibang app. Sundin ang aming Traefik reverse proxy guide para magpatakbo ng maraming app sa isang VPS sa halip na gumawa ng bagong TLS config dito. I-route ang isang hostname sa frontend sa port 3000 at ang pangalawang hostname sa livecontext sa port 8080.

Hindi optional ang pangalawang hostname. Tinatawag ng web UI ang backend mula sa browser, kaya kailangan ng backend ng sarili nitong origin na maaabot ng browser. Itakda ang GATEWAY_PUBLIC_URL sa docker/.env.ce bilang backend URL, halimbawa https://lc-api.example.com. Kapag nilaktawan ito, normal na maglo-load ang page pero mabibigo ang bawat action, dahil nireresolve ng UI ang backend origin batay sa address na binuksan mo at tumatawag ito sa port na hindi kailanman ipinublish ng proxy.

Dahil bukas ang sign-up page sa unang makakaabot dito, mainam na maglagay ng forward auth sa frontend router upang walang makakita sa page na iyon nang hindi muna nag-a-authenticate sa proxy. Ito ang idinadagdag ng pagpapatakbo ng Authentik bilang sarili mong SSO layer sa parehong Traefik setup.

Saan inilalagay ang model key, at bakit may gastos pa rin ang idle instance

Tumatakbo ang mga agent sa loob ng automation dito, kaya iba ang economics nito kumpara sa isang plain workflow tool. Nasa docker/.env.ce ang provider key bilang ANTHROPIC_API_KEY o OPENAI_API_KEY. Binabasa ito ng backend at ng bridge sa startup, at nalalapat ito sa buong instance. Hindi ito naka-scope bawat user. Sinumang may account sa iyong instance at makakagawa ng agent ay gumagamit ng key na iyon, at ang unang mag-register ay nagiging admin.

Tatlong gawain ang nakatutulong upang maging predictable ang bill. Gumawa ng hiwalay na provider key para sa VPS na ito upang ma-revoke mo ito nang hindi naaapektuhan ang iba. Magtakda ng hard spend cap sa provider console, dahil ang limitasyong iyon lamang ang nasa labas ng machine na sine-secure mo. Gamitin din ang per-agent credit budget at per-agent metrics na inilalabas ng LiveContext, upang hindi maubos ng isang loop ang key bago mo ito mapansin.

Hindi zero ang idle cost kapag may schedule ang isang agent. Nagti-trigger ang schedule kahit walang nagmo-monitor, at bawat trigger ay nagpapadala ng tokens. Ang limang minutong schedule ay 288 runs bawat araw. May bayad pa rin ang agent na nagbabasa ng page at nagpapasyang walang gawin, dahil binayaran ang pagbasa sa page. Ilagay muna ang mga unang agent sa webhook o chat trigger. Subaybayan ang aktuwal na gastos sa loob ng isang linggo, at lumipat sa schedule kapag alam mo na ang gastos bawat run.

I-back up ang Postgres at object store

May dalawang data store at isang secret. Kapag nawala ang alinman sa tatlo, mawawala ang iyong instance. Kunin ang database at bucket sa parehong window, habang nakahinto ang backend. Sa ganitong paraan, walang file na maisusulat matapos ma-dump ang katumbas nitong database row.

cd ~/livecontext-ce
mkdir -p ~/backups
docker compose --env-file docker/.env.ce stop livecontext frontend
docker compose --env-file docker/.env.ce exec -T postgres \
  pg_dump -U postgres -d livecontext --clean --if-exists \
  | gzip > ~/backups/livecontext-db-$(date +%F).sql.gz

Gamitin ang itinakda mo bilang DB_USERNAME kapalit ng postgres kung binago mo ito. Pagkatapos, kopyahin ang object store volume gamit ang prefixed name na ipinakita ng 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)

Tiyaking hindi empty ang dump bago mo ito pagkatiwalaan: dapat ipakita ng gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 ang CREATE TABLE at DROP TABLE statements, hindi isang one-line error. Pagkatapos, kopyahin ang lahat ng tatlong file palabas ng server. Ang backup na nasa machine lamang na pinoprotektahan nito ay hindi tunay na backup.

Para mag-restore sa bagong box, i-install ang parehong tag, ibalik ang naka-save na docker/.env.ce upang magtugma ang credential encryption password at salt, simulan nang isang beses ang stack upang malikha ang mga volume, ihinto ang backend, at pagkatapos ay i-load ang 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

Mga Upgrade at Pagbabalik Kapag May Nagkaproblema

Laging gumawa muna ng dump. Awtomatikong ina-apply ng backend ang schema migrations nito sa startup, at pasulong lamang ang mga migration. Kaya kapag nag-check out ka sa mas lumang tag matapos ang maling upgrade, tatakbo ang lumang code laban sa mas bagong schema. Ang rollback ay nangangahulugang pag-restore ng dump. Iyon ang dahilan kung bakit nauuna ang 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

Itakda ang TAG sa tag na pinili mo mula sa listing na inilabas ng ikatlong command. I-monitor ang backend log hanggang muling makatugon ang health endpoint. Untracked ang iyong docker-compose.override.yml, kaya mananatili ito kapag nagsagawa ng git checkout. Gayunman, basahin ang diff sa docker-compose.yml sa pagitan ng mga tag, dahil maaaring maging stale ang override mo kapag may bagong service o may pinalitang pangalan ng service, kahit walang error message.

Mga failure mode at mga string na makikita mo

Paulit-ulit na nagre-restart ang container at ipinapakita ng docker compose ps ang exited (137). Ito ang kernel out-of-memory killer, at kinukumpirma ito ng docker inspect livecontext-app sa pamamagitan ng "OOMKilled": true sa state block. Naabot ng backend ang 1536M limit nito, o naubusan muna ng memory ang host. Suriin ang free -m bago magtaas ng anumang limit, dahil ang pagtataas ng container limit sa host na wala nang ekstrang memory ay maglilipat lang ng kill sa ibang container.

Nabibigo ang pull at ipinapakita ang no matching manifest for linux/arm64/v8 in the manifest list entries. Para lamang sa linux/amd64 na mga platform na-publish ang mga image. Hindi kayang patakbuhin ng Arm VPS ang stack na ito mula sa mga na-publish na image, at napakabagal ng emulation sa pamamagitan ng QEMU para sa JVM at Chromium. Lumipat sa x86 plan.

Bind for 0.0.0.0:3000 failed: port is already allocated. May ibang process sa host na gumagamit na ng port na iyon. Baguhin ang FRONTEND_PORT sa docker/.env.ce, o ilapat ang override sa itaas at huwag nang mag-publish ng anumang port.

Gumagana ang UI pero nabibigo ang login request matapos mong idagdag ang proxy. Tinatawag ng browser ang backend gamit ang origin na hindi sini-serve ng proxy mo. Buksan ang network tab ng browser at tingnan ang host ng nabibigong request. Itakda ang GATEWAY_PUBLIC_URL sa public backend URL at muling gawin ang frontend container, dahil binabasa ang value na iyon sa startup.

Maayos ang lahat pero nawawala ang mga file na ina-upload sa isang workflow. Tiyaking ipinapakita ng minio-init ang exited (0) sa halip na non-zero code. Kung hindi kailanman nalikha ang bucket na workflow-files, walang paglalagyan ng objects ang backend.

Piliin ang LiveContext o n8n

Piliin ang LiveContext kapag ang agent ang pangunahing pokus: gusto mong buuin at patakbuhin ng model ang automation, at tanggap mong kapalit nito ang isang 8 GB box at Java service. Piliin ang n8n kapag gusto mo ng deterministic workflows, malaking node library, at footprint na maaaring makihati sa isang VPS sa iba pang serbisyo. Bago pa lamang ang mga version number dito, v0.2.11 noong August 2026, kaya i-pin ang iyong tag at basahin ang release notes bago ang bawat upgrade. Para sa mas malawak na pagpipilian, kabilang ang mga tool na nasa pagitan ng dalawang ito, tingnan ang aming roundup ng mga self-hosted na alternatibo sa n8n sa halip na paghambingin lamang ang dalawang ito.

FAQ

Gaano karaming RAM ang kailangan ng isang self-hosted LiveContext?

Maglaan ng 8 GB. Itinatala ng upstream README ang 4 GB bilang minimum at 8 GB bilang rekomendasyon, at tugma rito ang kasamang compose file: ang backend lamang ay may limitasyong 1536 MB, habang ang limang base service ay umaabot sa bahagyang mas mababa sa 3 GB bago isama ang frontend container na walang limitasyon. Kapag na-enable ang browser agent profile, nagdadagdag ito ng 2048 MB para sa Chromium at isang SearXNG container. Sa puntong iyon, kailangan na ang 8 GB.

Maaari ko bang patakbuhin ang LiveContext sa isang Arm VPS?

Hindi. Ang bawat published image ay binuo para sa linux/amd64, kaya docker compose up sa isang Arm plan ay nabibigo sa pull at lumalabas ang no matching manifest for linux/arm64/v8 in the manifest list entries. Posible ito sa teorya gamit ang QEMU emulation, pero hindi praktikal para sa isang JVM workload. Pumili ng x86 plan.

Saan ko ilalagay ang model API key ko?

Sa docker/.env.ce, bilang ANTHROPIC_API_KEY, OPENAI_API_KEY, o GOOGLE_API_KEY, bago ang unang pagsisimula. Binabasa ito ng backend at bridge sa startup, at nalalapat ito sa buong instance sa halip na sa isang user lamang. Panatilihin ang file sa mode 600. Gumamit ng key na ginawa lamang para sa server na ito para mabawi mo ito nang hiwalay kung kinakailangan. Magtakda rin ng spend cap sa provider console, dahil ang cap na iyon lamang ang limitasyong nasa labas ng machine.

Paano ko iba-back up ang LiveContext?

Tatlong bagay: isang pg_dump ng livecontext database, kopya ng MinIO volume, at ang docker/.env.ce file. Ihinto ang livecontext at frontend service habang kinukuha ang unang dalawang backup upang magkatugma ang database at object store. Mahalaga ang env file dahil naka-encrypt gamit ang CREDENTIAL_ENCRYPTION_PASSWORD at CREDENTIAL_ENCRYPTION_SALT ang mga credential na naka-store sa iyong workflows. Kung magre-restore nang wala ang mga value na ito, mananatili ang mga credential row na hindi mababasa ng anumang component sa bagong machine.

Bakit nananatili ang backend sa health: starting nang ilang minuto pagkatapos ng boot?

Itinatakda ng compose healthcheck ang start_period: 120s at nagpo-poll sa /actuator/health, kaya iniuulat ng Docker na nagsisimula pa ang service habang tumatakbo ang schema migrations at tool registration. Inaasahan ang dalawa hanggang tatlong minuto sa unang boot. Kung hindi ito kailanman magiging healthy, basahin ang docker compose logs -f livecontext. Karaniwang nakaturo sa database volume mula sa mas bagong release ang stack kapag humihinto ito sa migration step.