가이드

작성자 Matt Connor 2026-08-10 · 업데이트됨 2026-08-13

LiveContext 셀프 호스팅 가이드: Docker 구성 및 백업

Q: 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 플랜을 선택하십시오.

Q: 모델 API 키는 어디에 입력하는가?

첫 실행 전에 docker/.env.ce 내의 ANTHROPIC_API_KEY, OPENAI_API_KEY 또는 GOOGLE_API_KEY에 입력하십시오. 백엔드와 브리지는 시작 시점에 이를 읽어 들이며, 특정 사용자가 아닌 인스턴스 전체에 적용됩니다. 파일 권한은 600으로 유지하고, 이 서버 전용으로 생성한 키를 사용하여 필요 시 개별적으로 취소할 수 있도록 하십시오. 또한 공급자 콘솔에서 사용량 한도를 설정하십시오. 해당 한도만이 서버 외부에서 작동하는 유일한 제한 장치입니다.

Q: LiveContext는 어떻게 백업하는가?

세 가지가 필요합니다. livecontext 데이터베이스의 pg_dump, MinIO 볼륨의 복사본, 그리고 docker/.env.ce 파일입니다. 데이터베이스와 객체 저장소 간의 일관성을 유지하기 위해 처음 두 가지를 백업하는 동안 livecontext 및 frontend 서비스를 중지하십시오. env 파일이 중요한 이유는 워크플로우에 저장된 자격 증명이 CREDENTIAL_ENCRYPTION_PASSWORD 및 CREDENTIAL_ENCRYPTION_SALT로 암호화되어 있기 때문입니다. 이 값들 없이 복원하면 새 서버에서 읽을 수 없는 자격 증명 행만 남게 됩니다.

Q: 부팅 후 백엔드가 왜 몇 분 동안 health: starting 상태로 머무르는가?

compose 헬스체크가 start_period: 120s를 설정하고 /actuator/health을 폴링하기 때문에, 스키마 마이그레이션과 도구 등록이 진행되는 동안 Docker는 해당 서비스를 시작 중인 것으로 보고합니다. 첫 부팅 시 2~3분 정도 소요되는 것은 정상입니다. 만약 상태가 정상으로 바뀌지 않는다면 docker compose logs -f livecontext을 확인하십시오. 마이그레이션 단계에서 멈추는 스택은 대개 더 최신 릴리스의 데이터베이스 볼륨을 참조하고 있는 경우입니다.

LiveContext CE를 직접 운영하기 위한 8GB RAM 서버 사양 산정법과 Docker Compose 설정, Traefik 리버스 프록시 배치 및 데이터 백업 절차를 상세히 안내합니다.

LiveContext의 정의 및 운영 비용

LiveContext를 직접 호스팅하려면 약 8 GB의 RAM을 갖춘 VPS가 필요합니다. LiveContext CE는 자동화 내부에서 AI 에이전트를 실행하는 오픈 소스 자동화 플랫폼이며, Java 백엔드를 중심으로 구성된 6개의 컨테이너로 이루어진 Docker Compose 스택 형태로 제공됩니다. 업스트림 README에서는 최소 4 GB, 권장 8 GB의 메모리를 요구하며, compose 파일에서 해당 메모리가 어떻게 할당되는지 확인할 수 있습니다.

이 프로젝트는 GitHub의 livecontext-ai/livecontext-ce에 위치하며 AGPL-3.0 라이선스를 따릅니다. 2026년 8월 기준 최신 릴리스는 2026년 8월 3일에 게시된 v0.2.11입니다. 모든 이미지는 linux/amd64 전용으로 빌드되므로 저렴한 Arm 플랜은 사용할 수 없습니다. 이 가이드는 해당 태그를 고정하고, 스택을 리버스 프록시 뒤에 배치하며, 업스트림 문서에 포함되지 않은 백업 절차를 다룹니다.

LiveContext를 셀프 호스팅하기 전 VPS 크기 산정하기

제공되는 compose 파일의 모든 서비스에는 명시적인 메모리 제한이 설정되어 있으므로, 서버를 임대하기 전에 필요한 사양을 미리 산정할 수 있습니다. 이 제한 값은 실제 측정된 사용량이 아니라 v0.2.11 compose 파일에 기록된 설정값입니다.

ChartMemory limits in the LiveContext CE v0.2.11 compose file, MB

label

memory_limit_mb

livecontext (backend)

1536

bridge

512

redis

384

postgres

256

minio

256

websearch (optional)

