SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor

LiveContextのセルフホスト手順と推奨スペック

LiveContext CEをセルフホストするための構築ガイドです。7つのコンテナで構成されるJavaスタックのメモリ要件8GBへの対応、バージョンv0.3.8の固定、Traefikによるリバースプロキシ設定、およびデータストアのバックアップ方法を具体的に解説します。

LiveContext の概要と運用コスト

LiveContext をセルフホストするには、約 8 GB の RAM を搭載した VPS が必要です。LiveContext CE は、自動化プロセス内で AI エージェントを実行するソース利用可能な自動化プラットフォームです。Java バックエンドを中心に 7 つのコンテナで構成される Docker Compose スタックとして提供されており、そのうち 1 つはセットアップ後に終了するワンショットジョブです。ベンダーのセルフホスト用ドキュメントでは最低 4 GB、推奨 8 GB とされていますが、npm ランチャーの README では現在最低 6 GB と記載されており、compose ファイルからメモリ消費の内訳を確認できます。

このプロジェクトは当初 GitHub 上で livecontext-ai/livecontext-ce として公開され AGPL-3.0 が適用されていましたが、CE 版は現在 AGPL ではありません。現在のリリースに同梱されているライセンスは LiveContext Sustainable Use License 1.1 です。これはソース利用可能なライセンスであり、自社ビジネスの運用環境を含め、CE 版の実行や改変は許可されています。ただし、LiveContext の有料版と競合するような、ホスト型または組み込み型のサービスを第三者に提供することは禁止されています。ベンダーの npm ランチャーを見ると、この変更が確認できます。livecontext@0.2.11 は AGPL-3.0-only を宣言しており、livecontext@0.3.8 は当該ライセンスファイルを参照しています。2026 年 10 月 13 日の時点で、GitHub リポジトリおよび livecontext-ai 組織はどちらも 404 エラーを返しますが、ベンダーのドキュメントでは依然としてクローンするよう指示されているため、本ガイドでは npm パッケージからリリースファイルを取得します。現在のリリースは v0.3.8 で、2026 年 10 月 9 日に公開されました。すべての LiveContext イメージは linux/amd64 専用にビルドされているため、安価な Arm プランは利用できません。本ガイドではそのタグを固定し、スタックをリバースプロキシの背後に配置した上で、アップストリームのバックアップ推奨事項をコマンドとして実行します。

LiveContext をセルフホストする前の VPS サイジング

配布されている compose ファイル内のほとんどのサービスには明示的なメモリ制限が設定されているため、レンタル前にサーバーのサイズを決定できます。ただし、1 回限りの minio-init ジョブとフロントエンドには制限がありません。これらは v0.3.8 compose ファイルに記述された制限値であり、測定された使用量ではありません。

グラフMemory limits in the LiveContext CE v0.3.8 compose file, MB
このグラフのデータ
[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 2048
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "postgres",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "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
  }
]

バックエンド単体で 2048 MB の上限が設定されています。この上限は、ヒープサイズが 1 GiB に設定された Java 21 プロセス（-Xmx1024m、ZGC 使用）に適用されます。compose ファイルのコメントには、ヒープがその 1 GiB まで増加し、さらに JVM 自体のオーバーヘッドが加わると記載されています。制限のある 5 つの基本サービスの合計は約 3.6 GB です。フロントエンドには制限がないため、Node が要求する分だけ消費します。4 GB の VPS では、これらの制限だけでフロントエンド、カーネル、ページキャッシュに割り当てられるメモリが数百 MB しか残りません。そのため、セルフホストのドキュメントには 4 GB と記載されていても、ランチャーの README では最小要件が 6 GB とされています。

オプションのプロファイルを使用すると、8 GB のサーバーが必要になります。ブラウザエージェントプロファイルは、SearXNG 検索インスタンスの横に 2048 MB に制限された Chromium コンテナを追加し、レンダラープロファイルはスクリーンショットや PDF 生成のためにさらに 1024 MB を追加します。どちらもプロファイルを有効にしない限り起動しないため、必要になるまではオフにしておいてください。Chromium コンテナは npm パッケージに含まれていない websearch-service ディレクトリからローカルでビルドされます。そのため、2026 年 10 月 13 日の時点で GitHub リポジトリにアクセスできない場合、公開されているファイルからブラウザエージェントプロファイルをビルドすることはできません。レンダラーは公開済みのイメージを使用するため、影響を受けません。SearXNG コンテナはエージェントの検索バックエンドとして機能します。そのため、返されるページは信頼できないテキストとしてプロンプトに入力されます。これについては AI エージェントに SearXNG Web 検索を許可する で詳しく解説しています。

