Як розгорнути LiveContext як альтернативу n8n

Що таке LiveContext і скільки коштує його запуск

Для self-hosting LiveContext потрібен VPS приблизно з 8 GB RAM. LiveContext CE — це open source платформа автоматизації, яка запускає AI-агентів безпосередньо в самій системі автоматизації. Платформа постачається як стек Docker Compose із шести контейнерів на основі Java backend. У README upstream-проєкту вказано 4 GB як мінімальну вимогу та 8 GB як рекомендований обсяг. Файл compose показує, як розподіляється ця пам’ять.

Проєкт розміщено на livecontext-ai/livecontext-ce у GitHub. Ліцензія — AGPL-3.0. Станом на August 2026 поточний реліз — v0.2.11, опублікований 3 August 2026. Усі image зібрано лише для linux/amd64, тому недорогі Arm-плани не підходять. У цьому посібнику зафіксовано цей tag, стек розміщено за reverse proxy, а також описано процедуру резервного копіювання, якої немає в документації upstream-проєкту.

Оцініть ресурси 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
  }
]

Для backend встановлено обмеження 1536 MB. Це обмеження діє для процесу Java 21, тому JVM використає більшу частину доступної пам’яті й утримуватиме її. П’ять базових сервісів разом використовують трохи менше 3 GB, а для frontend обмеження не встановлено, тому він споживає стільки пам’яті, скільки запитує Node. На VPS із 4 GB для kernel і page cache майже нічого не залишається. Саме тому 4 GB вказано як мінімум, а не як рекомендований обсяг.

Необов’язкові профілі збільшують потрібний обсяг ресурсів до 8 GB. Профіль browser agent додає контейнер Chromium з обмеженням 2048 MB і екземпляр пошуку SearXNG, а профіль renderer додає ще 1024 MB для screenshots і PDF. Жоден із цих профілів не запускається без явного ввімкнення, тому не вмикайте їх, доки вони не знадобляться. Контейнер SearXNG призначений для роботи як пошуковий backend агента. Тому сторінки, які він повертає, надходять у prompts як ненадійний текст. Саме через цю межу довіри працює надання AI-агенту вебпошуку SearXNG, докладно описане в окремому матеріалі.

Якщо ви вже використовуєте n8n, плануйте замінити його, а не додавати до наявної системи. Стек з нашого посібника із запуску n8n на VPS за допомогою Docker і HTTPS складається з одного процесу Node поруч із Postgres і без проблем працює на невеликому сервері. Для одного лише backend LiveContext резервує більше пам’яті, ніж використовує весь цей стек. Дві automation-платформи на одному VPS із 8 GB працюватимуть доти, доки обидві не запустять завдання в одну й ту саму хвилину. Якщо ви все ж використовуєте спільний сервер, встановіть явні обмеження для всіх інших компонентів за методом із нашої статті про встановлення обмежень пам’яті в Docker Compose, щоб один неконтрольований workflow не вивів із ладу весь сервер.

Встановлення 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 може змінитися без вашого відома, а backend під час кожного запуску виконує міграції бази даних. Тому випадкове завантаження нового образу може о 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 backend має start_period тривалістю 120s і опитує /actuator/health. Тому docker compose ps протягом приблизно перших двох хвилин показує сервіс livecontext як health: starting, доки виконуються міграції схеми та реєстрація інструмента. Це нормально. Швидка перевірка на сервері:

curl -s localhost:8080/actuator/health

Команда має вивести {"status":"UP"}. Після цього відкрийте вебінтерфейс на порту 3000. Перший створений обліковий запис стає обліковим записом адміністратора, тому створіть свій обліковий запис, перш ніж порт стане доступним для інших. Це головна причина не публікувати порт 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 генеруються автоматично, якщо залишити їх порожніми. Натомість задайте їх самостійно. Облікові дані, які зберігають ваші workflow, шифруються цією парою значень. Тому дамп бази даних, відновлений на новому сервері без того самого пароля й salt, міститиме рядки облікових даних, які неможливо прочитати. Задайте ці значення один раз і вважайте docker/.env.ce частиною резервної копії.
• FRONTEND_PORT і BACKEND_PORT підставляються в mappings портів як ${FRONTEND_PORT:-3000}:3000 і ${BACKEND_PORT:-8080}:8080. У прикладі env-файлу обидва значення задано явно, і значення, що постачаються у файлі, не завжди дорівнюють 3000 і 8080. Перевірте свою копію, а не припускайте ці значення.
• GATEWAY_PUBLIC_URL — це origin бекенду, доступний браузеру. Це має значення, щойно з’являється 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 потрібне для пошуку embedding, тому звичайний образ postgres:16 не підійде.
• redis запускає redis:7-alpine із параметрами appendonly yes і --maxmemory-policy noeviction. Це зроблено навмисно: тут Redis зберігає стан черги та виконання, тому після досягнення ліміту пам’яті він повертає помилку процесу запису, а не мовчки видаляє ключі. Помилку, яку можна побачити, краще за роботу, яка зникає без сліду.
• minio — це S3-сумісне об’єктне сховище для файлів, які проходять через workflow. Одноразовий контейнер minio-init запускає mc mb myminio/workflow-files --ignore-existing під час старту, створює bucket і завершує роботу. Якщо в docker compose ps видно minio-init як exited (0), це означає, що стан системи нормальний.
• bridge містить CLI-адаптери та інструменти MCP (протоколу контексту моделі). Він прослуховує порт 8093 у Docker network і не публікується на хост.
• livecontext — це backend: один монолітний застосунок на Java 21, який працює на порту 8080. Він запускає workflow engine, планувальники та agents.
• 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 видаляє всі п’ять томів. Це документований спосіб почати з чистого стану, але водночас найшвидший спосіб втратити всі створені workflow. -v — це вся різниця.