2048

searxng (optional)

512

renderer (optional)

1024

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
  }
]

백엔드 단독으로 1536 MB의 제한이 걸려 있습니다. 이 제한은 Java 21 프로세스에 적용되므로, JVM은 할당된 메모리의 대부분을 점유하고 유지하게 됩니다. 5개의 기본 서비스 합계는 3 GB에 조금 못 미치며, 프론트엔드는 별도의 제한이 없어 Node가 요청하는 만큼 메모리를 사용합니다. 4 GB VPS에서는 커널과 페이지 캐시를 위한 공간이 거의 남지 않기 때문에, 4 GB는 권장 사양이 아닌 최소 사양으로 명시되어 있습니다.

선택적 프로파일을 사용하면 서버 사양을 8 GB까지 높여야 합니다. 브라우저 에이전트 프로파일은 SearXNG 검색 인스턴스 옆에 2048 MB로 제한된 Chromium 컨테이너를 추가하며, 렌더러 프로파일은 스크린샷과 PDF 생성을 위해 1024 MB를 추가로 사용합니다. 두 프로파일 모두 활성화하지 않으면 시작되지 않으므로, 필요할 때까지는 꺼두는 것이 좋습니다. SearXNG 컨테이너는 에이전트의 검색 백엔드 역할을 하므로, 반환되는 페이지는 신뢰할 수 없는 텍스트로 프롬프트에 전달됩니다. 이는 AI 에이전트에게 SearXNG 웹 검색 권한 부여하기에서 상세히 다루는 신뢰 경계 문제입니다.

이미 n8n을 운영 중이라면, 기존 환경에 추가하기보다 대체할 계획을 세우는 것이 좋습니다. Docker와 HTTPS를 사용하여 VPS에서 n8n을 실행하는 가이드의 스택은 Postgres와 함께 하나의 Node 프로세스로 구성되어 작은 서버에서도 원활하게 동작합니다. LiveContext는 백엔드 하나만으로도 해당 스택 전체가 사용하는 것보다 더 많은 메모리를 예약합니다. 8 GB VPS 하나에 두 개의 자동화 플랫폼을 함께 운영하면 두 서비스가 동시에 작업을 수행하는 순간 메모리 부족이 발생할 수 있습니다. 만약 호스트를 공유해야 한다면, Docker Compose에서 메모리 제한 설정하기 게시물의 방법을 사용하여 다른 모든 서비스에도 명시적인 제한을 설정하십시오. 그래야 하나의 워크플로우가 폭주하더라도 서버 전체가 다운되는 상황을 방지할 수 있습니다.

Docker Compose를 사용하여 LiveContext 설치하기 (태그 고정)

Docker Engine 24 이상과 Compose v2가 설치된 깨끗한 Ubuntu 24.04 VPS에서 시작합니다. Docker가 아직 설치되지 않았다면 먼저 VPS를 위한 Docker Compose 기초를 따라 설치한 뒤 돌아오십시오.

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 파일에 내장된 기본값으로 돌아가며, 설정한 포트와 다른 포트가 게시될 수 있습니다.

백엔드 상태 확인(healthcheck)은 start_period가 120s이며 /actuator/health을 폴링합니다. 따라서 스키마 마이그레이션과 도구 등록이 진행되는 처음 2분 동안은 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는 비워두면 자동으로 생성됩니다. 대신 직접 설정하십시오. 워크플로우가 저장하는 자격 증명은 이 쌍으로 암호화되므로, 동일한 비밀번호와 salt 없이 새 서버에 데이터베이스 덤프를 복원하면 자격 증명 행을 읽을 수 없게 됩니다. 한 번 설정한 후에는 docker/.env.ce를 백업의 일부로 관리하십시오.
FRONTEND_PORT과 BACKEND_PORT은 포트 매핑에서 ${FRONTEND_PORT:-3000}:3000과 ${BACKEND_PORT:-8080}:8080로 치환됩니다. 예제 env 파일은 두 값을 명시적으로 설정하며, 제공되는 값이 항상 3000이나 8080은 아닙니다. 기본값을 가정하지 말고 본인의 파일을 직접 확인하십시오.
GATEWAY_PUBLIC_URL은 브라우저에서 바라보는 백엔드의 오리진입니다. 리버스 프록시를 사용할 때 중요하게 작용합니다. 다음 섹션을 참조하십시오.
모델 키(ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY 및 선택적으로 MISTRAL_API_KEY 또는 DEEPSEEK_API_KEY)는 이곳에 일반 텍스트로 저장됩니다. 실제로 사용하는 제공업체의 키만 입력하십시오.

