著者 VPS向けOpen WebUI代替の比較と選び方
パブリックIPのVPSでOpen WebUI、LibreChat、Hollama、OrionChatを比較します。モデル用に残るRAM、ログイン、リモートOllama、保守負荷の違いが分かります。
VPS に適した Open WebUI の代替はどれか
Open WebUI の代替製品は、RAM が安価で、パブリックアドレスで待ち受けるサービスもないノート PC 上で比較されることがほとんどです。VPS ではこの2つの条件が変わるため、評価順位も変わります。2人目のユーザーがログインする時点で、Open WebUI が引き続き無難な選択肢です。実際のユーザーアカウントと管理パネルを備えているためです。インターフェースとモデルが残りの RAM 1 GB を取り合う場合は、より軽量なプロジェクトが有利です。ただし、その代償として認証機能がありません。
以下の内容は、各プロジェクトの公式ドキュメントを2026年8月に確認した結果に基づいています。評価軸は4つです。いずれも、サーバーがインターネットから到達可能になって初めて重要になります。
パブリック IP でのみ重要になる 4 つの観点
- モデルの近くに必要なメモリ。モデルサーバーは、そのホスト上で最も多くのリソースを消費するプロセスです。インターフェースが使用するメモリが 1 MB 増えるごとに、モデルが使用できるメモリは 1 MB 減ります。
- 認証。ユーザーアカウントとロールに対応しているプロジェクトもあります。一方で、ノート PC 上で自分だけが実行することを前提とし、ログイン機能を持たないプロジェクトもあります。
- リモート推論。
127.0.0.1:11434にしか接続できない UI では、モデルをインターフェースと同じホスト上で実行する必要があります。 - 保守。SQLite ファイルを使用する 1 つのコンテナと、MongoDB およびベクトルデータベースを背後に置く 6 つのコンテナでは、運用負荷が異なります。
モデルはインターフェース用にどれだけ RAM を残すか
サーバー上で最も大きなものはインターフェースではありません。モデルです。モデルが応答している間は重みをメモリ上に保持する必要があるため、公開されているダウンロードサイズは最低限の目安になります。さらに、コンテキストキャッシュが確保されると、実際のメモリ使用量はダウンロード後のサイズを上回ります。
The data behind this chart
[
{
"label": "llama3.2:3b",
"download_gb": "2.0"
},
{
"label": "qwen3:4b",
"download_gb": "2.5"
},
{
"label": "gemma3:4b",
"download_gb": "3.3"
},
{
"label": "qwen3:8b",
"download_gb": "5.2"
}
]これらは、Ollama のライブラリページに 2026 年 8 月に掲載されていた数値です。実測値ではなく、公開サイズです。4 GB の VPS では、qwen3:4b は 2.5 GB あるため、オペレーティングシステムやその他すべてに残る容量は 1.5 GB 未満です。会話が長くなると、コンテキストキャッシュがその容量をさらに消費します。qwen3:8b は 5.2 GB あるため、そのサーバーにはまったく収まりません。これはノート PC の比較記事では扱われない状況です。数百 MB を保持するチャットインターフェースが、モデルを実行できるかどうかを左右します。これらのタグを大幅に上回るモデル用にサーバーの容量を見積もる場合は、CPU のみの VPS で 27B モデルを動かす計算を見ると、インターフェースが判断要素でなくなるまでの速さが分かります。
比較記事にある数値を含め、どの数値もそのまま信用せず、実測してください。実運用を開始して 1 分後ではなく 1 時間後に docker stats --no-stream を実行してください。重要なメモリは、初回使用時に確保されるためです。
Open WebUI: 複数ユーザーでも依然として標準的な選択肢
Open WebUI は 1 つのイメージで動作し、データを 1 つのボリュームに保存します。
docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:mainプロジェクトの README にあるコマンドは -p 3000:8080 を公開します。このポートはすべてのインターフェースで待ち受けます。127.0.0.1: プレフィックスを付けると、ループバックに限定できます。VPS では、このプレフィックスが行内の他の何よりも重要です。Docker は独自の iptables ルールを書き込み、公開ポートには ufw の deny ルールが適用されないためです。
以下で説明するトンネルまたはプロキシ経由でページにアクセスし、最初のアカウントを作成します。このアカウントが管理者になります。その後に作成されるアカウントには、DEFAULT_USER_ROLE の仕様上のデフォルトである pending ロールが設定されます。そのため、見知らぬユーザーがページに到達しても、管理者が承認するまでモデルを使用できません。
Open WebUI は機能が多いため、以下のプロジェクトより多くのメモリを消費します。Open WebUI 自身のパフォーマンスページには、メモリを消費する要素が記載されています。デフォルトの埋め込みエンジンは、コンテナ内で sentence-transformers モデルを読み込みます。ドキュメントでは、ワーカープロセスごとに約 500 MB とされています。RAG_EMBEDDING_ENGINE=ollama を設定すると、すでに実行しているモデルサーバーにその処理を委任できます。AUDIO_STT_ENGINE=webapi を設定すると、ローカルの音声テキスト変換モデルの読み込みを避けられます。SQLite で DATABASE_POOL_SIZE が未設定の場合、プールは大きな内部サイズにフォールバックします。各接続が独自のページキャッシュとメモリーマップを確保するため、小規模なサーバーでは DATABASE_POOL_SIZE=8 と DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 を設定します。ENABLE_AUTOCOMPLETE_GENERATION=False を設定すると、ユーザーが入力中にインターフェースがモデルへ補完を要求する動作を停止できます。
LibreChat: 複数ユーザー対応と、その背後で動くスタック
git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -dインターフェースは 3080 番ポートで接続を受け付けます。ログイン画面ではなく認証基盤が必要な場合は、LibreChat が候補になります。LDAP と OAuth2 によるログインに対応し、ユーザーとロールを管理する管理パネルも備えています。この機能は、複数のサービスで構成されるスタックとともに提供されます。
The data behind this chart
[
{
"label": "OrionChat",
"containers": 0,
"notes": "static files, served by a web server you already run"
},
{
"label": "Hollama",
"containers": 1,
"notes": "one container serving a browser app"
},
{
"label": "Open WebUI",
"containers": 1,
"notes": "application and SQLite in one image"
},
{
"label": "LibreChat",
"containers": 6,
"notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
}
]デフォルトの compose ファイルは 6 個のサービスを起動します: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API。これらのどれもモデルではありません。MongoDB と pgvector はそれぞれ専用のメモリを必要とするため、4 GB のマシンでは、その分だけモデルに使えるメモリが減ります。
アップグレードは git 操作で行います。ここを誤るケースが多くあります。
docker compose down
git pull
docker compose pull
docker compose up -d追跡対象の docker-compose.yml を編集していると、git pull は競合が発生して停止します。その結果、アップグレードが途中まで適用された状態になります。この用途のためにプロジェクトが用意している docker-compose.override.yml に変更を記述し、Secret は .env に保存してください。どちらのファイルも未追跡なので、git pull は変更しません。
librechat.yaml のカスタムエンドポイントを設定して、LibreChat から独自のモデルサーバーを指定します。
endpoints:
custom:
- name: "Ollama"
apiKey: "ollama"
baseURL: "http://model-host:11434/v1/"
models:
default: ["llama3.2"]
fetch: true
titleConvo: true
titleModel: "current_model"
modelDisplayLabel: "Ollama"model-host を Ollama が動作しているマシンのアドレスに置き換えます。Ollama は値を無視しますが、apiKey フィールド自体は必要です。そのため、プレースホルダーを指定できます。LibreChat を Docker で実行し、Ollama を同じマシンで実行する場合、コンテナ内の localhost はコンテナ自身を指します。そのため、そこでは host.docker.internal を使用してください。
Hollama と OrionChat: 処理はブラウザーで行います
Hollama は、1 つの小さなコンテナからブラウザーアプリケーションを提供します。チャットはサーバーではなく、ブラウザーのストレージに保存されます。
docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latestREADME に記載されたこのコマンドでは --rm を使用しています。これはコンテナの停止時にコンテナを削除するため、再起動後にインターフェースが戻りません。リバースプロキシの背後で使用する場合は -e VITE_ALLOWED_HOSTS='chat.example.com' を追加してください。このイメージはホスト名 localhost だけを許可するためです。それ以外のホスト名へのリクエストには、アプリケーションではなく blocked-host エラーを返します。
OrionChat はさらに単純で、サーバーコンポーネントがまったくありません。リポジトリをクローンし、すでに実行している Web サーバーでそのフォルダーを提供するか、ディスク上の index.html を開きます。API キーはブラウザーの localStorage に保存され、チャット履歴もブラウザー内に残ります。チャット数が 512 を超えると、古いチャットから削除されます。
どちらのプロジェクトにもログイン機能はありません。ログインを確認するサーバーが存在しないためです。ラップトップでは問題ありません。しかし VPS では、このページを 0.0.0.0 で公開してはいけません。さらに、見落としやすい点があります。モデルを呼び出すのはサーバーではなくブラウザーです。
この点によって、これら 2 つを使用できる場所が決まります。ブラウザーから Ollama に直接接続する必要があるため、Ollama は loopback 以外でも待ち受ける必要があります。また、Ollama には認証機能が一切ありません。ここから、ブラウザーに関する 2 つのルールが導かれます。HTTPS で提供されたページから、通常の HTTP エンドポイントを呼び出すことはできません。コンソールには Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked. と表示されます。許可するまで、別のオリジンへの呼び出しは has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource で拒否されます。
Ollama がどちらの設定も変更するために文書化している方法は、systemd の override です。
sudo systemctl edit ollama.service[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434ss の出力は、以前 127.0.0.1:11434 と表示されていた箇所で、0.0.0.0:11434 になるはずです。この変更は、ファイアウォールまたは認証機能を持つプロキシによって、そのポートへ接続できるユーザーがすでに制御されている場合にだけ行ってください。11434 を開放するとモデルサーバーも公開されるためです。大量スキャナーは、新しく公開されたポートにすぐ到達します。以下の SSH トンネルを使えば、この問題全体を回避できます。その場合、ページは localhost オリジンで実行されます。これは Ollama がデフォルトで許可するオリジンです。また、ポートがホストの外部に公開されることもありません。
各サービスからリモートの Ollama または vLLM エンドポイントを利用できますか
Open WebUI は利用できます。接続はサーバー側から行われます。OLLAMA_BASE_URL=http://model-host:11434 で Ollama を指定します。vLLM またはその他の OpenAI 互換サーバーを使用する場合は、値が空でない OPENAI_API_KEY を含む OPENAI_API_BASE_URL=http://model-host:8000/v1 を設定し、必須の /v1 サフィックスを残します。OPENAI_API_BASE_URLS には、セミコロン区切りで複数のバックエンドを指定できます。
LibreChat では、上記のカスタムエンドポイントに表示される baseURL を通じて利用できます。このリクエストもサーバーから外部へ送信されるため、ブラウザーのルールは適用されません。同じベース URL と同じプレースホルダーキーはチャット画面の外でも使用できます。これだけで、すでにホストしているモデルを コーディングエージェントから利用できます。
Hollama と OrionChat では、設定で入力した任意のエンドポイントを指定できます。ただし、リクエストはブラウザーから外部へ送信されます。上のセクションの内容は Hollama と OrionChat にも適用されますが、ここで挙げた他のサービスには適用されません。
リモートエンドポイントを利用する最大の利点は、インターフェースとモデルを分離できることです。インターフェースを小規模なマシンに配置し、メモリに余裕のある場所でモデルを実行します。複数のユーザーが同時にモデルへアクセスした場合、Ollama と vLLM は動作が大きく異なります。そのため、リクエストを Ollama と vLLM のどちらで処理するかも、この段階で決めます。モデルサーバーがまだない場合は、まず VPS で Ollama を実行する方法を確認してください。CPU のみのマシンでは、実行基盤を選ぶ前に Ollama と llama.cpp の比較を読んでください。
0.0.0.0 でログインなしのチャット UI を公開しない
Open WebUI のハードニングページには、このプロジェクトは「データベース、コンテナレジストリ、CI サーバーなど、ほかの自己ホスト型インフラと同様に、プライベートで信頼できるネットワーク向けに構築されている」と記載されています。また、VPN の背後、または認証付きのリバースプロキシの背後に配置するよう案内されています。ログイン機能がまったくないプロジェクトには、少なくとも同じ対策が必要です。
何かを信頼する前に、待ち受けているポートを確認してください。
sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'127.0.0.1:3000 と表示される行が正しい状態です。0.0.0.0:3000 と表示される行は、チャットインターフェースがパブリックインターネット上にあることを意味します。自分のマシンから curl -sI http://YOUR.VPS.IP:3000 が HTTP/1.1 200 OK に応答する場合も、同じことをより明確に示しています。
WEBUI_AUTH=False で Open WebUI のログインを無効にする設定は、ほかのユーザーがアクセスできないマシンで使う単一ユーザー向けの設定です。すでにアカウントが存在するインストールには適用されず、You can't turn off authentication because there are existing users. というメッセージが表示されます。
パターン 1: loopback にバインドし、SSH 経由でアクセスする。 すべてのポートを 127.0.0.1 で公開し、必要なポートだけを転送します。ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com を実行し、ノート PC で http://localhost:3000 を開きます。何も公開されないため、スキャンも受けません。Hollama または OrionChat では、同じコマンドに -L 11434:127.0.0.1:11434 を指定してモデルのポートも転送し、Ollama は loopback で待ち受けさせます。このパターンの安全性は SSH の設定に依存するため、鍵認証のみの SSH と強化した sshd と組み合わせてください。
パターン 2: アプリがリクエストを受け取る前に認証するリバースプロキシを使う。 アプリは loopback で待ち受けさせ、プロキシに 443 番ポートを担当させ、前段にシングルサインオンを配置します。Docker Compose のラベルで構成する Traefik と アイデンティティプロバイダーとしての Authentik を使うと、同じマシン上のすべてのアプリでログインと証明書を共通化できます。Open WebUI を TLS（transport layer security）の背後に配置する場合は、WEBUI_SESSION_COOKIE_SECURE=true と WEBUI_SESSION_COOKIE_SAME_SITE=strict を設定します。JWT_EXPIRES_IN も、デフォルトの 4 週間より短くしてください。Open WebUI のドキュメントによると、Redis がない場合、ログアウトしてもトークンは無効にならず、自然に期限切れになるまで使用できるためです。
パターン 2 では、ブラウザーだけで動作するプロジェクトは保護できません。ページの前段にプロキシを置いてもモデルのエンドポイントは保護されません。また、そのページから別のホスト名へ fetch してもセッション Cookie は送信されません。そのため、Ollama の前段にある認証プロキシはログインフォームへのリダイレクトを返し、チャットが失敗します。モデルのエンドポイントをページと同じホスト名の配下にルーティングするか、パターン 1 を使用してください。
選択基準
自分以外の利用者もいる場合は、Open WebUI を使用してください。実際のアカウント機能があり、新規ユーザーは承認待ちキューに入ります。保守担当者が公開しているハードニングのガイダンスにも従えます。LDAP や管理パネルが必要な場合は、LibreChat を使用してください。依存する前に、docker stats で 6 つのサービスと使用するモデルを合わせて実行できるか確認してください。モデルが小規模なサーバーの RAM の大半をすでに使用しており、利用者が 1 人だけの場合は、SSH トンネル経由で Hollama または OrionChat を提供し、状態はブラウザーに保持させてください。VPS で避けるべき構成は、ログイン機能を前段に置かず、いずれかを 0.0.0.0 で公開することです。
FAQ
Open WebUI をパブリック IP に直接公開しても安全ですか？
Open WebUI の強化ガイドでは、データベースや CI サーバーと同じく、非公開の信頼できるネットワーク向けのソフトウェアと説明されています。実際のアカウント機能があり、最初に作成したアカウントは管理者になります。一方、後から作成したアカウントは承認されるまで pending のままなので、ログイン機能のない UI よりはるかに安全です。それでも、TLS を有効にしたリバースプロキシの背後に配置し、可能であればシングルサインオンも使用してください。コンテナのポートは 127.0.0.1:3000:8080 として公開してください。これにより、Docker 独自の iptables ルールが意図せずインターネットへ公開することを防げます。
VPS で最も少ない RAM で動作する Open WebUI の代替はどれですか？
ブラウザー上で動作する Hollama と OrionChat です。アプリケーションはクライアント側で動作するためです。サーバーが配信するのは静的ファイルだけで、OrionChat ではアプリケーションコンテナも必要ありません。Open WebUI は Python プロセス、データベース、さらにデフォルトではローカルの埋め込みモデルをメモリに保持します。埋め込みモデルだけで、ワーカーごとに約 500 MB と記載されています。機能の有効化状況によって変わるため、docker stats --no-stream を使って実際のサーバーでも確認してください。
これらのチャット UI は別のホストにある Ollama サーバーを使用できますか？
Open WebUI と LibreChat は使用できます。接続するのはサーバーなので、ブラウザーの制約は適用されません。Open WebUI では OLLAMA_BASE_URL を設定し、LibreChat ではカスタムエンドポイントに baseURL を設定してください。vLLM やその他の OpenAI 互換サーバーを使用する場合は、OPENAI_API_BASE_URL に /v1 のサフィックスを付け、空でない API key を指定してください。Hollama と OrionChat でも任意の接続先を指定できますが、リクエストはブラウザーから送信されます。そのため、エンドポイントにはブラウザーからも到達できる必要があります。
ブラウザーのチャット UI から Ollama に接続できないのはなぜですか？
ほぼすべてのケースは、2 つの原因に分けられます。Ollama はデフォルトで 127.0.0.1:11434 に bind するため、別のマシンにあるブラウザーからは、OLLAMA_HOST が変更されるまで接続できません。また、Ollama は localhost からの cross-origin リクエストだけを受け付けます。そのため、自分のドメインから配信されたページは、OLLAMA_ORIGINS にその origin が登録されるまで No 'Access-Control-Allow-Origin' header is present on the requested resource で拒否されます。ページが HTTPS でエンドポイントが HTTP の場合、Ollama がリクエストを受け取る前に、ブラウザーが mixed content としてブロックします。両方の変数を systemctl edit ollama.service の override に設定してください。または、SSH 経由でポートを転送すれば、この問題は解消します。