Розмістіть сервіс за Traefik замість публікації порту 3000

Публікація портів 3000 і 8080 на публічному VPS відкриває застосунок без TLS (захисту транспортного рівня) і без проміжної автентифікації для реєстрації адміністраторів. Правила ufw недостатньо, оскільки Docker вставляє власні правила iptables для опублікованих портів перед ланцюжком, яким керує ufw. Тому порт, опублікований на 0.0.0.0, залишається доступним, навіть якщо ufw повідомляє, що доступ до нього заборонено.

Надійне рішення — нічого не публікувати, а дозволити проксі підключатися до контейнерів через спільну Docker network. Створіть 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 два списки об’єднаються, і порти залишаться опублікованими. Також default має залишатися в кожному списку networks, оскільки зазначення будь-якої network замінює мережу за замовчуванням. Якщо не вказати її, frontend втратить доступ до Postgres і Redis. Перед запуском перевірте об’єднаний результат:

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

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

Друге hostname не є необов’язковим. Вебінтерфейс викликає backend із браузера, тому backend потрібен власний origin, доступний браузеру. Установіть GATEWAY_PUBLIC_URL у docker/.env.ce на URL цього backend, наприклад https://lc-api.example.com. Якщо пропустити цей параметр, сторінка завантажиться нормально, але кожна дія завершуватиметься помилкою. Це відбувається тому, що UI визначив origin backend за адресою, яку ви відкрили, і звертається до порту, який ваш проксі не публікував.

Оскільки сторінка реєстрації відкрита для першого відвідувача, варто налаштувати forward auth на frontend router. Тоді ніхто не побачить цю сторінку без автентифікації на проксі. Саме це додає запуск Authentik як власного SSO-рівня до тієї самої конфігурації Traefik.

Де зберігається ключ моделі та чому запущений бездіяльний екземпляр усе одно коштує грошей

Агенти працюють усередині цієї системи автоматизації, тому економіка відрізняється від звичайного інструмента для робочих процесів. Ключ провайдера зберігається в docker/.env.ce як ANTHROPIC_API_KEY або OPENAI_API_KEY, зчитується бекендом і bridge під час запуску та застосовується до всього екземпляра. Ключ не прив’язаний до окремого користувача. Кожен, хто має обліковий запис у вашому екземплярі та може створювати агента, витрачає кошти з цього ключа. Перший зареєстрований користувач стає адміністратором.

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

Витрати не дорівнюють нулю, якщо агент працює за розкладом, навіть коли він бездіяльний. Тригер розкладу спрацьовує незалежно від того, чи хтось стежить за системою, і кожне спрацювання витрачає токени. Розклад із інтервалом у п’ять хвилин дає 288 запусків на день. Агент, який читає сторінку та вирішує нічого не робити, усе одно витрачає кошти на її читання. Спочатку налаштуйте агентів на webhook або chat trigger, протягом тижня відстежуйте фактичні витрати, а потім переходьте на розклад, коли визначите вартість одного запуску.

Створення резервної копії Postgres і object store

Є два сховища даних і один секрет. Втрата будь-якого з них означає втрату інстансу. Створюйте резервну копію бази даних і bucket в одному сеансі, коли backend зупинено. Це запобігає запису файлу після того, як його рядок у базі даних уже збережено в дампі.

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, використовуйте встановлене вами значення DB_USERNAME замість postgres. Потім скопіюйте volume object store, використовуючи назву з префіксом, яку вивела команда 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, щоб пароль і сіль шифрування облікових даних збігалися, один раз запустіть stack, щоб volumes було створено, зупиніть backend, а потім завантажте дамп:

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 застосовує міграції схеми під час запуску, а міграції рухаються лише вперед. Тому після невдалого оновлення повернення до старішого tag залишає старий код, який працює з новішою схемою. Rollback означає відновлення дампа. Саме тому дамп потрібно створювати першим.

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, вибраного зі списку, який вивела третя команда. Моніторте журнал backend, доки endpoint перевірки стану знову не почне відповідати. Ваш docker-compose.override.yml не відстежується, тому команда git checkout залишить його на місці. Однак перегляньте diff у docker-compose.yml між tag, оскільки новий сервіс або перейменований сервіс може зробити ваш override застарілим без будь-якого повідомлення про помилку.

