ガイド

著者 Matt Connor 2026-08-10 ・更新日 2026-08-13

LiveContextをセルフホストする方法と必要なVPS容量

Q: Arm VPS で LiveContext を実行できますか？

できません。公開されているすべてのイメージは linux/amd64 向けにビルドされているため、Arm プランでは pull 時に docker compose up が no matching manifest for linux/arm64/v8 in the manifest list entries で失敗します。理論上は QEMU エミュレーションで実行できますが、JVM ワークロードでは実用になりません。x86 プランを選択してください。

Q: model API key はどこに設定しますか？

初回起動前に docker/.env.ce へ ANTHROPIC_API_KEY、OPENAI_API_KEY、または GOOGLE_API_KEY として設定します。backend と bridge は起動時にこの値を読み込み、1 ユーザーではなくインスタンス全体に適用します。ファイルの mode は 600 にし、このサーバー専用に作成した key を使用して単独で revoke できるようにしてください。また、provider のコンソールで spend cap を設定してください。マシンの外部で適用される制限は、この cap だけだからです。

Q: LiveContext をバックアップするにはどうすればよいですか？

必要なのは 3 つです。livecontext データベースの pg_dump、MinIO volume のコピー、そして docker/.env.ce ファイルです。最初の 2 つを取得する間は livecontext サービスと frontend サービスを停止し、データベースと object store の整合性を保ってください。env ファイルも重要です。workflow に保存される credentials は CREDENTIAL_ENCRYPTION_PASSWORD と CREDENTIAL_ENCRYPTION_SALT で暗号化されているため、これらの値なしで restore すると、新しいマシンでは credential の行を読み取れなくなります。

Q: 起動後、backend が health: starting のまま数分間変わらないのはなぜですか？

compose の healthcheck は start_period: 120s を設定し、/actuator/health を polling します。そのため、schema migration と tool registration の実行中、Docker はサービスを starting と報告します。初回起動で 2〜3 分かかるのは想定内です。healthy にならない場合は docker compose logs -f livecontext を確認してください。migration の段階で停止する stack は、通常、新しい release のデータベース volume を参照しています。

LiveContext CEはJavaバックエンドを含む6コンテナ構成で、推奨は8 GB RAMです。バージョン固定、Traefikの設定、2つのストアのバックアップ手順を解説します。

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 月時点の最新リリースは v0.2.11 で、2026 年 8 月 3 日に公開されています。すべてのイメージは linux/amd64 専用にビルドされているため、安価な Arm プランは利用できません。このガイドでは、そのタグを固定し、スタックをリバースプロキシの背後に配置します。また、上流ドキュメントに記載されていないバックアップ手順も説明します。

LiveContext をセルフホストする前に VPS の容量を決める

配布されている compose ファイルでは、すべてのサービスに明示的なメモリ制限が設定されています。そのため、VPS を借りる前に必要なスペックを決められます。これは 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 になります。ブラウザーエージェントのプロファイルでは、2048 MB に制限された Chromium コンテナが、SearXNG の検索インスタンスとともに追加されます。renderer プロファイルでは、スクリーンショットと PDF 用にさらに 1024 MB が追加されます。どちらもプロファイルを有効にしない限り起動しません。必要になるまで、両方とも無効にしてください。この SearXNG コンテナはエージェントの検索バックエンドとして動作します。そのため、返されたページは信頼できないテキストとしてプロンプトに入ります。AI エージェントに SearXNG の Web 検索を使わせる仕組みでは、これが信頼境界になります。

すでに n8n を運用している場合は、追加するのではなく置き換える計画にしてください。VPS 上で Docker と HTTPS を使って n8n を運用する手順の構成は、Postgres と同じホスト上で 1 つの Node プロセスを動かすもので、小規模な VPS で問題なく動作します。LiveContext は、バックエンドだけでその構成全体より多くのリソースを確保します。1 台の 8 GB VPS で 2 つの自動化プラットフォームを動かす場合、両方が同じ分にジョブを実行するまでは収まります。ホストを共有する場合は、Docker Compose でメモリ制限を設定する手順の方法を使い、他のすべてのサービスにも明示的な制限を設定してください。1 つの暴走したワークフローによってマシン全体が停止する事態を防げます。