6개 컨테이너의 역할

postgres은 pgvector/pgvector:pg16을 livecontext-db 컨테이너로 실행하며, livecontext라는 이름의 데이터베이스를 유지합니다. 임베딩 검색을 위해 pgvector 확장이 포함되어 있으므로, 일반 postgres:16 이미지는 사용할 수 없습니다.
redis은 redis:7-alpine를 appendonly yes 및 --maxmemory-policy noeviction와 함께 실행합니다. 이러한 정책은 의도된 것입니다. Redis는 여기서 큐와 실행 상태를 관리하며, 메모리 한계에 도달하면 키를 조용히 삭제하는 대신 작성자에게 오류를 반환합니다. 사라진 작업보다는 눈에 보이는 오류가 훨씬 낫기 때문입니다.
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입니다. 마지막 두 컨테이너만 호스트에 공개됩니다.

상태 데이터는 5개의 명명된 볼륨에 저장됩니다: Postgres용 livecontext_data, 그리고 livecontext_redis, livecontext_minio, livecontext_keys, livecontext_logs입니다. Compose는 프로젝트 이름을 접두사로 붙이며, 기본값은 디렉터리 이름이므로 디스크상의 실제 볼륨 이름은 livecontext-ce_livecontext_minio와 같은 형태가 됩니다. 백업 스크립트를 작성하기 전에 docker volume ls을 실행하여 정확한 이름을 확인하십시오.

docker compose down -v은 5개의 볼륨을 모두 삭제합니다. 이는 처음부터 다시 시작하는 공식적인 방법이지만, 동시에 구축한 모든 워크플로우를 잃는 가장 빠른 방법이기도 합니다. -v가 그 모든 차이를 만듭니다.

포트 3000을 공개하는 대신 Traefik 뒤에 배치하기

공개 VPS에서 포트 3000과 8080을 직접 공개하면 TLS(transport layer security) 없이 애플리케이션이 노출되며, 관리자 등록 페이지 앞단에 아무런 보호 장치도 없게 됩니다. Docker는 ufw가 관리하는 체인보다 앞서서 공개된 포트에 대한 자체 iptables 규칙을 삽입하므로, ufw에서 포트 차단을 설정하더라도 0.0.0.0로 공개된 포트는 여전히 접근 가능하기 때문에 ufw 규칙만으로는 충분하지 않습니다.

가장 깔끔한 해결책은 포트를 전혀 공개하지 않고, 공유 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 리버스 프록시 가이드를 따르십시오. 하나의 호스트네임은 포트 3000의 frontend으로, 다른 하나는 포트 8080의 livecontext으로 라우팅하십시오.

