著者 VPS向けOpen WebUI代替を比較
公開IPのVPSでOpen WebUI、LibreChat、Hollama、OrionChatを比較します。モデル用RAM、ログイン、リモートOllama、保守性の違いと適した構成が分かります。
VPS にはどの Open WebUI 代替が適しているか
Open WebUI の代替製品は、RAM が安価で、パブリックアドレスで待ち受けるサービスもないノートパソコン上で比較されることがほとんどです。VPS ではこの2点が変わるため、評価順位も変わります。2人目のユーザーがログインする時点で、Open WebUI が引き続き有力な既定の選択肢です。実際のユーザーアカウントと管理者パネルを備えているためです。インターフェースとモデルが残りの 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 のライブラリページに August 2026 時点で表示されていた数値です。実測値ではなく、公開サイズです。4 GB の VPS では、qwen3:4b は 2.5 GB を使用するため、オペレーティングシステムとその他すべてに残る容量は 1.5 GB 未満です。会話が長くなるとコンテキストキャッシュもその容量を消費します。そのため、設定する num_ctx は品質だけでなくメモリにも関わる判断になります。qwen3:8b は 5.2 GB なので、そのマシンにはまったく収まりません。これはノートパソコンの比較記事では扱われない状況です。数百 MB を保持するチャットインターフェースが、モデルを実行できるかどうかを左右します。これらのタグを大きく上回るモデル用にマシンの容量を見積もる場合は、CPU のみの VPS で 27B モデルを動かす計算を見ると、インターフェースが判断要素でなくなるまでの速さが分かります。
比較記事の数値も含め、どの数値もそのまま信頼せずに実測してください。実際の使用を開始してから 1 分後ではなく、1 時間後に docker stats --no-stream を実行します。重要なメモリは初回使用時に割り当てられるためです。Ollama はアイドル状態が 5 分続くと重みも解放します。そのため、会話の合間に測定するとピーク値を過小評価します。次のメッセージでは、keep_alive でモデルを常駐させる設定にしない限り、モデル全体を再び読み込む必要があります。
Open WebUI: 2 人以上で使う場合も依然として標準的な選択肢
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 ルールを無視するためです
以下で説明する tunnel または proxy を通じてページにアクセスし、最初のアカウントを作成します。このアカウントが administrator になります。その後に作成されるアカウントには、DEFAULT_USER_ROLE として文書化されているデフォルトの役割 pending が割り当てられます。そのため、第三者がページに到達しても、administrator が承認するまでモデルを使用できません。
Open WebUI は機能が多いため、以下のプロジェクトより多くのメモリを消費します。Open WebUI の performance ページには、メモリを消費する構成要素が記載されています。デフォルトの embedding engine は、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 は大きな内部サイズにフォールバックします。また、各 connection が独自の page cache と memory map を拡張するため、小規模なサーバーでは DATABASE_POOL_SIZE=8 と DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 を設定します。ENABLE_AUTOCOMPLETE_GENERATION=False を設定すると、ユーザーが入力中に interface が model に completion を要求する動作を停止できます。
LibreChat: 複数ユーザー対応と、その背後で動くスタック
git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -dインターフェースはポート 3080 で応答します。ログイン画面ではなく、ユーザー識別システムが必要な場合は LibreChat を検討します。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 -dgit pull は、追跡対象の docker-compose.yml を編集していると競合で停止します。その結果、アップグレードが途中まで適用された状態になります。変更内容は、この用途のためにプロジェクトが用意している 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 はさらに進んでおり、サーバー側のコンポーネントがまったくありません。リポジトリを clone して、すでに実行している Web サーバーでそのフォルダーを提供するか、ディスク上の index.html を開きます。API キーはブラウザーの localStorage に保存され、チャット履歴もブラウザー内に残ります。チャット数が 512 を超えると、アプリケーションは古いチャットから削除します。
どちらのプロジェクトにもログイン機能はありません。ログインを確認するサーバーが存在しないためです。ノート PC では問題ありません。しかし 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 でその origin を許可するまで、他の origin への呼び出しは拒否されます。
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 がデフォルトで許可する origin になります。また、ポートがホストの外部に出ることもありません。
それぞれでリモートの 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 suffix は残してください。OPENAI_API_BASE_URLS では、セミコロンで区切って複数のバックエンドを指定できます。
LibreChat では、上記に示したカスタムエンドポイントの baseURL を使用して接続できます。このリクエストもサーバーから送信されるため、ブラウザー側のルールは適用されません。同じ base URL と同じ placeholder key は chat window の外でも使用できます。必要なのは、すでにホストしているモデルを coding agent から利用することだけです。
Hollama と OrionChat では、設定画面に入力した任意のエンドポイントを指定できます。ただし、リクエストはブラウザーから送信されます。上記のセクションの内容はこれらにも適用されますが、ここで挙げた他のものには適用されません。
インターフェースとモデルを分離できることが、リモートエンドポイントを利用する最大の利点です。インターフェースは小規模なマシンに配置し、モデルは十分なメモリを備えた場所で実行します。また、複数の人が同時にモデルへアクセスした場合、Ollama と vLLM は動作が大きく異なります。そのため、リクエストを Ollama と vLLM のどちらで処理するかを決めるのもこの段階です。まだモデルサーバーがない場合は、まず VPS で Ollama を実行することから始めてください。CPU-only のマシンでは、runner を選ぶ前に Ollama と llama.cpp の違いを確認することを推奨します。
0.0.0.0 でログインなしのチャット UI を公開しない
Open WebUI の hardening ページには、このプロジェクトは「データベース、コンテナレジストリ、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 を組み合わせると、同じマシン上のすべてのアプリでログインと証明書を統一できます。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 を実行してください。そのうえで、6 つのサービスとモデルを合わせても要件に適合することを docker stats で確認してから、依存してください。モデルがすでに RAM の大半を使用している小規模なマシンを 1 人で使う場合は、SSH トンネル経由で Hollama または OrionChat を提供し、状態はブラウザーに保持させてください。VPS で避けるべき構成は、ログインなしでそれらのいずれかを 0.0.0.0 に公開することです。
FAQ
Open WebUI をパブリック IP に直接公開しても安全ですか？
Open WebUI 自身の hardening ページでは、データベースや CI サーバーと同じく、プライベートで信頼されたネットワーク向けのソフトウェアと説明されています。実際のアカウント機能があり、最初に作成したアカウントは administrator になり、後から作成したアカウントは承認されるまで pending のままです。そのため、ログイン機能のない UI よりははるかに安全です。それでも、TLS を設定した reverse proxy の背後に置き、可能であれば single sign-on も使用してください。Docker 自身の iptables ルールによって意図せずインターネットへ公開されないよう、コンテナのポートは 127.0.0.1:3000:8080 として公開します。
VPS で最も RAM 使用量が少ない Open WebUI の代替製品はどれですか？
ブラウザーで動作する Hollama と OrionChat です。アプリケーションはクライアント上で実行されるためです。サーバーが配信するのは静的ファイルだけで、OrionChat ではアプリケーションコンテナも必要ありません。Open WebUI は Python プロセス、データベース、さらにデフォルトではローカルの embedding model をメモリに保持します。embedding model だけで worker 1 つあたり約 500 MB と記載されています。機能の有効化状況によって値は変わるため、docker stats --no-stream を使って自分のサーバーでも確認してください。
これらの chat UI から別のホスト上にある Ollama サーバーを使用できますか？
Open WebUI と LibreChat では使用できます。接続はそれぞれのサーバーから行われるため、ブラウザーの制約は適用されません。Open WebUI では OLLAMA_BASE_URL を設定し、LibreChat ではカスタム endpoint に baseURL を設定します。vLLM やその他の OpenAI-compatible server を使用する場合は、/v1 サフィックスを付けた OPENAI_API_BASE_URL を使用し、空でない API key を指定してください。Hollama と OrionChat でも任意の接続先を指定できますが、リクエストはブラウザーから送信されます。そのため、endpoint はブラウザーからも到達可能でなければなりません。
ブラウザーの chat UI から Ollama に接続できないのはなぜですか？
ほぼすべてのケースは、2 つの原因で説明できます。Ollama はデフォルトで 127.0.0.1:11434 に bind するため、OLLAMA_HOST が変更されるまで別のマシン上のブラウザーから到達できません。また、Ollama は localhost からの cross-origin request だけを受け付けます。そのため、自分のドメインから配信されたページは、OLLAMA_ORIGINS にその origin を登録するまで No 'Access-Control-Allow-Origin' header is present on the requested resource で拒否されます。ページが HTTPS で endpoint が HTTP の場合、Ollama がリクエストを受け取る前に、ブラウザーが mixed content として通信をブロックします。両方の変数を systemctl edit ollama.service の override で設定してください。または、SSH 経由でポートを forward すれば、この問題は解消します。