Docker Compose で LiveContext をインストールし、タグを固定する

Docker Engine 24 以降と Compose v2 を備えた、クリーンな Ubuntu 24.04 VPS から始めます。Docker がまだインストールされていない場合は、先に VPS 向け Docker Compose の基本に従ってから戻ってきてください。

README には、1 行で起動する npx livecontext が用意されています。ノート PC では問題ありません。ただしサーバーでは、管理下のディレクトリに 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 タグを checkout すると、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 をポーリングします。そのため、docker compose ps はスキーママイグレーションとツール登録が実行される最初の約 2 分間、livecontext サービスを health: starting と報告します。これは正常です。サーバーから簡単に確認するには、次を実行します。

curl -s localhost:8080/actuator/health

{"status":"UP"} と表示されるはずです。表示されたら、ポート 3000 で Web UI を開きます。最初に作成したアカウントが admin になります。そのため、他のユーザーからポートに到達できるようになる前に、自分のアカウントを作成してください。初日からポート 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 は空のままにすると自動生成されます。代わりに、自分で設定してください。ワークフローに保存する認証情報は、この 2 つの値で暗号化されます。そのため、同じパスワードと salt がない状態で新しいサーバーにデータベースダンプをリストアすると、認証情報の行を復号できません。一度設定したら、docker/.env.ce もバックアップ対象として扱ってください。
FRONTEND_PORT と BACKEND_PORT は、ポートマッピングの ${FRONTEND_PORT:-3000}:3000 と ${BACKEND_PORT:-8080}:8080 に置換されます。サンプルの env ファイルでは両方が明示的に設定されており、設定されている値は常に 3000 と 8080 とは限りません。思い込みで判断せず、手元のファイルを確認してください。
GATEWAY_PUBLIC_URL は、バックエンドにブラウザーからアクセスする際の origin です。リバースプロキシを使用すると、すぐに影響します。次のセクションを参照してください。
モデルのキー（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 番ポートで動作する 1 つの Java 21 モノリスです。ワークフローエンジン、スケジューラー、エージェントを実行します。
frontend は 3000 番ポートで動作する Next.js の Web UI です。ホストに公開されるのは最後の 2 つだけです。

状態は 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 がその違いをすべて決めます。

Traefik の背後に置き、port 3000 を公開しない

公開 VPS で ports 3000 と 8080 を公開すると、TLS（transport layer security）なしでアプリにアクセスでき、管理者登録の前段に認証も置かれません。ufw ルールだけでは不十分です。Docker は公開 port 用の独自の iptables ルールを、ufw が管理する chain より前に挿入するためです。そのため、0.0.0.0 に公開した port は、ufw が拒否していても到達可能なままです。

確実な方法は、port を一切公開せず、共有 Docker network 経由で proxy から container に接続させることです。リポジトリの root で docker-compose.override.yml を作成します。

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

networks:
  proxy:
    external: true

この構成が機能するかどうかは、2 つの点で決まります。!override は ports list をマージせず置き換えます。この機能には Compose v2.24 以降が必要です。docker compose version で確認してください。古い Compose では 2 つの list がマージされ、port が公開されたままになります。また、各 networks list には default を残す必要があります。network を 1 つでも名前付きで指定すると default network が置き換わるため、省略すると frontend から Postgres と Redis に接続できなくなります。起動する前に、マージ後の結果を確認します。

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

router、certificate resolver、HTTP から HTTPS への redirect は、他のアプリと同じです。そのため、ここで新しい TLS 設定を書くのではなく、1 台の VPS で複数のアプリを運用するための Traefik reverse proxy ガイドに従ってください。1 つの hostname を port 3000 の frontend に、もう 1 つの hostname を port 8080 の livecontext に転送します。

2 つ目の hostname は省略できません。Web UI は browser から backend を呼び出すため、browser から到達できる独自の origin が backend に必要です。docker/.env.ce で GATEWAY_PUBLIC_URL を backend URL に設定します。例として https://lc-api.example.com のように指定します。これを省略すると、ページは正常に読み込まれても、すべての操作が失敗します。UI は開いたアドレスから backend origin を解決し、proxy が公開していない port を呼び出すためです。

