著者 Matt Connor
小規模VPSのSSO比較：Keycloak、authentik、Zitadel
Keycloak、authentik、Zitadelを1台の小規模VPSで比較します。必要なRAMの下限、SSO非対応アプリを保護できる製品、各製品の弱点を確認できます。
1 台の VPS に適した SSO サーバーはどれか
Keycloak、authentik、Zitadel は、サーバー上のすべてのアプリで 1 つのログインを使いたい場合に候補となる、自己ホスト型のシングルサインオン（SSO）サーバーです。1 台の小規模な VPS では、これらを同じものとして扱うことはできません。自己ホスト型アプリを 3 つまたは 4 つ運用するサーバーでは、authentik が無難な既定の選択です。3 つの中で唯一、独自のログイン機能を持たないアプリの前段にログイン画面を配置できるためです。保護するすべてのアプリが標準プロトコルに対応しており、Java 仮想マシン（JVM）用のメモリを確保できる場合は、Keycloak が適しています。Zitadel は API 経由で製品を提供する開発者向けに設計されており、4 GB 未満の環境では導入しません。
最初に選択してから、インストールしてください。選択したら、VPS への authentik の実践的なインストールでセットアップの手順を確認できます。
各プロジェクトに実際に必要な RAM はどの程度ですか？
まず、リソースの下限から確認します。機能を比較する前に、候補を絞り込めるためです。以下の数値は、各プロジェクトが公開している情報を 2026 年 8 月に確認したものです。ベンダーの指針であり、負荷テストの結果ではありません。
The data behind this chart
[
{
"label": "authentik",
"vendor_min_ram_mb": 2048,
"base_containers": 3
},
{
"label": "Keycloak",
"vendor_min_ram_mb": 1250,
"base_containers": 2
},
{
"label": "Zitadel",
"vendor_min_ram_mb": 2048,
"base_containers": 4
}
]authentik の Docker Compose インストールページでは、「2 CPU コア以上と 2 GB の RAM を備えたホスト」を求めています。これは 2048 MB です。また、公開されている compose ファイルでは、PostgreSQL、server、worker の 3 コンテナが起動します。
Keycloak は、3 件の中で最も具体的な数値を公開しています。サイジングガイドには、「Realm データのキャッシュと 10,000 件のキャッシュ済みセッションを含む Pod の基本メモリ使用量は 1250 MB の RAM」と記載されています。この 1250 MB は Java プロセスだけに必要な量であり、データベース分は含みません。同じページでは、コンテナのメモリ制限が重要な理由も説明しています。Keycloak はメモリ制限の 70% をヒープとして使用し、その上で約 300 MB の非ヒープメモリを必要とします。コンテナに 1 GB を割り当てると、ヒープは約 717 MB になりますが、さらに 300 MB の非ヒープメモリが必要です。そのため、セッションデータがキャッシュに入る前に、すでに制限を使い切ります。
Zitadel の compose ページも 2 GB、つまり同じ 2048 MB を求めています。ただし、これは初回起動時の数値です。確認すべきなのは本番環境向けのページです。Zitadel プロセス自体は「約 512MB の RAM を必要とし、CPU 1 コア未満で動作できます」。負荷が大きいのはデータベースです。「100 requests per second (req/s) あたり約 1 CPU コア、1 コアあたり 4GB の RAM」が必要です。パスワードハッシュ処理には「この用途のために 4 CPU コアを利用可能にする」必要もあります。ログインが集中すると、CPU 使用率が急上昇するためです。公式の v4 compose では、追加設定なしで Traefik をプロキシ、Zitadel API、独立した Login UI コンテナ、PostgreSQL といった 4 コンテナが起動します。Redis と OpenTelemetry collector は、任意の compose profile の背後に配置されています。
したがって、Keycloak と authentik は、保護対象のアプリケーション用に余裕を残しながら 4 GB の VPS で運用できます。Zitadel は 2 GB でも起動しますが、ログインのたびに自身の PostgreSQL とメモリを奪い合います。Zitadel は 4 GB 未満では運用しないことを推奨します。アプリケーションも同じサーバーでホストするなら、8 GB を確保したいところです。
実際にサーバー上で実行される内容
authentik は、PostgreSQL と、同じイメージから作成される server と worker の 2 つのコンテナで構成されます。server は HTTP リクエストに応答し、組み込みの outpost を保持します。worker は、ディレクトリ同期やメール送信などのバックグラウンドタスクを実行します。公開されているインストール手順は短いものです。
wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -dserver はポート 9000 と 9443 を公開します。ポート 9000 に初めてアクセスすると初期セットアップフローが開始され、デフォルトの akadmin ユーザーのパスワードを設定します。このポートがインターネットから到達可能になる前に、正式な証明書を使用するリバースプロキシを前段に配置してください。
Keycloak は、1 つのプロセスと、別途用意するデータベースで構成されます。クイックスタートでは、1 つのコンテナだけを使用します。
docker run -p 127.0.0.1:8080:8080 \
-e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
-e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
quay.io/keycloak/keycloak:26.7.1 start-devstart-dev は動作を確認するためのものです。ローカルの開発用データベースを使用し、TLS（transport layer security）も設定されません。そのため、この方法で起動したコンテナを後で削除すると、realm も失われます。本番環境では、代わりに start を使用し、KC_DB を介して実際の PostgreSQL に接続し、KC_HOSTNAME を介して公開ホスト名を設定します。Keycloak の本番環境向けガイドにも、サーバーとのすべての通信にセキュアなチャネルが必要と記載されています。したがって、ここでは HTTPS は必須です。
Zitadel は、前述した 4 コンテナ構成のスタックです。
mkdir zitadel-compose && cd zitadel-compose
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example
cp .env.example .env
docker compose up -d --wait初回起動前に .env で ZITADEL_MASTERKEY を設定してください。これは、Zitadel がデータベース内の Secret を暗号化するために使用する 32 文字のキーです。このキーを失うと、該当する Secret にアクセスできなくなります。これらのようなスタックの運用に慣れていない場合は、VPS 向け Docker Compose の基本で、アイデンティティプロバイダーが再起動後も維持されるかどうかを左右するボリュームと restart policy の選択について確認できます。
各製品が対応するプロトコルは何ですか？
3 製品とも、現在のアプリケーションが使用する OAuth 2.0 上のログイン層である OpenID Connect (OIDC) に対応しています。また、エンタープライズソフトウェアで現在も使われている旧来の標準、SAML 2.0 (security assertion markup language) にも対応しています。大きな違いは LDAP (lightweight directory access protocol) です。LDAP では、正反対の 2 つの役割を同じ言葉で表します。
LDAP から読み取るとは、SSO サーバーが、すでに運用しているディレクトリに対してパスワードを照合することです。Keycloak では、ユーザーフェデレーションを通じてこれを実行します。Zitadel も対応しており、ドキュメントでは「ZITADEL のアイデンティティプロバイダーとして LDAP サーバーに接続する」方法を説明しています。
LDAP を提供するとは、LDAP 以外のプロトコルを話さないアプリケーションが、ディレクトリに接続する場合と同じように SSO サーバーへ bind できることです。これに対応するのは authentik だけです。authentik の LDAP プロバイダーは、専用の LDAP outpost を通じて「authentik のデータベース内にあるすべてのユーザーとグループを LDAP ディレクトリから検索可能」にします。LDAPS は port 636 で利用できます。読み取り専用のため、bind と検索は機能しますが、書き込みはできません。ワンタイムコードは、password;123456 のようにセミコロンでパスワードに追加します。bind 中の SMS 認証器には対応していません。
一覧に LDAP だけを話すアプリケーションが 1 つでもある場合、比較はそこで終わります。Keycloak と Zitadel はその bind に応答できないため、これらとは別に 2 つ目のディレクトリを運用し、2 つのユーザー一覧を同期する必要があります。
ログイン機能がまったくないアプリはどうしますか？
その場合は Forward auth を使用します。これは、セルフホスト環境で頻繁に発生するケースです。リバースプロキシは、リクエストを upstream に転送する前に、SSO サーバーへそのリクエストが許可されているか確認します。背後のアプリは SSO の存在を認識しません。アプリが受け取るのは、通常はユーザー名をヘッダーに含む、プロキシによる確認済みのリクエストです。
authentik の proxy provider には、これに対応する 3 つのドキュメント化されたモードがあります。"Proxy" では、authentik outpost がトラフィックを upstream のアプリへ直接転送します。"Forward auth (single application)" では、トラフィックを既存のリバースプロキシに処理させ、認証確認だけに authentik を使用します。"Forward auth (domain level)" では、1 つの親ドメイン配下にあるすべてのアプリを、1 つの provider で保護します。Domain level は便利ですが、ドキュメントに記載された制限があります。保護対象の各アプリに異なるアプリケーションレベルの認可ルールを適用できないため、そのドメイン配下のすべてのアプリで同じポリシーセットを共有します。
Keycloak には、この機能がありません。付属のプロキシである Keycloak Gatekeeper は Louketo Proxy に改称された後、GitHub でアーカイブされました。最後のコミットは 2023 年 8 月です。OIDC に対応していないアプリを保護するには、通常は oauth2-proxy などの別コンポーネントをアプリの前段で実行し、Keycloak の client を指定します。Zitadel にも独自の Forward auth モードはありません。そのため、別のコンポーネントをインストールし、監視し、アップグレードする必要があります。
この追加のホップによって、リバースプロキシの設定は単純ではなくなります。認証 middleware を組み込む前に、Traefik で複数の Docker Compose アプリを前段で処理する方法を確認してください。
アップグレード経路はどれほど厳しいですか？
2026 年 8 月時点の最新リリースは、Keycloak 26.7.1、authentik 2026.5.6、Zitadel v4.16.3 です。3 つとも PostgreSQL に対してスキーママイグレーションを実行するため、アップグレードのたびにデータベースが変更されます。毎回、最初にデータベースをバックアップしてください。この習慣 1 つが、この比較に含まれるどの機能よりも重要です。
authentik は最も厳格なルールを採用しており、明確に説明しています。「アップグレードはメジャーリリースの順序に従う必要があります。古いメジャーバージョンから最新バージョンへ直接移行しないでください。」次のバージョンへ進む前に、各バージョン系列内の最新パッチへ更新します。また、「authentik はダウングレードをサポートしていません」。カレンダーバージョン方式のプロジェクトで 1 年遅れると、1 回のアップグレードが複数回の連続した作業になります。それぞれでデータベースマイグレーションが必要です。
Keycloak のアップグレードガイドには、従うべき順序が示されています。まず前のバージョンからのマイグレーション変更を確認し、次にサーバーをアップグレードし、その後でアダプターをアップグレードします。データベースマイグレーションは自動的に実行できます。または、変更をエクスポートして手動で適用することもできます。変更が適用される前に内容を確認したい場合に便利です。Keycloak のコストは、この確認作業にあります。リリースノートには非推奨化と動作変更が記載されています。これらは見落としやすく、見落とした場合の影響も大きくなります。
Zitadel では、init フェーズと setup フェーズを実行中のサーバーから分離します。本番環境向けのガイダンスでも、スケーリング時に setup 処理が繰り返されないよう、これらを分離することを推奨しています。単一の VPS では、主に API が正常と報告する前に setup 処理を完了させる必要があるという意味です。そのため、compose ファイルにはヘルスチェックが含まれ、start コマンドでは --wait を使用します。
各プロジェクトの対象と、適さないケース
Keycloak は Red Hat のアイデンティティサーバーです。realm、グループ、ロールマッピング、既存の企業ディレクトリを持つ組織向けに設計されています。3 つの中で、標準仕様への対応が最も包括的です。一方、2 GB の VPS で 4 つのセルフホストアプリを運用し、その半数が OIDC に対応していない環境には適しません。JVM に 1250 MB を割り当て、企業向けに設計された realm モデルを学ぶ必要があります。それでも、実際に必要なアプリには oauth2-proxy を別途導入することになります。
authentik はセルフホストを利用するユーザー向けに設計されており、機能一覧にもその方針が表れています。forward auth と LDAP provider が組み込まれており、ビジュアルエディターでログインフローを構築できます。一方、ベンダーのサポート契約や、数週間ごとには更新されないリリースサイクルが必要な場合には適しません。カレンダーバージョニングでダウングレード手段がなく、バージョンを飛ばして更新することもできないため、運用上の作業が発生します。実際の課題が 1 つの OIDC client である場合、フローエディター全体のモデルを学ぶ必要がある点も負担になります。
Zitadel は、提供する製品に認証機能を組み込む開発者向けに設計されています。強力な API と、第一級の機能として扱われるマルチテナンシーを備えています。一方、このケースには適しません。4 つのコンテナが必要で、forward auth に対応しておらず、データベースにはコアあたり 4 GB が必要です。これは、パスワードマネージャーと wiki を背後で運用する 1 台の VPS には適さない構成です。
1 台の VPS で実行する構成と方法
1 台の VPS で自己ホスト型アプリを 3 つまたは 4 つ運用するなら、authentik を使用します。3 つともログイン画面を提供します。判断の決め手は、一部のアプリが OIDC に対応できないことです。authentik なら、別のコンポーネントを追加せず、組み込みの forward auth でこの問題に対応できます。
可能であれば 4 GB を割り当て、隣接するアプリが小規模な場合に限り 2 GB にします。ポート 9000 はパブリックインターネットからアクセスできないようにし、前段のリバースプロキシで TLS を終端します。PostgreSQL のダンプを毎晩取得し、サーバー外に保存します。バックアップのない ID プロバイダーは、その背後にあるすべてのアプリにとって単一障害点になるためです。スタックは root ではなく、専用の非特権アカウントで実行します。VPS で最小権限ユーザーを設定するでは、この構成に必要なアカウントとファイル所有権について説明しています。
保護するすべてのアプリがすでに OIDC または SAML に対応している場合、または Keycloak realm が提供する細粒度のロールモデルが必要な場合は、Keycloak を選択します。他のユーザーがサインアップするアプリを構築しており、API とテナントモデルを利用したい場合は、Zitadel を選択します。どちらも、この記事で扱う 1 台のサーバーに 3 つのアプリを配置するケースには適していません。
最初に遭遇する障害パターン
Keycloak の再起動後にデータがない。 start-dev で起動しています。これはローカルの開発用データベースを使用します。ボリュームを割り当てていないコンテナでは、コンテナを削除すると realm も削除されます。実際のデータベースを KC_DB=postgres で指定し、start に移行してください。
小規模なホストで authentik の worker コンテナが消える。 worker と server は同じイメージを使用し、どちらも Python プロセスを保持します。さらに PostgreSQL も 2 GB のホストメモリを使用します。docker compose ps を実行して、どのサービスが終了したかを確認してください。その後、dmesg で out-of-memory による kill を確認してから、アプリのバグを調べてください。
プロキシの背後で Zitadel の Console が動作しない。 Zitadel API は gRPC を使用するため、upstream まで HTTP/2 が必要です。要件ページでは、upstream 接続で HTTP/2 をサポートするリバースプロキシを求めており、検証済みの Traefik v3.x、NGINX v1.x、Caddy v2.x、Apache httpd 2.4.x のバージョンを示しています。upstream 接続を HTTP/1.1 にダウングレードするプロキシでは、ログインページは読み込めても Console は動作しません。
すべてのアプリでログイン画面に戻される。 SSO サーバーの公開 URL と、アプリに設定した URL は、スキームとポートを含めて完全に一致させる必要があります。Keycloak ではこれを hostname 設定と呼び、Zitadel では external domain と呼びます。一致しない場合、アプリはサーバーが自身の URL と認識しないログイン URL へリダイレクトします。その結果、ブラウザーが2つの URL の間を繰り返し移動します。
FAQ
2 GB の VPS にはどれが適していますか？
authentik と Keycloak です。authentik の要件では、少なくとも 2 CPU コアと 2 GB の RAM を備えたホストが必要です。Keycloak のサイジングガイドでは、データベースを除くサーバーの基本メモリとして 1250 MB が示されています。保護対象のアプリを追加すると、どちらも 2 GB では余裕がありません。そのため、余裕を持って運用できる下限は 4 GB と考えてください。Zitadel は初回実行に 2 GB を示していますが、本番環境のガイダンスでは、パスワードハッシュ処理に 4 CPU コア、データベースコアあたり 4 GB の RAM を求めています。したがって、2 GB では実運用できません。
独自のログイン機能を持たないアプリを Keycloak または Zitadel で保護できますか？
単独ではできません。どちらにも forward auth コンポーネントは付属していません。Keycloak の旧 companion proxy である Louketo Proxy は GitHub でアーカイブされており、最後のコミットは August 2023 です。そのため、これを基盤にするべきではありません。リバースプロキシとアプリの間に oauth2-proxy などのコンポーネントを配置し、SSO サーバー上の OIDC クライアントを指定します。authentik では、proxy provider を "Forward auth (single application)" または "Forward auth (domain level)" モードで使用して、これをネイティブに実行できます。
LDAP だけを話すアプリ向けに LDAP サーバーとして動作できるのはどれですか？
authentik です。LDAP provider は outpost 上で動作し、authentik のユーザーとグループを LDAP 経由で検索できるようにします。LDAPS は port 636 で利用できます。読み取り専用のため、bind と search は機能しますが、書き込みは機能しません。Keycloak と Zitadel は逆方向に動作します。どちらも既存の LDAP ディレクトリをユーザーソースとして読み取りますが、アプリケーションからの LDAP bind に応答することはできません。
authentik のアップグレードでバージョンをスキップできますか？
いいえ。ドキュメントでは、アップグレードは major release の順序に従う必要があり、古い major version から最新バージョンへ直接スキップしてはならないと説明されています。まず各バージョン系列内の最新 patch release へ更新し、その後 1 バージョンずつ進めてください。authentik はダウングレードをサポートしておらず、migration は前方向にのみ実行されるため、各手順の前に PostgreSQL をバックアップしてください。