著者 VPS向けOpen WebUI代替4選を比較
VPSでOpen WebUI、LibreChat、Hollama、OrionChatを比較します。モデル用に残るRAM、ログイン、リモートOllama対応、保守負担を確認できます。
VPS にはどの Open WebUI 代替が適しているか
Open WebUI の代替プロジェクトは、RAM が安価で、パブリックアドレスで待ち受けるサービスもないノート PC 上で比較されることがほとんどです。VPS ではこの 2 つの前提が変わるため、評価順位も変わります。2 人目のユーザーがログインする時点で、Open WebUI が引き続き標準の選択肢になります。実ユーザーアカウントと管理パネルを備えているためです。インターフェースとモデルが残り 1 GB の RAM を奪い合う場合は、軽量なプロジェクトが有利です。ただし、その代わりに認証機能がありません。
以下は、各プロジェクトの公式ドキュメントを 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 を保持するチャットインターフェースが、モデルを実行できるかどうかを左右します。
比較記事の数値は、この記事の数値も含めて、鵜呑みにせず実測してください。実際の使用を開始してから 1 時間後に docker stats --no-stream を実行します。コンテナの起動直後 1 分では不十分です。重要なメモリは、最初の使用時に確保されるためです。
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: プレフィックスを付けると、loopback に限定できます。VPS では、このプレフィックスが行内の他の指定より重要です。Docker は独自の iptables ルールを書き込み、公開ポートには ufw の deny ルールが適用されないためです。
下記で説明するトンネルまたはプロキシ経由でページにアクセスし、最初のアカウントを作成します。そのアカウントが管理者になります。後から作成されるアカウントには pending ロールが割り当てられます。これは DEFAULT_USER_ROLE として文書化されている既定値です。そのため、ページにアクセスした第三者は、管理者が承認するまでモデルを使用できません。
Open WebUI は機能が多いため、下記のプロジェクトより多くのメモリを消費します。Open WebUI 自身のパフォーマンスページには、メモリを消費する部分が記載されています。既定の embedding エンジンは、コンテナ内で sentence-transformers モデルを読み込みます。文書では、worker process 1 つあたり約 500 MB とされています。RAG_EMBEDDING_ENGINE=ollama を設定すると、その処理を既に実行している model server に委譲できます。AUDIO_STT_ENGINE=webapi を設定すると、ローカルの speech-to-text モデルの読み込みを回避できます。SQLite で DATABASE_POOL_SIZE が未設定の場合、pool は大きな内部サイズにフォールバックします。各接続が独自の page cache と memory map を確保するため、小規模なホストでは DATABASE_POOL_SIZE=8 と DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 を設定します。ENABLE_AUTOCOMPLETE_GENERATION=False を設定すると、ユーザーが入力中に interface がモデルへ completion を要求する処理を停止できます。
LibreChat: 複数ユーザー対応、背後にスタックを配置
git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -dインターフェースは port 3080 で応答します。ログイン画面ではなく ID システムが必要な場合は、LibreChat を検討します。LDAP と OAuth2 のログインに対応し、ユーザーとロールを管理する admin panel も付属しています。この機能は stack とともに導入されます。
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 file は 6 services を起動します: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API。これらのいずれも model ではありません。MongoDB と pgvector はそれぞれ専用のメモリを必要とします。4 GB のマシンでは、そのメモリが model に必要な容量を圧迫します。
アップグレードは git operation です。ここで間違える人が多くいます。
docker compose down
git pull
docker compose pull
docker compose up -dgit pull は、追跡対象の docker-compose.yml を編集していると conflict で停止します。その結果、アップグレードが中途半端に適用されます。変更は、この用途のためにプロジェクトが用意している docker-compose.override.yml に記述し、secret は .env に保存してください。どちらの file も untracked なので、git pull は変更しません。
librechat.yaml の custom endpoint で、LibreChat が独自の model server を参照するように設定します。
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 を実行しているマシンの address に置き換えます。Ollama は値を無視しますが、apiKey field は必須です。そのため、placeholder を指定できます。LibreChat を Docker で実行し、Ollama を同じマシンで実行する場合、container 内の localhost は container 自体を指します。その場合は 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. と表示されます。別の origin への呼び出しは、許可するまで has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource によって拒否されます。
Ollama でこの2つの設定を変更する公式の方法は、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 origin で動作します。Ollama はこれをデフォルトで許可し、ポートがホストの外部に公開されることもありません。
各サービスからリモートの Ollama または vLLM エンドポイントを使用できますか
Open WebUI は使用できます。接続はサーバー側で確立されます。OLLAMA_BASE_URL=http://model-host:11434 で Ollama を指定します。vLLM またはその他の OpenAI-compatible server では、空でない OPENAI_API_KEY とともに OPENAI_API_BASE_URL=http://model-host:8000/v1 を設定し、必須の /v1 サフィックスを残します。OPENAI_API_BASE_URLS には、セミコロンで区切って複数のバックエンドを指定できます。
LibreChat は、上記に示したカスタムエンドポイントの baseURL を通じて使用できます。このリクエストもサーバーから送信されるため、ブラウザーのルールは適用されません。
Hollama と OrionChat は、設定で入力した任意のエンドポイントを指定できます。ただし、リクエストはブラウザーから送信されます。上記のセクションの内容は、これらにも適用されます。このセクション内の他のサービスには適用されません。
リモートエンドポイントを利用する最大の利点は、インターフェースとモデルを分離できることです。インターフェースを小規模なマシンに配置し、モデルを十分なメモリがあるマシンに配置します。この段階で、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 と ID プロバイダーとしての Authentik を組み合わせると、同じマシン上のすべてのアプリで 1 つのログインと 1 つの証明書を使用できます。Open WebUI を TLS（トランスポート層セキュリティ）の背後に置く場合は、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 を実行してください。ただし、6 つのサービスとモデルを含む構成が実際に収まるか、docker stats で確認してから依存してください。小規模なマシンで1人だけが使い、モデルがすでに RAM の大部分を使用している場合は、Hollama または OrionChat を SSH トンネル経由で提供し、状態の保持はブラウザーに任せてください。VPS で避けるべき構成は、ログインを前段に置かずに、これらのいずれかを 0.0.0.0 で公開することです。
FAQ
Open WebUI をパブリック IP に直接公開しても安全ですか？
Open WebUI のハードニングページでは、データベースや CI サーバーと同じく、非公開の信頼できるネットワーク向けのソフトウェアと説明されています。実際のアカウント機能があり、最初に作成したアカウントは管理者になります。後から作成したアカウントは、承認されるまで pending のままです。そのため、ログイン機能のない UI よりははるかに安全です。それでも、TLS を設定したリバースプロキシの背後に置き、可能であればシングルサインオンも使用してください。Docker 自身の iptables ルールによって意図せずインターネットへ公開されないよう、コンテナポートは 127.0.0.1:3000:8080 として公開してください。
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 互換サーバーでは、/v1 サフィックスを付けた OPENAI_API_BASE_URL を使用し、空でない API key を指定してください。Hollama と OrionChat でも任意の接続先を指定できます。ただし、リクエストはブラウザーから送信されるため、エンドポイントもブラウザーから到達可能でなければなりません。
ブラウザーのチャット UI から Ollama に接続できないのはなぜですか？
ほとんどの場合、原因は2つです。Ollama はデフォルトで 127.0.0.1:11434 に bind するため、OLLAMA_HOST を変更しない限り、別のマシン上のブラウザーから接続できません。また、Ollama は localhost からのクロスオリジンリクエストだけを受け付けます。そのため、自身のドメインから配信されたページは、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 経由でポートを転送すれば、この問題は解消します。