サインアップページは、最初に到達したユーザーに公開されます。そのため、frontend router に forward auth を設定し、proxy で認証しない限り誰もそのページを見られないようにする価値があります。Authentik を独自の SSO 層として運用する方法では、同じ Traefik 構成にこの機能を追加できます。

モデルキーの配置場所と、アイドル状態のインスタンスにも費用が発生する理由

ここではエージェントが自動化処理の中で実行されるため、単純なワークフローツールとは費用構造が異なります。プロバイダーキーは docker/.env.ce の ANTHROPIC_API_KEY または OPENAI_API_KEY に設定します。バックエンドとブリッジが起動時に読み込み、インスタンス全体に適用します。ユーザー単位では分離されません。インスタンスのアカウントを持ち、エージェントを作成できるユーザーは誰でもこのキーを使用でき、最初に登録したユーザーは管理者になります。

請求額を予測しやすくするには、3 つの運用が有効です。この VPS 専用のプロバイダーキーを作成し、他の環境に影響を与えずに失効できるようにします。プロバイダーのコンソールで上限額を設定します。保護対象のマシンの外部にある制限は、この上限だけだからです。次に、LiveContext が提供するエージェントごとのクレジット予算とメトリクスを使用します。異常なループによって、気付く前にキーの残高を使い切られることを防げます。

エージェントをスケジュールで実行すると、アイドル状態でも費用は 0 になりません。スケジュールトリガーは、誰も監視していなくても実行され、そのたびにトークンを送信します。5 分間隔のスケジュールは 1 日 288 回実行されます。ページを読み取り、何もしないと判断するエージェントでも、ページの読み取りには費用が発生します。最初のエージェントは webhook またはチャットトリガーで実行し、1 週間実際の使用額を監視してください。1 回の実行コストを把握してから、スケジュール実行に移行します。

Postgres とオブジェクトストアをバックアップする

データストアが 2 つと Secret が 1 つあります。3 つのいずれかを失うと、インスタンス全体を失います。データベースとバケットは、バックエンドを停止した状態で同じ時間帯に取得してください。これにより、データベースの行をダンプした後にファイルが書き込まれることを防げます。

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 では、1 行のエラーではなく、CREATE TABLE と DROP TABLE のステートメントが表示される必要があります。次に、3 つすべてのファイルをサーバーの外部へコピーします。保護対象のマシン上にしか存在しないバックアップは、バックアップではありません。

新しいサーバーへ復元するには、同じ tag をインストールし、保存した docker/.env.ce を戻して認証情報の暗号化パスワードと salt を一致させます。次に、ボリュームを作成するためにスタックを 1 回起動し、バックエンドを停止してから、ダンプを読み込みます。

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を、3 番目のコマンドが出力した一覧から選んだタグに設定します。ヘルスエンドポイントが再び応答するまで、バックエンドのログを監視します。docker-compose.override.ymlは追跡対象外のため、git checkoutを実行してもそのまま残ります。ただし、タグ間のdocker-compose.ymlの差分を確認してください。新しいサービスの追加やサービス名の変更によって、エラーメッセージが表示されないままオーバーライドが古い状態になることがあります。

障害パターンと表示される文字列

コンテナが再起動を繰り返し、docker compose ps に exited (137) と表示されます。 これはカーネルの OOM killer によるもので、状態ブロックの "OOMKilled": true により docker inspect livecontext-app であることを確認できます。バックエンドが 1536M の上限に達したか、先にホストのメモリが不足しました。上限を引き上げる前に free -m を確認してください。空きメモリがないホストでコンテナの上限を引き上げても、別のコンテナが kill されるだけです。

pull が no matching manifest for linux/arm64/v8 in the manifest list entries で失敗します。 イメージは linux/amd64 向けにのみ公開されています。Arm VPS では公開済みイメージからこのスタックを実行できません。JVM と Chromium を QEMU でエミュレーションすると遅すぎます。x86 プランに移行してください。

