Docker
単一サーバーに本番環境に近い形でデプロイするなら、Docker が最も簡単です。
インターネットからアクセスできる単一サーバー環境では、
非公開リモートデプロイから始めてください。この Compose テンプレートは
アプリケーションのポートを公開せず、既定で main イメージを使用し、外側に Cloudflare Access の境界、
ホスト制御、バックアップ、コンテナ制限を追加します。
Work の利用可否
リポジトリの Compose ファイルでは、Work が既定で有効です。イメージには Docker CLI が含まれ、
Compose は /var/run/docker.sock をマウントします。そのため、Work のタスクコンテナは
Libre WebUI コンテナの 兄弟コンテナ として動作し、ホスト上の docker ps に表示されます。
このソケットにアクセスできるプロセスは、Docker ホストに対して root と同等の制御権限を持ちます。 Work は主要機能であり、デーモンへのアクセスなしでは動作できないため、既定で有効にするのは意図的な選択です。 その結果、Libre WebUI のすべての管理者は、実質的にホスト管理者となります。次の点を踏まえて運用してください。
- 管理者をすでに信頼しているホスト上でスタックを運用する。
- 公開ポートを信頼できないネットワークに露出しない。
- Work が不要な場合は
/var/run/docker.sockのマウントを削除する。その場合、Work ページには ランタイムを利用できません と表示されます。
Linux ではソケットを所有するのは root ではなく docker グループなので、root 以外のアプリユーザーには
そのグループ ID が必要です。次のコマンドで一度設定します。
echo "DOCKER_GID=$(docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
alpine stat -c '%g' /var/run/docker.sock)" >> .env
上記のとおり、コンテナを介して値を読み取ってください。macOS ホストでは Docker Desktop が VM 経由で ソケットをプロキシするため、ホストが報告する値とコンテナから見える値が異なります。グループが誤っている場合、 Work ページは黙って失敗せず、問題の内容を表示します。Work：隔離されたワークスペースも参照してください。
Work のプレビューと Work Computer は、ランダムなポートをプライベートなホスト
インターフェイス上にのみ公開します。Docker Desktop では Compose の既定値のままで
動作します。バインド先はホストのループバック、バックエンドからの接続には
host.docker.internal を使います。ネイティブの Docker Engine では、兄弟コンテナから
ホストのループバック上のリスナーへ到達できません。代わりに、公開されていない
Docker ブリッジのゲートウェイをバインド先に設定してください。
echo "WORK_PREVIEW_BIND=$(docker network inspect bridge \
--format '{{(index .IPAM.Config 0).Gateway}}')" >> .env
echo "WORK_DOCKER_PUBLISHED_HOST=host.docker.internal" >> .env
docker compose up -d --force-recreate libre-webui
Compose ファイルは host-gateway を介して host.docker.internal をマップします。
WORK_PREVIEW_BIND=0.0.0.0 は絶対に使わないでください。認証されていない一時的な
タスクポートが、Libre WebUI の署名付きプロキシの内側ではなく、すべてのホスト
インターフェイス上に公開されてしまいます。
Ollama 同梱構成
Libre WebUI と Ollama を 1 つの Compose スタックで実行します。
docker compose up -d
http://localhost:8080 を開きます。
WebUI のポートは既定でホストのループバックにバインドされます。信頼できる LAN またはホストの
リバースプロキシからアクセスする必要がある場合に限り、WEBUI_BIND_ADDRESS=0.0.0.0 を設定し、
ホストのファイアウォールでポートを制限してください。
Ollama は Compose ネットワーク内からのみアクセスできます。ホストのアプリケーションから ループバック経由で利用できるようにするには、明示的なホスト用オーバーライドを追加します。
docker compose -f docker-compose.yml -f docker-compose.ollama-host.yml up -d
別のマシンから Ollama にアクセスする必要がある場合に限り OLLAMA_BIND_ADDRESS を設定し、
ファイアウォールと認証対応プロキシでそのポートを保護してください。
NVIDIA GPU
Docker から NVIDIA ランタイムにアクセスできる場合は、GPU 用 Compose ファイルを使用します。
docker compose -f docker-compose.gpu.yml up -d
モデルが依然として CPU 上で動作する場合は、Ollama コンテナから GPU にアクセスできることを確認してください。
外部 Ollama
Ollama がホストまたは別のサーバーですでに動作している場合に使用します。
docker compose -f docker-compose.external-ollama.yml up -d
必要に応じて Ollama の URL を上書きします。
OLLAMA_BASE_URL=http://192.168.1.10:11434 docker compose -f docker-compose.external-ollama.yml up -d
ソケットを隔離した Work
標準の Compose ファイルは Docker ソケットを Libre WebUI コンテナにマウントし、Work からタスクコンテナを 実行できるようにします。このマウントは Docker ホストに対する root と同等の制御権限を与えます。 Web アプリケーションにソケットを渡さずに Work を利用するには、socket-proxy バリアントを使用します。
docker compose -f docker-compose.socket-proxy.yml up -d
内部ネットワーク上のソケットプロキシが /var/run/docker.sock を保持し、Work が使う API セクション
（containers、images、volumes、networks、exec、info）だけを転送します。Swarm、secrets、configs、build、
system の各エンドポイントはプロキシで拒否されます。Libre WebUI は
DOCKER_HOST=tcp://docker-socket-proxy:2375 経由でアクセスします。ソケットのマウントも
DOCKER_GID も不要で、対話型ターミナルとシステム診断は変わらず動作します。この境界で保護できる範囲と
できない範囲については、Workspaces のドキュメントを参照してください。
データの永続化
Libre WebUI はバックエンドデータをコンテナ内の /app/backend/data に保存します。Compose ファイルはこのパスを名前付きボリュームとしてマウントします。
イメージを docker run で直接起動した場合も、既定で同じパスを使用します。データベースの事前チェック用
一時領域は /app/backend/temp に分離されています。コンテナを再作成する可能性がある場合は、
必ず /app/backend/data をマウントしてください。
本番環境では安定したシークレットを設定します。
JWT_SECRET=replace-with-a-long-random-secret
ENCRYPTION_KEY=replace-with-64-hex-characters
データボリュームと暗号化キーは一緒にバックアップしてください。
古いイメージから直接起動したコンテナを削除する前に、/app/backend/data/.encryption_key が存在することを
確認するか、設定済みの ENCRYPTION_KEY を記録してください。古いイメージでは、自動生成されたキーが
コンテナレイヤーにしか書き込まれない場合があり、そのコンテナを削除すると、永続化データベースを復号できる
唯一のキーも失われます。
独自の Work 対応ランタイムを運用している場合、タスクファイルは別の Docker 名前付きボリュームに保存され、
通常の /app/backend/data バックアップには含まれません。
公開アクセス
リポジトリの Compose ファイルは WebUI をループバックにバインドし、CORS_ORIGIN を直接設定しています。
シェルまたは .env ファイルの値では、そのリテラルを上書きできません。
libre-webui.environment エントリを編集するか、明示的なオーバーライドを compose.origin.yml として保存します。
services:
libre-webui:
environment:
CORS_ORIGIN: https://your-domain.example
BASE_URL: https://your-domain.example
選択したリポジトリの Compose ファイルと一緒にオーバーライドを適用します。
docker compose -f docker-compose.yml -f compose.origin.yml up -d
その後、HTTPS 対応のリバースプロキシまたはプラットフォームのロードバランサーの背後に Libre WebUI を配置します。
WEBUI_BIND_ADDRESS には、そのプロキシが必要とするインターフェースを正確に設定してください。
ファイアウォールの要件がない限り、すべてのインターフェースでポートを公開しないでください。
サーバーはビルド済みのフロントエンドをすでに効率よく配信しています。/js/ と /assets/ 配下の
ハッシュ付きバンドルは brotli または gzip で圧縮され、1 年間の immutable キャッシュ期間が付きます。
一方 index.html と Service Worker は no-cache として扱われるため、新しいリリースは次回の
読み込みで反映されます。プロキシ側でこれらのパスを再圧縮したりキャッシュしたりする必要はありません。
Accept-Encoding はそのまま透過させてください。
よく使うコマンド
docker compose ps
docker compose logs -f libre-webui
docker compose logs -f ollama
docker compose pull
docker compose up -d