すでに n8n を運用している場合は、追加するのではなく置き換える計画を立ててください。Docker と HTTPS を使用した VPS での n8n 運用ガイド にあるスタックは、Postgres と 1 つの Node プロセスで構成されており、小規模なサーバーでも快適に動作します。LiveContext は、そのスタック全体が使用するメモリ量よりも多くのメモリをバックエンド単体で確保します。8 GB の VPS で 2 つの自動化プラットフォームを共存させることは可能ですが、両方が同時にジョブを実行するとリソースが枯渇します。ホストを共有する場合は、Docker Compose でメモリ制限を設定する方法 に記載されている手法を用いて、他のすべてのサービスにも明示的な制限を設けてください。これにより、暴走したワークフローがマシン全体を停止させる事態を防げます。

Docker Compose を使用した LiveContext のインストール（タグ固定）

Docker Engine 24 以降および Compose v2 がインストールされた、クリーンな Ubuntu 24.04 VPS を用意してください。Docker が未導入の場合は、まず VPS での Docker Compose の基本 に従い、完了後に戻ってきてください。

ランチャーの README には npx livecontext@latest で開始するコマンドが記載されています。これはノート PC では有効ですが、ランチャーは実行のたびに compose ファイルを再コピーし、指定されるイメージタグは latest となっています。サーバー運用では、管理下のディレクトリに compose ファイルを配置し、特定のリリースに固定することで、アップグレード時に差分を確認できるようにします。ベンダーのドキュメントでは GitHub リポジトリの git clone が推奨されていますが、2026 年 10 月 13 日時点でそのリポジトリは 404 エラーを返すため、必要なリリースの npm パッケージから compose ファイルとサンプル環境ファイルを取得してください。

sudo apt update && sudo apt install -y npm
npm view livecontext version
mkdir -p ~/livecontext-ce/docker ~/livecontext-ce/catalog-seeds
cd ~/livecontext-ce
npm pack livecontext@0.3.8
tar xzf livecontext-0.3.8.tgz
cp package/assets/docker-compose.yml .
cp package/assets/.env.example docker/.env.ce
chmod 600 docker/.env.ce

compose ファイルは ./catalog-seeds をバックエンドにバインドマウントするため、上記でディレクトリを作成しています。npm ランチャーは起動時にダウンロードしたモデルカタログバンドルをこのディレクトリに展開しますが、スタックの初回起動時は空の状態です。

npm パッケージ内の compose ファイルでは、すべての LiveContext イメージが latest タグ（例: ghcr.io/livecontext-ai/livecontext-ce:latest）で指定されていますが、ヘッダーコメントにはリリース固定である旨が記載されています。初回起動前に、自身でタグを固定してください。ベンダーは Docker Hub の livecontext 名前空間で同じリリースタグを公開しており、2026 年 10 月 13 日時点でバックエンド、フロントエンド、ブリッジ、レンダラーの各イメージには v0.3.8 が付与されていました。そのため、これら 4 つのイメージのタグを該当バージョンに書き換えてください。

sed -i -E 's#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v0.3.8#' docker-compose.yml
grep -n 'image:' docker-compose.yml

イメージと同じリリースの compose ファイルを使用することで、両者の整合性が保たれます。v0.3.8 用の compose ファイルは、そのバージョンのイメージに合わせて記述されているためです。タグを latest のままにしないでください。latest タグは意図せず更新される可能性があり、バックエンドは起動のたびにデータベースのマイグレーションを実行するため、誤ってイメージをプルすると深夜にスキーマが自動更新され、リストア以外に戻す手段がなくなります。

初回起動前に 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 ファイル内のデフォルト値が適用され、設定したポートとは異なるポートが公開される可能性があります。

バックエンドのヘルスチェックには start_period が 120 秒設定されており、/actuator/health をポーリングします。そのため、スキーママイグレーションとツール登録が完了するまでの約 2 分間は、docker compose ps で livecontext サービスが health: starting と表示されます。これは正常な動作です。サーバーから以下のコマンドで確認してください。

curl -s localhost:8080/actuator/health

このコマンドで {"status":"UP"} と表示されるはずです。確認できたら、3000 番ポートで Web UI を開いてください。最初に作成したアカウントが管理者になります。管理者が再設定しない限り、それ以降の公開登録は閉じられるため、他のユーザーからポートにアクセスされる前にアカウントを作成してください。これが、初日に 3000 番ポートをインターネットに公開すべきではない最大の理由です。

変更が必要な環境変数