Bind for 0.0.0.0:3000 failed: port is already allocated。 ホスト上の別のプロセスが、そのポートをすでに使用しています。docker/.env.ce の FRONTEND_PORT を変更するか、上記の override を適用して、何も公開しないようにしてください。

プロキシを追加した後、UI は起動していますがログインリクエストが失敗します。 ブラウザーが、プロキシで提供されていない origin のバックエンドを呼び出しています。ブラウザーのネットワークタブを開き、失敗したリクエストのホストを確認してください。GATEWAY_PUBLIC_URL を公開バックエンド URL に設定し、フロントエンドコンテナを再作成してください。この値は起動時に読み込まれます。

すべて正常ですが、ワークフローでアップロードしたファイルが消えます。 minio-init にゼロ以外のコードではなく exited (0) が表示されることを確認してください。バケット workflow-files が作成されていなければ、バックエンドにはオブジェクトの保存先がありません。

LiveContext と n8n のどちらを選ぶか

エージェントを中心に据える場合は LiveContext を選びます。モデルに自動化の構築と実行を任せ、その代わりに 8 GB のサーバーと Java サービスを受け入れる構成です。決定論的なワークフロー、大規模なノードライブラリ、他のサービスと VPS を共有できる規模を重視する場合は n8n を選びます。ここで扱うバージョン番号は新しく、v0.2.11 2026 年 8 月時点のものです。そのため、タグを固定し、アップグレードの前に毎回リリースノートを確認してください。両者の中間に位置するツールを含む、より広い選択肢については、この 2 つだけを比較した記事ではなく、自己ホスト型 n8n 代替製品の一覧を参照してください。

FAQ

自己ホスト型の LiveContext には、どの程度の RAM が必要ですか？

8 GB を見込んでください。upstream の README では最小要件が 4 GB、推奨が 8 GB とされており、提供されている compose ファイルもこの要件に一致します。backend だけで 1536 MB に制限され、5 つの基本サービスを合計すると、frontend コンテナの無制限分を除いて 3 GB 弱になります。browser agent プロファイルを有効にすると、Chromium と SearXNG コンテナ用にさらに 2048 MB が必要になるため、その時点では 8 GB が実質的な必須要件になります。

Arm VPS で LiveContext を実行できますか？

できません。公開されているすべてのイメージは linux/amd64 向けにビルドされているため、Arm プランでは pull 時に docker compose up が no matching manifest for linux/arm64/v8 in the manifest list entries で失敗します。理論上は QEMU エミュレーションで実行できますが、JVM ワークロードでは実用になりません。x86 プランを選択してください。

model API key はどこに設定しますか？

初回起動前に docker/.env.ce へ ANTHROPIC_API_KEY、OPENAI_API_KEY、または GOOGLE_API_KEY として設定します。backend と bridge は起動時にこの値を読み込み、1 ユーザーではなくインスタンス全体に適用します。ファイルの mode は 600 にし、このサーバー専用に作成した key を使用して単独で revoke できるようにしてください。また、provider のコンソールで spend cap を設定してください。マシンの外部で適用される制限は、この cap だけだからです。

LiveContext をバックアップするにはどうすればよいですか？

必要なのは 3 つです。livecontext データベースの pg_dump、MinIO volume のコピー、そして docker/.env.ce ファイルです。最初の 2 つを取得する間は livecontext サービスと frontend サービスを停止し、データベースと object store の整合性を保ってください。env ファイルも重要です。workflow に保存される credentials は CREDENTIAL_ENCRYPTION_PASSWORD と CREDENTIAL_ENCRYPTION_SALT で暗号化されているため、これらの値なしで restore すると、新しいマシンでは credential の行を読み取れなくなります。

起動後、backend が `health: starting` のまま数分間変わらないのはなぜですか？

compose の healthcheck は start_period: 120s を設定し、/actuator/health を polling します。そのため、schema migration と tool registration の実行中、Docker はサービスを starting と報告します。初回起動で 2〜3 分かかるのは想定内です。healthy にならない場合は docker compose logs -f livecontext を確認してください。migration の段階で停止する stack は、通常、新しい release のデータベース volume を参照しています。

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