Типові відмови та повідомлення, які ви побачите

Контейнер постійно перезапускається, а docker compose ps показує exited (137). Це вбивця процесів ядра через нестачу пам’яті (OOM killer). docker inspect livecontext-app підтверджує це значенням "OOMKilled": true у блоці стану. Бекенд досяг ліміту 1536M або на хості раніше завершилася доступна пам’ять. Перш ніж збільшувати будь-який ліміт, перевірте free -m. Збільшення ліміту контейнера на хості без вільної пам’яті лише перенесе завершення іншого контейнера.

Завантаження образу завершується помилкою 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. Інший процес на хості вже використовує цей порт. Змініть FRONTEND_PORT у docker/.env.ce або застосуйте наведене вище перевизначення й узагалі не публікуйте порт.

Інтерфейс доступний, але після додавання проксі запит входу завершується помилкою. Браузер звертається до бекенду через origin, який ваш проксі не обслуговує. Відкрийте вкладку мережевих запитів браузера та перегляньте хост запиту, що завершується помилкою. Установіть GATEWAY_PUBLIC_URL на публічну URL-адресу бекенду й повторно створіть контейнер frontend, оскільки це значення зчитується під час запуску.

Усе працює штатно, але файли, завантажені під час workflow, зникають. Перевірте, що minio-init показує exited (0), а не ненульовий код. Якщо bucket workflow-files не було створено, бекенду нікуди записувати об’єкти.

Оберіть LiveContext або n8n

Оберіть LiveContext, якщо головним є агент: ви хочете, щоб модель створювала й запускала автоматизацію, і готові прийняти сервер із 8 GB RAM та Java-сервіс як необхідну умову. Оберіть n8n, якщо вам потрібні детерміновані робочі процеси, велика бібліотека вузлів і компактне розгортання, яке можна розмістити на VPS разом з іншими сервісами. Номери версій тут ще нестабільні, v0.2.11 станом на August 2026, тому зафіксуйте tag і перед кожним оновленням читайте release notes. Ширший огляд, зокрема інструментів, що займають проміжне місце між цими двома варіантами, дивіться в нашому огляді self-hosted альтернатив n8n, а не в порівнянні лише цих двох продуктів.

FAQ

Скільки RAM потрібно для self-hosted LiveContext?

Плануйте 8 GB. У README upstream як мінімум указано 4 GB, а як рекомендований обсяг — 8 GB. Це відповідає shipped compose file: лише backend обмежений значенням 1536 MB, а п’ять базових сервісів разом використовують трохи менше 3 GB без урахування frontend container, для якого ліміт не встановлено. Увімкнення browser agent profile додає ще 2048 MB для Chromium і контейнер SearXNG, тому після цього 8 GB стає обов’язковим обсягом.

Чи можна запустити LiveContext на Arm VPS?

Ні. Кожен опублікований image зібрано для linux/amd64, тому docker compose up на Arm plan завершується помилкою під час pull із повідомленням no matching manifest for linux/arm64/v8 in the manifest list entries. Теоретично його можна запускати через емуляцію QEMU, але на практиці це непридатно для JVM workload. Виберіть x86 plan.

Куди додати API key моделі?

У docker/.env.ce як ANTHROPIC_API_KEY, OPENAI_API_KEY або GOOGLE_API_KEY до першого запуску. Backend і bridge читають його під час запуску, і ключ застосовується до всього instance, а не до одного користувача. Встановіть для файлу mode 600 і використовуйте ключ, створений лише для цього сервера, щоб його можна було відкликати окремо. Також установіть ліміт витрат у provider console, оскільки це єдиний ліміт, який діє поза межами машини.

Як створити резервну копію LiveContext?

Потрібні три речі: pg_dump бази даних livecontext, копія MinIO volume і файл docker/.env.ce. На час створення перших двох копій зупиніть сервіси livecontext і frontend, щоб база даних і object store залишалися узгодженими. Env file важливий, оскільки credentials, збережені у ваших workflows, зашифровано за допомогою CREDENTIAL_ENCRYPTION_PASSWORD і CREDENTIAL_ENCRYPTION_SALT. Тому після відновлення без цих значень у таблицях залишаться записи credentials, які новий сервер не зможе прочитати.

Чому backend після запуску протягом кількох хвилин перебуває у стані health: starting?

Compose healthcheck установлює start_period: 120s і опитує /actuator/health, тому Docker повідомляє, що сервіс запускається, поки виконуються schema migrations і реєстрація tools. Під час першого запуску дві-три хвилини є нормальною тривалістю. Якщо сервіс так і не перейде у стан healthy, прочитайте docker compose logs -f livecontext. Якщо stack зупиняється на етапі migration, зазвичай він використовує database volume із новішого release.