Как развернуть LiveContext на своем сервере

Что такое LiveContext и сколько стоит его запуск

Для самостоятельного размещения LiveContext требуется VPS с объемом оперативной памяти около 8 GB. LiveContext CE — это платформа автоматизации с открытым исходным кодом, которая запускает AI-агенты непосредственно внутри процессов автоматизации. Продукт поставляется в виде стека Docker Compose из шести контейнеров, работающих на базе Java. В README от разработчиков указан минимум 4 GB и рекомендуемый объем 8 GB; файл compose наглядно показывает распределение этой памяти.

Проект находится по адресу livecontext-ai/livecontext-ce на GitHub и распространяется по лицензии AGPL-3.0. Текущий релиз на август 2026 года — v0.2.11, опубликован 3 августа 2026 года. Все образы собраны исключительно для архитектуры linux/amd64, что исключает использование недорогих тарифных планов на базе Arm. В данном руководстве зафиксирована эта версия, стек вынесен за reverse proxy, а также описана процедура резервного копирования, которая отсутствует в официальной документации.

Определите размер VPS перед самостоятельным развертыванием LiveContext

Каждый сервис в поставляемом файле compose имеет явное ограничение по оперативной памяти, поэтому вы можете оценить требования к серверу до его аренды. Это лимиты, прописанные в файле 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 МБ. Этот лимит распространяется на процесс Java 21, поэтому JVM будет использовать большую часть этого объема и удерживать его. Пять базовых сервисов в сумме потребляют чуть менее 3 ГБ, а для фронтенда ограничений нет, поэтому он использует столько памяти, сколько запрашивает Node. На VPS с 4 ГБ памяти почти не остается ресурсов для ядра и страничного кэша, поэтому 4 ГБ указаны как минимальное требование, а не как рекомендация.

Дополнительные профили увеличивают потребление до 8 ГБ. Профиль браузерного агента добавляет контейнер Chromium с ограничением в 2048 МБ вместе с экземпляром поиска SearXNG, а профиль рендеринга добавляет еще 1024 МБ для создания скриншотов и PDF-файлов. Ни один из них не запускается, пока вы не активируете соответствующий профиль, поэтому не включайте их без необходимости. Контейнер SearXNG существует как поисковый бэкенд для агента, поэтому возвращаемые им страницы попадают в ваши промпты как недоверенный текст. Это граница доверия, которую подробно описывает статья предоставление AI-агенту доступа к веб-поиску SearXNG.

Если вы уже используете n8n, планируйте заменить его, а не дополнять. Стек, описанный в нашем руководстве по запуску n8n на VPS с Docker и HTTPS, состоит из одного процесса Node и базы данных Postgres, что комфортно работает на небольшом сервере. LiveContext резервирует для одного только бэкенда больше ресурсов, чем весь этот стек. Две платформы автоматизации на одном VPS с 8 ГБ памяти будут работать нормально, пока обе не запустят задачу в одну и ту же минуту. Если вы все же используете один хост для нескольких сервисов, установите явные лимиты для всего остального, используя метод из нашей статьи об установке лимитов памяти в Docker Compose, чтобы один вышедший из-под контроля рабочий процесс не привел к падению всей системы.

Установка LiveContext с помощью Docker Compose, с фиксацией версии

Начните с чистой VPS на базе Ubuntu 24.04 с установленным 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 и образы, так как файл compose для v0.2.11 был написан именно под эти версии образов. Не меняйте теги на latest. Тег latest может измениться в любой момент, а бэкенд выполняет миграции базы данных при каждом запуске. Случайный pull может обновить схему БД в 3 часа ночи, и единственным способом отката останется восстановление из резервной копии.

Отредактируйте docker/.env.ce перед первым запуском (в следующем разделе указано, что именно нужно изменить), а затем поднимите стек.

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

Используйте один и тот же флаг --env-file для каждой команды compose в этом руководстве. Compose считывает файл при каждом вызове, поэтому команда без этого флага будет использовать значения по умолчанию, прописанные в файле compose, что может привести к публикации портов, отличных от настроенных вами.