サンプルファイルには、ラップトップ上でスタックを起動できるよう動作するデフォルト値が含まれています。そのうちいくつかは、公開サーバーでは安全ではありません。

DB_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
PUBLIC_BASE_URL=https://lc.example.com
GATEWAY_PUBLIC_URL=https://lc-api.example.com

各ランダム値は openssl rand -base64 32 を使用して生成してください。注意が必要な項目は以下の通りです。

  • DB_PASSWORD と MINIO_ROOT_PASSWORD は、それぞれ postgres と minioadmin として提供されます。Compose ファイルは DB_PASSWORD を Postgres の POSTGRES_PASSWORD として渡します。データベースのポートはホストに公開されないため直接アクセスされることはありませんが、後から同じネットワークに接続したコンテナからは、ドキュメント化されたデフォルト値で両方に到達可能です。
  • CREDENTIAL_ENCRYPTION_PASSWORD と CREDENTIAL_ENCRYPTION_SALT はコメントアウトされた状態で提供されており、空のままにすると初回起動時に自動生成されます。これらは自身で設定してください。ワークフローが保存する認証情報はこれらのペアで暗号化されるため、同じパスワードとソルトなしで新しい環境にデータベースダンプを復元しても、認証情報の行を読み取ることはできません。一度設定したら、docker/.env.ce はバックアップの一部として扱ってください。
  • FRONTEND_PORT と BACKEND_PORT は、ポートマッピングにおいて ${FRONTEND_PORT:-3000}:3000 と ${BACKEND_PORT:-8080}:8080 に代入されます。サンプル環境ファイルでは両方とも # FRONTEND_PORT=3000 および # BACKEND_PORT=8080 としてコメントアウトされているため、行のコメントを外して上書きしない限り、デフォルトの 3000 と 8080 が適用されます。
  • PUBLIC_BASE_URL は Web UI のブラウザ向けアドレスであり、サンプルファイルではサーバーインストール時に GATEWAY_PUBLIC_URL と併せて設定するよう求められます。末尾にスラッシュを付けずに記述してください。サンプルファイルには、スラッシュを付けると OAuth コールバックが機能しなくなるという警告が記載されています。
  • GATEWAY_PUBLIC_URL はバックエンドのブラウザ向けオリジンです。リバースプロキシを導入する場合に重要となります。次のセクションを参照してください。
  • モデルキー（ANTHROPIC_API_KEY、OPENAI_API_KEY、GOOGLE_API_KEY、およびオプションで MISTRAL_API_KEY または DEEPSEEK_API_KEY）は、ここにプレーンテキストで記述します。実際に使用するプロバイダーのみを入力してください。

7つのコンテナの役割

  • postgres は livecontext-db というコンテナ名で pgvector/pgvector:pg16 を実行し、livecontext という名前のデータベースを保持します。埋め込み検索のために pgvector 拡張が必要なため、標準の postgres:16 イメージでは動作しません。
  • redis は appendonly yes および --maxmemory-policy noeviction を指定して redis:7-alpine を実行します。このポリシーは意図的なものです。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 の Web UI です。ホストに公開されるのは、これら最後の2つのみです。

状態は7つの名前付きボリュームに保存されます。livecontext_data (Postgres用)、livecontext_redis、livecontext_minio、livecontext_keys、livecontext_bridge_secret、livecontext_cli_home、そして livecontext_logs です。Compose はプロジェクト名をプレフィックスとして付与し、compose ファイルで livecontext-ce に設定されているため、ディスク上の実際のボリューム名は livecontext-ce_livecontext_minio のようになります。npm ランチャーはこの名前を -p livecontext で上書きするため、かつて npx livecontext を実行していた環境では、livecontext_ がプレフィックスされた2つ目のセットが作成されます。バックアップスクリプトを作成する前に、docker volume ls を実行して正確な名前を確認してください。

docker compose down -v は7つすべてのボリュームを削除します。ベンダーのドキュメントでは、構築したすべてのワークフローを失う最も早い手段であるため、決して実行しないよう警告されています。-v の有無が決定的な違いとなります。

ポート 3000 を公開せず Traefik の背後に配置する

公開 VPS 上でポート 3000 および 8080 を公開すると、TLS (Transport Layer Security) が適用されず、管理者登録の前にゲートも存在しない状態でアプリが露出します。ufw ルールだけでは不十分です。Docker は ufw が管理するチェーンよりも先に、公開ポート用の独自の iptables ルールを挿入するため、0.0.0.0 に公開されたポートは ufw で拒否設定をしていても到達可能なままとなります。

クリーンな解決策は、ポートを一切公開せず、共有 Docker ネットワーク経由でプロキシからコンテナへアクセスさせることです。docker-compose.yml の隣に docker-compose.override.yml を作成します。

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

