著者 Matt Connor
VPS向けOpen WebUI代替を比較
公開IPの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 月に確認し、2026 年 10 月 20 日に再確認したものです。さらに、Open WebUI、LibreChat、Hollama、OrionChat については 2026 年 10 月 25 日に再確認しています。Ollama のドキュメントとブラウザーのセキュリティルールは、2026 年 10 月 29 日にも再確認しました。ここで扱う 4 つの評価軸は、サーバーがインターネットから到達可能になって初めて重要になるものです。
パブリック IP でのみ重要になる 4 つの観点
- モデルの近くに必要なメモリ。モデルサーバーは、そのマシンで最もリソースを消費するプロセスです。インターフェースが使用するメモリが 1 MB 増えるたびに、モデルが使用できるメモリが 1 MB 減ります。
- 認証。ユーザーアカウントとロールを備えたプロジェクトもあります。一方で、自分のノート PC では自分だけが使用することを前提とし、ログイン機能をまったく備えていないプロジェクトもあります。
- リモート推論。
127.0.0.1:11434にしか接続しない UI は、モデルがインターフェースと同じマシン上にあることを前提とします。モデルを別の場所に置く場合は、ローカルポートをモデルのホストへ転送するトンネルが必要です。 - 保守。SQLite ファイルを使用するコンテナ 1 つの運用と、MongoDB とベクトルデータベースを背後に配置したコンテナ 6 つの運用では、必要な作業が異なります。
モデルはインターフェース用にどれだけ RAM を残すか
サーバー上で最も大きいのはインターフェースではありません。モデルです。ダウンロードサイズは最低限の目安になります。モデルが応答している間、重みをメモリ上に保持する必要があるためです。さらに、コンテキストキャッシュを確保すると、実際のメモリ使用量はダウンロードサイズを上回ります。
このグラフのデータ
[
{
"label": "llama3.2:3b",
"download_gb": "2.0"
},
{
"label": "qwen3:4b",
"download_gb": "2.5"
},
{
"label": "gemma3:4b",
"download_gb": "3.4"
},
{
"label": "qwen3:8b",
"download_gb": "5.2"
}
]これらは、2026 年 10 月 25 日に Ollama のライブラリページに表示された数値です。実測値ではなく、公表サイズです。4 GB の VPS では、qwen3:4b のダウンロードサイズが 2.5 GB あるため、オペレーティングシステムとその他すべてに残る容量は 1.5 GB 未満です。会話が長くなるとコンテキストキャッシュもその容量を消費します。そのため、設定する num_ctx は品質だけでなく、メモリにも関わる判断になります。qwen3:8b は 5.2 GB あるため、そのサーバーにはまったく収まりません。ノート PC の比較記事が扱わないのが、この状況です。数百 MB を使用するチャットインターフェースによって、モデルを実行できるかどうかが決まります。これらのタグを大きく上回るモデル用にサーバーの容量を見積もる場合は、CPU のみの VPS で 27B モデルを実行する計算を見ると、インターフェースが判断を左右する数値ではなくなるまでの速さが分かります。
比較記事にある数値も含め、どの数値もそのまま信頼せず、実測してください。実際の運用を開始してから 1 分後ではなく 1 時間後に docker stats --no-stream を実行します。重要なメモリは、初回使用時に確保されるためです。Ollama はアイドル状態が 5 分続くと重みも解放します。そのため、会話の合間に取得した値はピーク使用量を過小評価します。また、keep_alive でモデルを常駐させる設定にしない限り、次のメッセージでモデル全体を再び読み込む必要があります。
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 ルールを無視するためです。
以下で説明する tunnel または proxy 経由でページにアクセスし、最初のアカウントを作成します。このアカウントが administrator になります。その後、管理者が New Sign Ups を再度有効にするまでサインアップは自動的に無効になります。以降のサインアップには pending ロールが付与されます。これは DEFAULT_USER_ROLE として文書化されているデフォルト値です。そのため、ページにアクセスできた第三者でも、管理者が承認するまでモデルを使用できません。
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 は大きな内部サイズにフォールバックします。その結果、各接続が独自の page cache と memory map を確保するため、小規模なサーバーでは DATABASE_POOL_SIZE=8 と DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0 を設定します。ユーザーが入力中にモデルへ completion を要求する Autocomplete は、現在は無効な状態で出荷されています（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 によるログインが文書化されており、デフォルトの compose ファイルにはユーザー、グループ、ロールを管理する管理パネルも定義されています。このパネルは、そのままでは起動しません。.env に ADMIN_PANEL_SESSION_SECRET が設定されるまで起動を拒否します。ADMIN_PANEL_SESSION_SECRET は 32 文字以上が必須で、デフォルト値はありません。使用する場合は openssl rand -hex 32 で生成してください。このパネルは LibreChat プロセス内ではなく、独立したサービスとして動作します。LibreChat v0.8.5 以降が必要で、プロジェクト上では現在もプレビュー扱いです。この機能はスタックとして提供されます。
このグラフのデータ
[
{
"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": 5,
"notes": "api, MongoDB, Meilisearch, pgvector, RAG API"
}
]デフォルトの compose ファイルは 5 個のサービスを起動します。内容は次のとおりです: api, MongoDB, Meilisearch, pgvector, RAG API。6 個目のサービスである管理パネルも同じファイルに含まれており、Secret を設定するとこれらに加わります。いずれもモデルではありません。MongoDB と pgvector はそれぞれ独自にメモリを必要とするため、4 GB のマシンではモデルが使用するはずだったメモリを消費します。
このファイルでポートを公開するサービスは 2 つあり、どちらのマッピングにも bind address が指定されていません。API は 3080、管理パネルはホスト側のポート 3000 で、これは ADMIN_PANEL_PORT のデフォルト値です。そのため、起動するとどちらもすべてのインターフェースで待ち受けます。Open WebUI も上記でポート 3000 を使用するため、共有ホストでパネルを有効にするとすぐに競合します。スタックをインターネットに公開する前に、docker-compose.override.yml で両方を 127.0.0.1 に再割り当てしてください。
アップグレードは 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 が動作しているマシンのアドレスに置き換えます。apiKey フィールドは、Ollama が値を無視するとしても必須です。そのため、プレースホルダーを指定できます。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 が使用されます。これは停止時にコンテナを削除するため、再起動後にインターフェースが戻りません。
OrionChat はさらに進んでおり、サーバーコンポーネントがありません。リポジトリを clone し、既に実行している Web サーバーでそのフォルダーを提供するか、ディスク上の index.html を開きます。API key はブラウザーの localStorage に保存され、チャット履歴もブラウザーに残ります。チャット数が 512 を超えると、古いチャットから削除されます。OrionChat の Ollama アドレスはソース内の js/script.js で http://localhost:11434 に固定されており、設定画面には変更する項目がありません。
どちらのプロジェクトにも login 機能はありません。ノート PC であれば問題ありません。VPS では、ページを 0.0.0.0 で公開してはいけないということです。さらに、見落としやすい点があります。model を呼び出すのはサーバーではなく、ブラウザーです。
この事実によって、2 つを利用できる場所が決まります。ブラウザーから Ollama に直接接続できなければなりません。OrionChat では、ブラウザーを実行しているマシン上の localhost:11434 が常に必要です。そのため、VPS では、下記の SSH tunnel が model への唯一の経路になります。Hollama は入力された任意のアドレスを接続先の base URL として使用します。また、別のデバイス上にある Ollama server も self-hosting guide で扱っています。Ollama 側の OLLAMA_ORIGINS に Hollama の origin を追加してください。したがって、SSH で port を forward しない限り、Ollama は loopback 以外でも listen する必要があります。Ollama の API には login も key も必要ありません。
ここから、ブラウザーに関する 2 つのルールが導かれます。HTTPS で提供されたページは、public IP address 上の plain HTTP endpoint を呼び出せません。また、console には 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. と表示されます。loopback には別の例外があります。Mixed Content spec は potentially trustworthy ではない URL だけを block します。Secure Contexts spec では、localhost、127.0.0.0/8、::1 を potentially trustworthy とみなします。そのため、同じ HTTPS ページから http://localhost:11434 または http://127.0.0.1:11434 を呼び出せます。この例外を、下記の SSH tunnel が利用します。
version 142 以降の Chrome では、https://chat.example.com のような public site からページを提供する場合に、もう 1 つ手順が必要です。そのページから loopback または local network address への request は、permission prompt でユーザーが local network access を許可するまで待機します。Chrome は、hostname が 192.168.0.1 のような private IP literal、.local name、または fetch が targetAddressSpace: "local" を指定する場合、local-network endpoint への permission-gated HTTP request も mixed-content check の対象外にします。tunnel 経由で http://localhost に開いたページは、既に loopback 上にあるため、この prompt は表示されません。それ以外の origin への call は、has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource とともに拒否されます。origin を許可すると接続できます。
Ollama がどちらの設定を変更する場合も、documented な方法は 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 を表示するはずです。ただし、この変更は、firewall または認証を行う proxy が既に port への接続元を制御している場合だけ実施してください。公開された 11434 は公開 model server であり、新しい public port には短時間で大量の scanner が到達します。下記の SSH tunnel を使えば、この問題全体を回避できます。その場合、ページは localhost origin 上で動作し、Ollama はそれをデフォルトで許可します。また、port がマシンの外部に出ることもありません。
各ツールはリモートの Ollama または vLLM エンドポイントを利用できますか
Open WebUI は利用できます。接続はサーバー側で確立されます。OLLAMA_BASE_URL=http://model-host:11434 で Ollama を指定します。vLLM の場合は OPENAI_API_BASE_URL=http://model-host:8000/v1 を設定し、vLLM が API を提供する /v1 はそのまま保持します。OPENAI_API_KEY は、サーバーをキー付きで起動した場合にのみ設定してください。Open WebUI の vLLM ガイドでは、通常は認証を使用しないためです。その他の OpenAI 互換サーバーでは、それぞれのドキュメントに記載されたベースパスを指定します。常に /v1 になるとは限りません。OPENAI_API_BASE_URLS には、セミコロンで区切って複数のバックエンドを指定できます。
LibreChat では、上記のカスタムエンドポイントにある baseURL から接続できます。このリクエストもサーバーから送信されるため、ブラウザーのルールは適用されません。同じベース URL と同じプレースホルダーキーはチャット画面以外でも使用できます。必要なのは、すでにホストしているモデルをコーディングエージェントに指定することだけです。
Hollama では、設定に入力した任意のエンドポイントを指定できます。Hollama 接続には編集可能なベース URL があり、デフォルトは http://localhost:11434 です。さらに Hollama には OpenAI 互換接続もあり、デフォルトは http://localhost:8080/v1 です。vLLM にはこの接続を使用します。リクエストはブラウザーから送信されないため、上記セクションの内容がすべて適用されます。OrionChat は接続先を変更できません。エンドポイントがハードコードされており、Ollama は http://localhost:11434/v1/chat/completions に固定されています。また、README には各プロバイダーの公式 API に直接リクエストを送信すると記載されています。リモートの Ollama に接続するには、SSH トンネルを使用して、そのリモート Ollama がローカルのそのポートで応答するようにする必要があります。vLLM サーバーを指定する設定はありません。
リモートエンドポイントを利用する最大の利点は、インターフェースとモデルを分離できることです。インターフェースを小規模なマシンに配置し、メモリ容量のある場所にモデルを配置します。この段階で、Ollama と vLLM のどちらでリクエストを処理するかも決めます。複数のユーザーが同時にモデルへアクセスすると、両者の動作には大きな違いがあるためです。まだモデルサーバーがない場合は、まず VPS で Ollama を実行することから始めてください。CPU のみのマシンでは、実行基盤を選ぶ前に Ollama と llama.cpp の違いを確認してください。
0.0.0.0 でログインなしのチャット UI を公開しない
Open WebUI のハードニングページには、このプロジェクトは「データベース、コンテナレジストリ、CI サーバーなど、その他の self-hosted インフラストラクチャと同様に、プライベートで信頼できるネットワーク向けに構築されている」と記載されています。また、VPN の背後、または認証機能付きのリバースプロキシの背後に配置するよう案内されています。ログイン機能がまったくないプロジェクトには、少なくとも同じ対策が必要です。
何かを信頼する前に、待ち受けているサービスを確認してください。
sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'127.0.0.1:3000 と表示される行が求める状態です。0.0.0.0:3000 と表示される行は、サービスがすべてのアドレスで待ち受けていることを示します。また、Docker はデフォルトで、外部のすべての送信元 IP から公開ポートへの到達を許可します。Docker の DOCKER-USER chain またはプロバイダーのファイアウォールでブロックされていない限り、チャットインターフェースはパブリックインターネット上に公開されています。自分のマシンから curl -sI http://YOUR.VPS.IP:3000 が HTTP/1.1 200 OK に応答すれば、より直接的に確認できます。
WEBUI_AUTH=False で Open WebUI のログインを無効にする設定は、他のユーザーが到達できないマシンで使用する単一ユーザー向けの設定です。ドキュメントによると、登録済みユーザーがいないインストールでのみ機能します。そのため、すでにアカウントがある環境には適用できません。
パターン 1: loopback に bind し、SSH 経由でアクセスする。 すべてのポートを 127.0.0.1 に公開し、必要なポートを転送します。ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com を実行し、ノート PC で http://localhost:3000 を開きます。何も公開されないため、スキャンも受けません。OrionChat では、-L 11434:127.0.0.1:11434 を使って同じコマンドでモデルポートも転送し、Ollama は loopback で待ち受けさせます。Hollama は Ollama に直接接続できますが、この転送方法なら Ollama もパブリックインターネットに公開されません。そのため、Hollama にもこの方法が安全です。このパターンの安全性は SSH の設定に依存します。鍵のみを許可する SSH と harden した sshd と組み合わせてください。
パターン 2: アプリがリクエストを受け取る前に認証するリバースプロキシを使う。 アプリは loopback で待ち受けさせ、プロキシに 443 番ポートを割り当て、前段にシングルサインオンを置きます。Docker Compose の labels で制御する Traefik と identity provider としての Authentik を組み合わせると、ホスト上のすべてのアプリで 1 つのログインと 1 つの証明書を共有できます。Open WebUI を TLS（transport layer security）の背後に置く場合は、WEBUI_SESSION_COOKIE_SECURE=true と WEBUI_SESSION_COOKIE_SAME_SITE=strict を設定します。JWT_EXPIRES_IN も、デフォルトの 4 週間より短くしてください。Open WebUI のドキュメントによると、Redis がない場合、サインアウトしても token は無効化されず、有効期限が切れるまで使用できます。
パターン 2 では、ブラウザのみで動作するプロジェクトは保護できません。ページの前段にプロキシを置いても、model endpoint は保護されません。また、そのページから別の hostname への fetch にはセッション cookie が付加されません。そのため、Ollama の前段にある認証プロキシは login form への redirect を返し、チャットは失敗します。model endpoint をページと同じ hostname 配下でルーティングするか、パターン 1 を使用してください。
どれを選ぶか
自分以外の人も利用するなら、Open WebUI を使ってください。実際のアカウントを作成でき、新規ユーザーは承認待ちキューに入り、保守担当者が公開しているハードニングのガイダンスにも従えます。LDAP や管理パネルが必要なら LibreChat を使い、パネルが必要な場合は ADMIN_PANEL_SESSION_SECRET を設定してください。そのうえで docker stats を実行し、5 つのサービス（パネルを含めると 6 つ）とモデルを合わせて、必要なリソースに収まることを確認してから依存してください。モデルがすでに RAM の大半を確保している小規模なマシンで 1 人だけが使うなら、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 互換サーバーを使用する場合は、そのサーバーがドキュメントで示しているベースパスを OPENAI_API_BASE_URL に指定します。vLLM のベースパスは /v1 です。API key は、サーバーが要求する場合にだけ追加してください。Hollama も任意の接続先を指定できますが、リクエストはブラウザーから送信されるため、エンドポイントもブラウザーから到達可能である必要があります。OrionChat は使用できません。Ollama のアドレスが http://localhost:11434 にハードコードされているためです。リモートの Ollama を使用できるのは、SSH tunnel でそのポートを転送した場合だけです。
ブラウザーのチャット UI から Ollama に接続できないのはなぜですか？
ほぼすべてのケースは、2 つの原因に当てはまります。Ollama はデフォルトで 127.0.0.1:11434 に bind するため、別のマシン上のブラウザーから直接接続できません。OLLAMA_HOST を変更するか、SSH tunnel でポートを転送する必要があります。また、Ollama はデフォルトで localhost、127.0.0.1、0.0.0.0 からの cross-origin request を受け付けます。そのため、自分のドメインから配信されたページは、OLLAMA_ORIGINS にその origin を登録するまで No 'Access-Control-Allow-Origin' header is present on the requested resource で拒否されます。ページが HTTPS で、エンドポイントがパブリック IP アドレス上の通常の HTTP の場合、Ollama がリクエストを受け取る前に、ブラウザーが mixed content として通信をブロックします。loopback address（localhost、127.0.0.0/8 内の任意のアドレス（127.0.0.2 など）、または [::1]）は対象外です。Chrome では、local-network permission を許可した後、192.168.0.1 のような private IP literal、.local hostname、または targetAddressSpace: "local" を使用する local-network HTTP request も対象外になります。ただし、Ollama の CORS 要件は引き続き適用されます。systemctl edit ollama.service override で両方の変数を設定してください。または SSH でポートを転送すれば、この問題は解消します。