Healthcheck бэкенда имеет start_period длительностью 120 секунд и опрашивает /actuator/health, поэтому docker compose ps будет сообщать о статусе сервиса livecontext как health: starting в течение первых двух минут, пока выполняются миграции схемы и регистрация инструментов. Это нормальное поведение. Быстрая проверка с сервера:

curl -s localhost:8080/actuator/health

Команда должна вывести {"status":"UP"}. После этого откройте веб-интерфейс на порту 3000. Первая созданная учетная запись становится администратором, поэтому создайте свою до того, как порт станет доступен кому-либо еще. Это главная причина, по которой не следует открывать порт 3000 в интернет в первый же день.

Значения переменных окружения, которые необходимо изменить

Файл с примером поставляется с рабочими значениями по умолчанию, чтобы стек запускался на локальном компьютере. Некоторые из них небезопасны для публичного сервера.

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 — это адрес бэкенда, доступный из браузера. Он важен, как только в схеме появляется reverse proxy. См. следующий раздел.
• Ключи моделей (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 здесь хранит очередь и состояние выполнения, поэтому при достижении лимита памяти он возвращает ошибку записывающему процессу, а не молча удаляет ключи. Ошибка, которую можно увидеть, лучше, чем бесследно исчезнувшая работа.
• minio — это S3-совместимое объектное хранилище для файлов, проходящих через рабочие процессы. Однократный контейнер minio-init запускает mc mb myminio/workflow-files --ignore-existing при старте, создаёт бакет и завершает работу. Состояние, при котором minio-init отображается как exited (0) в docker compose ps, является нормальным.
• bridge содержит CLI-адаптеры и инструменты MCP (model context protocol). Он ожидает подключений на порту 8093 внутри сети Docker и не публикуется на хост-машину.
• livecontext — это бэкенд, монолит на Java 21, работающий на порту 8080. Он управляет движком рабочих процессов, планировщиками и агентами.
• frontend — это веб-интерфейс на Next.js, работающий на порту 3000. Только эти два последних сервиса опубликованы на хост-машине.

Состояние хранится в пяти именованных томах: livecontext_data для Postgres, livecontext_redis, livecontext_minio, livecontext_keys и livecontext_logs. Compose добавляет к ним префикс с именем проекта, которое по умолчанию совпадает с именем директории, поэтому реальное имя тома на диске будет выглядеть примерно как livecontext-ce_livecontext_minio. Выполните docker volume ls и скопируйте точные имена перед написанием любых скриптов резервного копирования.

docker compose down -v удаляет все пять томов. Это документированный способ начать всё сначала, а также самый быстрый способ потерять все созданные вами рабочие процессы. Разница заключается только в -v.

Размещение за Traefik вместо публикации порта 3000

Публикация портов 3000 и 8080 на публичном VPS делает приложение доступным без TLS (transport layer security) и без защиты перед страницей регистрации администратора. Правила ufw недостаточно, так как Docker добавляет свои правила 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 версии 2.24 или новее: проверьте версию с помощью docker compose version, так как в старых версиях Compose списки объединяются и порты остаются опубликованными. Кроме того, default должен оставаться в каждом списке networks, так как указание любой сети заменяет сеть по умолчанию, и его отсутствие изолирует фронтенд от Postgres и Redis. Проверьте итоговую конфигурацию перед запуском:

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

Маршрутизаторы, резолвер сертификатов и редирект с HTTP на HTTPS настраиваются так же, как и для любого другого приложения. Следуйте нашему руководству по Traefik reverse proxy для запуска нескольких приложений на одном VPS, вместо того чтобы создавать новую конфигурацию TLS. Направьте одно доменное имя на frontend на порт 3000, а второе — на livecontext на порт 8080.

Второе доменное имя обязательно. Веб-интерфейс обращается к бэкенду из браузера, поэтому бэкенду нужен собственный источник (origin), доступный браузеру. Укажите GATEWAY_PUBLIC_URL в docker/.env.ce, используя этот URL бэкенда, например https://lc-api.example.com. Если этого не сделать, страница загрузится, но все действия будут завершаться ошибкой, так как интерфейс определит адрес бэкенда на основе того URL, который вы открыли в браузере, и будет пытаться обратиться к порту, который прокси-сервер не открывал.

Поскольку страница регистрации доступна любому, кто перейдет по ссылке, стоит настроить аутентификацию на маршрутизаторе фронтенда. Это предотвратит доступ к странице без авторизации на прокси-сервере, что реализуется с помощью развертывания Authentik в качестве собственного уровня SSO поверх той же настройки Traefik.

Где размещается ключ модели и почему простаивающий экземпляр продолжает расходовать средства

Агенты работают внутри системы автоматизации, что меняет экономическую модель по сравнению с обычными инструментами для рабочих процессов. Ключ провайдера размещается в docker/.env.ce в качестве ANTHROPIC_API_KEY или OPENAI_API_KEY, считывается бэкендом и мостом при запуске и применяется ко всему экземпляру целиком. Он не ограничивается рамками отдельного пользователя. Любой, у кого есть учетная запись на вашем экземпляре и возможность создавать агентов, расходует лимит этого ключа, а первый зарегистрировавшийся пользователь автоматически становится администратором.

Три привычки помогут сделать расходы предсказуемыми. Создайте отдельный ключ провайдера для этого VPS, чтобы вы могли отозвать его, не затрагивая другие компоненты. Установите жесткий лимит расходов в консоли провайдера, так как это единственное ограничение, находящееся вне контролируемой вами машины. Затем используйте кредитные бюджеты и метрики для каждого агента, которые предоставляет LiveContext, чтобы один зацикленный процесс не исчерпал ключ до того, как вы это заметите.

Стоимость простоя не равна нулю, если агент работает по расписанию. Триггер расписания срабатывает независимо от того, наблюдает ли кто-то за процессом, и каждое срабатывание расходует токены. Расписание с интервалом в пять минут — это 288 запусков в день, и агент, который считывает страницу и решает ничего не предпринимать, всё равно оплачивает чтение этой страницы. Запускайте своих первых агентов через вебхук или чат-триггер, отслеживайте реальные расходы в течение недели и переходите к расписанию только после того, как узнаете стоимость одного запуска.

Резервное копирование 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, а не однострочное сообщение об ошибке. После этого скопируйте все три файла с сервера. Резервная копия, которая хранится только на защищаемом сервере, не является резервной копией.

Для восстановления на новом сервере установите ту же версию (tag), верните на место сохраненный 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

Обновления и восстановление после сбоев

Всегда делайте дамп перед началом. Backend применяет миграции схемы при запуске, а миграции работают только в одну сторону. Поэтому возврат к старой версии тега после неудачного обновления приведет к тому, что старый код будет работать с новой схемой базы данных. Откат означает восстановление из дампа, поэтому дамп делается в первую очередь.

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 в значение тега, который вы выбрали из списка, выведенного третьей командой. Следите за логом backend, пока health endpoint снова не начнет отвечать. Ваш файл docker-compose.override.yml не отслеживается системой контроля версий, поэтому команда git checkout оставит его на месте. Однако изучите различия в docker-compose.yml между тегами: новый или переименованный сервис может сделать ваш override неактуальным, при этом система не выдаст никаких сообщений об ошибках.

Типичные сбои и сообщения об ошибках

Контейнер постоянно перезапускается, а docker compose ps выводит exited (137). Это означает, что сработал механизм OOM Killer (Out-of-Memory) ядра Linux, а docker inspect livecontext-app подтверждает это значением "OOMKilled": true в блоке состояния. Бэкенд достиг лимита в 1536M или на хосте закончилась оперативная память. Проверьте free -m перед увеличением лимитов, так как повышение лимита для одного контейнера на хосте без свободных ресурсов просто приведет к завершению другого процесса.

При попытке загрузки образа возникает ошибка no matching manifest for linux/arm64/v8 in the manifest list entries. Образы опубликованы только для архитектуры linux/amd64. VPS на базе Arm не сможет запустить этот стек из готовых образов, а эмуляция через QEMU работает слишком медленно для JVM и Chromium. Перейдите на тарифный план с архитектурой x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. Порт уже занят другим процессом на хосте. Измените FRONTEND_PORT в файле docker/.env.ce или примените переопределение, указанное выше, чтобы не публиковать порт вовсе.

Интерфейс доступен, но запрос на вход в систему завершается ошибкой после настройки прокси. Браузер обращается к бэкенду по адресу, который не обслуживается вашим прокси. Откройте вкладку сети в инструментах разработчика браузера и посмотрите хост в неудачном запросе. Установите GATEWAY_PUBLIC_URL равным публичному URL бэкенда и пересоздайте контейнер фронтенда, так как это значение считывается только при запуске.

Все сервисы работают исправно, но файлы, загруженные в рамках рабочего процесса, исчезают. Убедитесь, что minio-init возвращает exited (0), а не код ошибки, отличный от нуля. Если бакет workflow-files не был создан, бэкенду некуда сохранять объекты.

Выбор между LiveContext и n8n

Выбирайте LiveContext, если приоритетом является агент: вы хотите, чтобы модель сама создавала и запускала автоматизацию, и готовы выделить под это сервер с 8 GB оперативной памяти и Java-сервис. Выбирайте n8n, если вам нужны детерминированные рабочие процессы, обширная библиотека узлов и компактность, позволяющая разместить сервис на одном VPS вместе с другими приложениями. Версии этих инструментов пока ранние, v0.2.11 по состоянию на август 2026 года, поэтому фиксируйте теги версий и читайте примечания к релизам перед каждым обновлением. Чтобы ознакомиться с более широким спектром инструментов, включая решения, занимающие промежуточное положение, изучите наш обзор self-hosted альтернатив n8n, вместо того чтобы ограничиваться сравнением только этих двух продуктов.

FAQ

Сколько оперативной памяти требуется для self-hosted LiveContext?

Планируйте 8 GB. В README от разработчиков указано 4 GB как минимум и 8 GB как рекомендуемый объем; поставляемый compose-файл соответствует этим требованиям: для одного только backend установлено ограничение в 1536 MB, а пять базовых сервисов в сумме потребляют чуть менее 3 GB без учета неограниченного контейнера frontend. Активация профиля браузерного агента добавляет еще 2048 MB для Chromium и контейнера SearXNG, поэтому при таком сценарии 8 GB становятся обязательными.

Можно ли запустить LiveContext на VPS с архитектурой Arm?

Нет. Все опубликованные образы собраны для linux/amd64, поэтому docker compose up на тарифе с Arm завершается ошибкой при попытке 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, до первого запуска. Backend и bridge считывают его при старте, и он применяется ко всему экземпляру, а не к отдельному пользователю. Установите права доступа к файлу 600, используйте ключ, созданный специально для этого сервера, чтобы его можно было отозвать отдельно, и установите лимит расходов в консоли провайдера, так как это единственный лимит, который действует вне самого сервера.

Как создать резервную копию LiveContext?

Нужны три компонента: pg_dump базы данных livecontext, копия тома MinIO и файл docker/.env.ce. Остановите сервисы livecontext и frontend перед копированием первых двух, чтобы состояние базы данных и объектного хранилища было согласованным. Файл окружения необходим, так как учетные данные в ваших рабочих процессах зашифрованы с помощью CREDENTIAL_ENCRYPTION_PASSWORD и CREDENTIAL_ENCRYPTION_SALT; восстановление без этих значений приведет к тому, что записи с учетными данными на новом сервере станут нечитаемыми.

Почему backend находится в состоянии health: starting в течение нескольких минут после загрузки?

Healthcheck в compose устанавливает start_period: 120s и опрашивает /actuator/health, поэтому Docker помечает сервис как запускающийся, пока выполняются миграции схемы и регистрация инструментов. Две-три минуты при первом запуске — это нормальное поведение. Если статус не меняется на healthy, изучите docker compose logs -f livecontext. Если процесс останавливается на этапе миграции, это обычно означает, что сервис пытается использовать том базы данных от более новой версии релиза.