networks:
  proxy:
    external: true

これが機能するかどうかは 2 つの点に依存します。!override はポートリストをマージするのではなく置換するため、Compose v2.24 以降が必要です。古い Compose では 2 つのリストがマージされポートが公開されたままになるため、docker compose version でバージョンを確認してください。また、default は各 networks リストに残す必要があります。ネットワーク名を指定するとデフォルトのネットワークが置き換えられるため、これを除外するとバックエンドが Postgres や Redis から切断され、フロントエンドもバックエンドから切断されてしまいます。開始前にマージ後の結果を確認してください。

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

ルーター、証明書リゾルバー、および HTTP から HTTPS へのリダイレクトの設定は他のアプリと同様です。そのため、ここで新しい TLS 設定を書くのではなく、1 台の VPS で複数のアプリを運用するための Traefik リバースプロキシガイドに従ってください。1 つのホスト名をポート 3000 の frontend に、もう 1 つをポート 8080 の livecontext にルーティングします。

2 つ目のホスト名は必須です。Web UI はブラウザからバックエンドを呼び出すため、バックエンドにはブラウザが到達可能な独自のオリジンが必要です。docker/.env.ce 内の GATEWAY_PUBLIC_URL をそのバックエンド URL（例: https://lc-api.example.com）に設定し、PUBLIC_BASE_URL をフロントエンド URL に設定してください。これを省略すると、ページは正常に読み込まれますが、すべての操作が失敗します。これは、UI が開いたアドレスからバックエンドのオリジンを解決しようとし、プロキシが公開していないポートを呼び出してしまうためです。

サインアップページは最初に到達した誰にでも開かれているため、フロントエンドルーターに前方認証を導入することをお勧めします。これにより、プロキシで認証しない限り誰もそのページを見ることができなくなります。これについては、独自の SSO レイヤーとして Authentik を実行する方法が、同じ Traefik 設定に追加可能です。

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

ここではエージェントが自動化環境内で実行されるため、単純なワークフローツールとはコスト構造が異なります。プロバイダーキーは docker/.env.ce に ANTHROPIC_API_KEY または OPENAI_API_KEY として設定され、起動時にバックエンドとブリッジによって読み込まれ、インスタンス全体に適用されます。ユーザーごとのスコープはありません。インスタンス上のアカウントを持ち、エージェントを作成できる人は誰でもそのキーを使用してコストを発生させられます。また、最初に登録した人が管理者になります。ユーザーごとのエージェントを用意し、同僚単位で実際の利用額を割り当てたい場合は、1 人 1 エージェントの基盤として OneCLI をセルフホストすることで、別の方法から同じキーの問題に対応できます。すべてのモデルキーを、呼び出し元を識別できるゲートウェイの背後に置く構成です。

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

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

Postgres とオブジェクトストレージのバックアップ