두 번째 호스트네임은 선택 사항이 아닙니다. 웹 UI는 브라우저에서 백엔드를 호출하므로, 백엔드는 브라우저가 도달할 수 있는 고유한 오리진이 필요합니다. docker/.env.ce의 GATEWAY_PUBLIC_URL를 해당 백엔드 URL(예: https://lc-api.example.com)로 설정하십시오. 이 설정을 건너뛰면 페이지는 정상적으로 로드되지만 모든 작업이 실패합니다. UI가 접속한 주소를 기반으로 백엔드 오리진을 해석하는데, 프록시가 해당 포트를 공개하지 않았기 때문입니다.

가입 페이지는 누구에게나 열려 있으므로, 프록시 단계에서 인증을 거치지 않으면 아무도 해당 페이지를 볼 수 없도록 프론트엔드 라우터에 전방 인증(forward auth)을 적용하는 것이 좋습니다. 이는 SSO 계층으로 Authentik을 실행하는 방법을 통해 동일한 Traefik 설정 위에 추가할 수 있습니다.

모델 키의 위치와 유휴 인스턴스에 비용이 발생하는 이유

에이전트는 자동화 내부에서 실행되며, 이는 일반적인 워크플로우 도구와 비교했을 때 경제적 측면에서 차이를 만듭니다. 공급자 키는 docker/.env.ce에 ANTHROPIC_API_KEY 또는 OPENAI_API_KEY로 저장되며, 시작 시 백엔드와 브리지에 의해 읽혀 인스턴스 전체에 적용됩니다. 이 키는 사용자별로 범위가 지정되지 않습니다. 인스턴스 계정을 보유하고 에이전트를 빌드할 수 있는 모든 사용자가 해당 키를 사용하여 비용을 발생시키며, 가장 먼저 등록한 사용자가 관리자가 됩니다.

세 가지 습관을 통해 비용을 예측 가능한 수준으로 유지할 수 있습니다. 첫째, 이 VPS를 위한 별도의 공급자 키를 생성하여 다른 설정에 영향을 주지 않고 키를 취소할 수 있도록 합니다. 둘째, 공급자 콘솔에서 엄격한 지출 한도를 설정하십시오. 이 한도만이 시스템 외부에서 비용을 제어할 수 있는 유일한 수단입니다. 셋째, LiveContext가 제공하는 에이전트별 크레딧 예산과 에이전트별 메트릭을 사용하여 단일 루프가 인지하기 전에 키의 잔액을 모두 소진하지 않도록 하십시오.

에이전트가 스케줄에 등록되면 유휴 상태라도 비용은 0이 아닙니다. 스케줄 트리거는 사용자의 확인 여부와 관계없이 작동하며, 실행될 때마다 토큰이 소모됩니다. 5분 단위 스케줄은 하루에 288번 실행되며, 페이지를 읽고 아무 작업도 하지 않기로 결정한 에이전트라도 페이지를 읽는 비용은 지불해야 합니다. 초기 에이전트는 웹훅이나 채팅 트리거를 통해 실행하고, 일주일 동안 실제 지출을 모니터링한 뒤 실행당 비용을 파악한 후 스케줄 방식으로 전환하십시오.

Postgres 및 오브젝트 스토어 백업

데이터 저장소 2개와 비밀값 1개가 있으며, 이 셋 중 하나라도 유실되면 인스턴스를 복구할 수 없습니다. 데이터베이스 행이 덤프된 후 파일이 기록되는 것을 방지하기 위해 백엔드를 중지한 상태에서 데이터베이스와 버킷을 동일한 시점에 백업하십시오.

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 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를 다시 배치하여 자격 증명 암호화 비밀번호와 솔트(salt)가 일치하도록 하십시오. 스택을 한 번 시작하여 볼륨을 생성한 뒤 백엔드를 중지하고, 덤프를 로드하십시오.

gunzip -c livecontext-db-2026-08-10.sql.gz \
  | docker compose --env-file docker/.env.ce exec -T postgres psql -U postgres -d livecontext

업그레이드 및 문제 발생 시 복구 방법

항상 먼저 덤프를 생성하십시오. 백엔드는 시작 시 스키마 마이그레이션을 적용하며, 마이그레이션은 앞으로만 진행됩니다. 따라서 잘못된 업그레이드 후 이전 태그로 체크아웃하면 최신 스키마에서 이전 코드가 실행되는 문제가 발생합니다. 롤백은 덤프를 복원하는 것을 의미하므로, 덤프를 먼저 수행해야 합니다.

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를 세 번째 명령어가 출력한 목록에서 선택한 태그로 설정하십시오. 헬스 체크 엔드포인트가 다시 응답할 때까지 백엔드 로그를 모니터링하십시오. 사용자의 docker-compose.override.yml은 추적되지 않으므로 git checkout을 수행해도 그대로 유지됩니다. 하지만 태그 간의 docker-compose.yml 차이점을 반드시 확인하십시오. 새로운 서비스가 추가되거나 서비스 이름이 변경되면 오류 메시지 없이 기존 오버라이드 설정이 무용지물이 될 수 있습니다.

실패 유형 및 확인되는 메시지

컨테이너가 계속 재시작되고 docker compose ps에서 exited (137)이 표시됩니다. 이는 커널의 OOM(out-of-memory) 킬러가 작동한 것이며, docker inspect livecontext-app의 상태 블록에서 "OOMKilled": true를 통해 확인할 수 있습니다. 백엔드가 1536M 제한에 도달했거나 호스트의 메모리가 먼저 고갈된 경우입니다. 제한을 높이기 전에 free -m을 먼저 확인하십시오. 여유 자원이 없는 호스트에서 특정 컨테이너의 제한만 높이면 다른 컨테이너가 종료되는 결과만 초래합니다.

이미지 가져오기(pull)가 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을 변경하거나, 위에서 설명한 override를 적용하여 포트를 노출하지 않도록 설정하십시오.

UI는 정상이나 프록시 설정 후 로그인 요청이 실패합니다. 브라우저가 프록시에서 처리하지 않는 오리진으로 백엔드를 호출하고 있습니다. 브라우저의 네트워크 탭을 열어 실패하는 요청의 호스트를 확인하십시오. GATEWAY_PUBLIC_URL를 공개 백엔드 URL로 설정하고 프론트엔드 컨테이너를 다시 생성하십시오. 해당 값은 시작 시점에 읽어오기 때문입니다.

모든 상태는 정상이나 워크플로우에서 업로드한 파일이 사라집니다. minio-init의 결과가 0이 아닌 코드가 아닌 exited (0)인지 확인하십시오. 버킷 workflow-files가 생성되지 않았다면 백엔드가 객체를 저장할 공간이 없는 상태입니다.

LiveContext와 n8n 선택하기

에이전트가 핵심이라면 LiveContext를 선택하십시오. 모델이 자동화를 직접 구축하고 실행하기를 원하며, 8 GB 메모리 사양의 서버와 Java 서비스 운영을 감수할 수 있는 경우에 적합합니다. 결정론적 워크플로우, 방대한 노드 라이브러리, 그리고 다른 서비스와 VPS를 공유할 수 있는 가벼운 리소스 점유율이 필요하다면 n8n을 선택하십시오. 2026년 8월 기준 v0.2.11으로 버전이 아직 초기 단계이므로, 태그를 고정하고 업그레이드할 때마다 릴리스 노트를 확인하십시오. 이 두 도구 사이의 영역을 포함한 더 넓은 범위의 도구들에 대해서는, 이 두 가지만 비교하는 대신 자체 호스팅 n8n 대안 총정리를 참조하십시오.

FAQ

자가 호스팅 LiveContext에는 RAM이 얼마나 필요한가?

8 GB를 계획하십시오. 업스트림 README에는 최소 4 GB, 권장 사양으로 8 GB가 명시되어 있으며, 제공되는 compose 파일도 이를 따릅니다. 백엔드만 해도 1536 MB로 제한되며, 5개의 기본 서비스는 제한 없는 프론트엔드 컨테이너를 제외하고도 3 GB에 조금 못 미치는 메모리를 사용합니다. 브라우저 에이전트 프로필을 활성화하면 Chromium과 SearXNG 컨테이너를 위해 2048 MB가 추가되므로, 이 시점부터 8 GB는 선택 사항이 아닌 필수 사양이 됩니다.

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 키는 어디에 입력하는가?

첫 실행 전에 docker/.env.ce 내의 ANTHROPIC_API_KEY, OPENAI_API_KEY 또는 GOOGLE_API_KEY에 입력하십시오. 백엔드와 브리지는 시작 시점에 이를 읽어 들이며, 특정 사용자가 아닌 인스턴스 전체에 적용됩니다. 파일 권한은 600으로 유지하고, 이 서버 전용으로 생성한 키를 사용하여 필요 시 개별적으로 취소할 수 있도록 하십시오. 또한 공급자 콘솔에서 사용량 한도를 설정하십시오. 해당 한도만이 서버 외부에서 작동하는 유일한 제한 장치입니다.

LiveContext는 어떻게 백업하는가?

세 가지가 필요합니다. livecontext 데이터베이스의 pg_dump, MinIO 볼륨의 복사본, 그리고 docker/.env.ce 파일입니다. 데이터베이스와 객체 저장소 간의 일관성을 유지하기 위해 처음 두 가지를 백업하는 동안 livecontext 및 frontend 서비스를 중지하십시오. env 파일이 중요한 이유는 워크플로우에 저장된 자격 증명이 CREDENTIAL_ENCRYPTION_PASSWORD 및 CREDENTIAL_ENCRYPTION_SALT로 암호화되어 있기 때문입니다. 이 값들 없이 복원하면 새 서버에서 읽을 수 없는 자격 증명 행만 남게 됩니다.

부팅 후 백엔드가 왜 몇 분 동안 `health: starting` 상태로 머무르는가?

compose 헬스체크가 start_period: 120s를 설정하고 /actuator/health을 폴링하기 때문에, 스키마 마이그레이션과 도구 등록이 진행되는 동안 Docker는 해당 서비스를 시작 중인 것으로 보고합니다. 첫 부팅 시 2~3분 정도 소요되는 것은 정상입니다. 만약 상태가 정상으로 바뀌지 않는다면 docker compose logs -f livecontext을 확인하십시오. 마이그레이션 단계에서 멈추는 스택은 대개 더 최신 릴리스의 데이터베이스 볼륨을 참조하고 있는 경우입니다.

#livecontext#n8n #docker-compose #self-hosting #ai-agents #automation