データストアが 2 箇所、シークレットを保持する場所が 2 箇所（env ファイルと livecontext_keys ボリューム）存在します。ベンダーのドキュメントでは、これらもバックアップ対象のボリュームとして記載されています。いずれかを紛失するとインスタンスは復旧できません。データベースの行がダンプされた後にファイルが書き込まれるのを防ぐため、バックエンドを停止した状態で、データベースとバケットを同じタイミングで取得してください。

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 run --rm \
  -v livecontext-ce_livecontext_keys:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-keys-$(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 のステートメントが表示されるはずです。その後、docker-compose.yml とオーバーライドファイルを含め、これら 4 つのファイルをすべてサーバーから外部へコピーしてください。保護対象のサーバー内にのみ存在するバックアップは、バックアップとは呼べません。

新しい環境へ復元するには、同じタグをインストールし、保存しておいた 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

アップグレードと失敗時の復旧

毎回、必ず最初にダンプを取得してください。バックエンドは起動時にスキーママイグレーションを適用しますが、マイグレーションは前方への変更しか行いません。そのため、アップグレードに失敗した後に古いタグへ戻すと、新しいスキーマに対して古いコードが実行されることになります。ロールバックとはダンプをリストアすることを指すため、ダンプの取得が最優先となります。

cd ~/livecontext-ce
npm view livecontext version
TAG=0.3.8
npm pack "livecontext@$TAG"
rm -rf package && tar xzf "livecontext-$TAG.tgz"
cp docker-compose.yml docker-compose.yml.prev
cp package/assets/docker-compose.yml .
sed -i -E "s#ghcr\.io/livecontext-ai/(livecontext-ce[a-z-]*):latest#livecontext/\1:v$TAG#" docker-compose.yml
diff docker-compose.yml.prev docker-compose.yml
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 に、2 番目のコマンドで出力されたバージョンを設定してください。ヘルスチェックのエンドポイントが応答を返すまで、バックエンドのログを監視します。docker-compose.override.yml はパッケージに含まれていないため、新しい compose ファイルをコピーしてもそのまま残ります。ただし、diff コマンドが表示する差分は必ず確認してください。新しいサービスや名称変更されたサービスがある場合、エラーメッセージなしでオーバーライド設定が陳腐化する可能性があるためです。また、新しい設定が追加される可能性があるため、docker/.env.ce と package/assets/.env.example の比較も行ってください。

障害モードと表示される文字列

コンテナの再起動が繰り返され、docker compose ps に exited (137) と表示される。 これはカーネルの out-of-memory killer による終了です。docker inspect livecontext-app の状態ブロック内に "OOMKilled": true があることで確認できます。バックエンドが 2048M の制限に達したか、ホスト側のメモリが枯渇しています。制限を引き上げる前に 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。 ホスト上の別のプロセスがすでにそのポートを使用しています。docker/.env.ce 内で FRONTEND_PORT を設定するか、前述のオーバーライドを適用してポートを公開しないようにしてください。

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

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

LiveContext と n8n の選択

エージェントが主役であれば LiveContext を選択してください。モデルに自動化の構築と実行を任せたい場合、8 GB のサーバーと Java サービスの運用コストを受け入れる必要があります。決定論的なワークフロー、豊富なノードライブラリ、他のサービスと VPS を共有できる軽量さを求めるなら n8n を選択してください。ライセンスによる両者の差異はなくなりました。LiveContext CE は AGPL-3.0 から LiveContext Sustainable Use License 1.1 へ移行しました。これは n8n の Sustainable Use License と同じフェアコードファミリーに属するソース利用可能なライセンスです。社外の誰かに提供する前に、ホスティングに関する制限事項を確認してください。セルフホスト版 n8n には有料顧客向けの機能制限があるため、n8n のどの機能が無料で、どの機能にライセンスキーが必要かを構築前に確認してください。ここで扱うバージョンは新しく、v0.3.8 2026年10月13日時点で 0.3 系は 2026年9月22日から 10月9日の間に 9 回のリリースが行われています。アップグレードのたびにバージョンを固定し、変更点を確認するようにしてください。これら 2 つの中間に位置するツールを含めたより広い範囲については、この 2 つのみの比較ではなく セルフホスト型 n8n 代替ツールのまとめを参照してください。

FAQ

LiveContext をセルフホストするにはどの程度の RAM が必要ですか？

8 GB を計画してください。ベンダーのセルフホスト用ドキュメントでは最小 4 GB、推奨 8 GB と記載されていますが、ランチャーの README では現在最小 6 GB とされており、同梱の compose ファイルにはその理由が示されています。バックエンド単体で 2048 MB の制限があり、制限付きのベースサービス 5 つを合わせると、制限のないフロントエンドコンテナを除いても約 3.6 GB に達します。ブラウザエージェントプロファイルを有効にすると、Chromium と SearXNG コンテナ用にさらに 2048 MB が追加されるため、その時点で 8 GB は必須となります。

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

いいえ。v0.3.8 用に公開されている LiveContext のイメージはすべて linux/amd64 向けにビルドされているため、Arm プランで docker compose up を実行すると 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 のバックアップ方法を教えてください。

以下の 4 点が必要です：livecontext データベースの pg_dump、MinIO ボリュームのコピー、livecontext_keys ボリュームのコピー、そして docker/.env.ce ファイルです。データベースとオブジェクトストレージの整合性を保つため、ダンプとボリュームのコピー中は livecontext および frontend サービスを停止してください。ワークフローに保存された認証情報は CREDENTIAL_ENCRYPTION_PASSWORD と CREDENTIAL_ENCRYPTION_SALT で暗号化されているため、env ファイルが不可欠です。これらがない状態で復元しても、新しい環境では読み取り不可能な認証情報行が残るだけとなります。

起動後、バックエンドが数分間 health: starting のままになるのはなぜですか？

compose のヘルスチェックで start_period: 120s が設定され /actuator/health がポーリングされるため、スキーマ移行とツール登録が実行されている間、Docker はサービスを「起動中」と報告します。初回起動時に 2 ～ 3 分かかるのは正常です。いつまでも正常（healthy）にならない場合は docker compose logs -f livecontext を確認してください。移行ステップで停止する場合、通常はより新しいリリースのデータベースボリュームを参照しています。

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