SSD Nodes Learn メモリ 8GB — 年額 $66
ガイド Matt Connor著者 Matt Connor ・更新日 2026-08-01

AuthentikをDocker Composeで構築する方法

AuthentikをDocker Composeで構築し、1回のログインで各アプリにアクセスする方法を解説します。必要な環境変数、akadminの初期設定、Traefikのforward auth設定を確認できます。

ホストするすべてのアプリに1回のログインでアクセス

Authentikはセルフホスト型のSSO（シングルサインオン）サーバーです。ユーザーは1回サインインするだけで、Authentikの背後にあるすべてのアプリがそれぞれのパスワードを要求せず、そのセッションを受け入れます。インストールには、公式のDocker Composeファイルと、生成した2つのシークレットを使用します。本当に検討が必要なのはその後です。リバースプロキシをAuthentikに向け、既存のアプリ1つをforward authの背後に配置します。

Authentikは、そのComposeファイルで3つのサービスとして動作します。PostgreSQLデータベース、serverプロセス、workerプロセスです。サーバーコンテナは組み込みoutpostも実行します。これは、保護された各アプリに対して「このリクエストはサインイン済みか」を確認するコンポーネントです。2026年7月時点の現行リリースは2026.5です。プロジェクトでは、少なくとも2 CPUコアと2 GBのRAMを備えたホストを求めています。これを最低要件と考えてください。ホストを1日稼働させると、PostgreSQLとworkerの両方がメモリを使用します。

開始前に必要なもの

docker compose version で確認できる、Compose v2 plugin を備えた Docker Engine が必要です。バージョンではなくエラーが表示される場合は、先に plugin をインストールしてください。基本的な手順は、VPS で Docker Compose を使用してアプリケーションを実行する で説明しています。また、サーバーを指す DNS A レコードも必要です。以下の例では auth.example.com が該当します。Authentik は、ブラウザーが使用したホスト名からリダイレクト URL を生成するためです。

スタックは root ではなく、docker グループに所属する一般ユーザーとして実行してください。このグループの所属権限はホスト上の root 権限と同等です。そのため、VPS で最小権限のユーザーアカウントを使用する の方針に従い、1つのデプロイ用アカウントだけに付与し、他のユーザーには付与しないでください。

公式のComposeファイルでインストールする

sudo install -d -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
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 -d

docker compose ps には3つのコンテナが表示されます。postgresql は healthy と server を報告し、worker は running を報告します。初回起動ではデータベースのマイグレーションが実行されるため、Webインターフェースが応答するまで1分ほど待ってください。

生成された2つの値は、それぞれ異なる理由で重要です。PG_PASS はPostgreSQLのパスワードで、長さは99文字までに制限されています。AUTHENTIK_SECRET_KEY はセッションとトークンの署名に使用されるため、後から変更するとすべてのユーザーがログアウトされ、発行済みのすべてのAPIトークンが無効になります。.env のモードは600のままにし、安全な場所にコピーを保管してください。一致する秘密鍵なしで復元されたデータベースには、誰もログインできません。

Composeファイルは ${PG_PASS:?database password required} 形式で両方の値を読み取ります。そのため、ファイルがない場合、Composeは起動を拒否します。間違ったディレクトリで docker compose up -d を実行すると、required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required と表示されて停止します。このメッセージはパスの問題を示しており、設定の問題ではありません。

重要な環境変数

その他の設定はすべて同じ .env ファイルに記述します。Authentik は二重アンダースコアをネストした設定キーに変換するため、AUTHENTIK_EMAIL__HOST は email.host を設定します。単一のアンダースコアは警告なしで無視されます。設定が反映されない最も一般的な原因はこれです。

  • AUTHENTIK_BOOTSTRAP_PASSWORD は初回起動時に組み込みの akadmin ユーザーのパスワードを設定します。そのため、公開 Web フォームにパスワードを入力する必要はありません。AUTHENTIK_BOOTSTRAP_EMAIL と AUTHENTIK_BOOTSTRAP_TOKEN も同様に、そのユーザーのアドレスと API トークンを設定します。
  • COMPOSE_PORT_HTTP と COMPOSE_PORT_HTTPS は、公開ポートをデフォルトの 9000 と 9443 から変更します。
  • AUTHENTIK_EMAIL__HOST、AUTHENTIK_EMAIL__PORT、AUTHENTIK_EMAIL__USERNAME、AUTHENTIK_EMAIL__PASSWORD、AUTHENTIK_EMAIL__USE_TLS、AUTHENTIK_EMAIL__FROM は送信メールを設定します。これらを設定しない場合、Authentik はポート 25 で localhost への接続を試みます。そのため、パスワードリセットメールは worker ログで接続エラーになります。
  • AUTHENTIK_LOG_LEVEL=debug は、ログインフローに問題があるときに必要な詳細情報を有効にします。問題を解決したら info に戻します。
  • AUTHENTIK_ERROR_REPORTING__ENABLED のデフォルト値は false です。クラッシュレポートを upstream に送信しても問題ない場合に限り、true に設定します。

これらは平文ファイル内のシークレットです。他の認証情報ストアと同じように、このディレクトリを管理してください。リカバリ用コピーの保存先には、ノート PC 上のメモよりも、self-hosted Vaultwarden インスタンスなどのパスワードマネージャーが適しています。

初回ログインと管理者アカウント

ブラウザーで http://SERVER_IP:9000 を開きます。Authentik に初期セットアップ画面が表示され、デフォルトの akadmin ユーザーにパスワードを設定するよう求められます。すでに AUTHENTIK_BOOTSTRAP_PASSWORD を設定している場合、この手順は完了しているため、ログインページに直接移動します。

Directory、次に Users の順に開き、自分用の通常の管理者ユーザーを作成します。そのユーザーを authentik Admins グループに追加し、そのアカウントでサインインします。akadmin は緊急用アカウントとして残し、長いパスワードをオフラインで保管します。共有の組み込みアカウントで日常の作業を行うと、監査ログが機能しなくなります。すべてのイベントに akadmin と記録され、実際に誰が操作したのか分からなくなるためです。

リバースプロキシの背後に Authentik を配置する

ポート 9000 をインターネットに公開しても動作しますが、TLS（トランスポート層セキュリティ）と正式なホスト名を使用したい場合があります。すでに 複数の Compose アプリケーション用の Traefik リバースプロキシ の構成を実行している場合は、override ファイルを使用して Authentik を同じ外部 proxy ネットワークに接続します。compose.yml の横に docker-compose.override.yml を作成します。

services:
  server:
    networks:
      - default
      - proxy
    labels:
      traefik.enable: "true"
      traefik.docker.network: proxy
      traefik.http.routers.authentik.rule: Host(`auth.example.com`)
      traefik.http.routers.authentik.entrypoints: websecure
      traefik.http.routers.authentik.tls.certresolver: le
      traefik.http.services.authentik.loadbalancer.server.port: "9000"

networks:
  proxy:
    external: true

docker compose up -d で適用します。Compose は override を自動的にマージするため、server サービスは公式ファイルの設定をすべて保持し、ラベルが追加されます。curl -I https://auth.example.com/if/user/ で確認します。HTTP/2 200 が返るはずです。Traefik から 404 page not found が返る場合、コンテナが proxy ネットワークに接続されていません。Traefik は到達できないコンテナにトラフィックをルーティングできません。

ホスト名が機能したら、override で公開ポートを 127.0.0.1 にバインドします。これにより、プロキシ経由だけが接続経路になります。

1つのアプリを forward auth で保護する

Authentik の proxy provider には3つのモードがあり、誤ったモードを選ぶと1時間を失うことがあります。Proxy は outpost 自体が upstream app にトラフィックを転送します。Forward auth (single application) は、独自の reverse proxy がトラフィックを転送し、リクエストがサインイン済みかどうかだけを Authentik に確認します。Forward auth (domain level) は、1つの親ドメイン配下にあるすべてのアプリを1つの provider で保護しますが、アプリケーション単位の認可ルールは設定できません。前段に Traefik を使用する場合は、forward auth (single application) を選択します。

Web インターフェースで Applications、次に Providers を開き、Proxy Provider を作成します。forward auth single application モードを選択し、external host に https://app.example.com を設定します。その provider を参照する Application を作成します。次に Outposts を開き、authentik Embedded Outpost を編集して、新しいアプリケーションを selected applications に追加します。outpost は割り当てられたアプリケーションに対してのみ応答します。この最後の手順を省略すると、provider を正しく設定しても応答が返らなくなります。

Authentik コンテナ上で middleware を1回だけ定義し、保護するすべてのアプリから参照します。

      traefik.http.middlewares.authentik.forwardauth.address: http://server:9000/outpost.goauthentik.io/auth/traefik
      traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: "true"
      traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-version

authResponseHeaders は、Authentik の応答から Traefik が upstream に送信するリクエストへコピーするヘッダーの一覧です。これを省略してもアプリ自体は保護されますが、アプリはユーザー情報を取得できません。そのため、automatic login に X-authentik-username を使用する機能はログアウト状態のままになります。

保護するアプリ自体には、1つではなく2つの router が必要です。

    labels:
      traefik.enable: "true"
      traefik.http.routers.myapp.rule: Host(`app.example.com`)
      traefik.http.routers.myapp.entrypoints: websecure
      traefik.http.routers.myapp.tls.certresolver: le
      traefik.http.routers.myapp.middlewares: authentik@docker
      traefik.http.routers.myapp-auth.rule: Host(`app.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)
      traefik.http.routers.myapp-auth.entrypoints: websecure
      traefik.http.routers.myapp-auth.tls.certresolver: le
      traefik.http.routers.myapp-auth.priority: "15"
      traefik.http.routers.myapp-auth.service: authentik

2つ目の router は、誰もが省略しがちな部分です。サインイン後、Authentik はブラウザーを auth.example.com ではなく、アプリの hostname 上にある /outpost.goauthentik.io/ 配下のパスへ戻します。そのパス prefix を Authentik service に転送する router がないと、リクエストはアプリに到達します。アプリは 404 を返すため、ログインは完了しません。同じドメイン上にある通常の Host() ルールよりも具体的なパスルールを優先するには、priority を高く設定します。

プライベートブラウザーウィンドウでテストします。auth.example.com にリダイレクトされ、サインイン後にアプリへ戻ることを確認します。Authentik 側の docker compose logs -f server には試行ごとに認可イベントが出力されます。これにより、リクエストが Authentik まで到達したかどうかを確認できます。

実際に発生する障害

アプリケーションとログインページの間でリダイレクトが無限に繰り返されます。 プロバイダー上の外部ホストが、ブラウザーで使用しているホストと一致していません。通常、プロバイダー側の http:// とアドレスバーの https:// が異なります。そのため、セッションCookieが別のオリジンに設定され、戻るたびに新しい匿名リクエストとして扱われます。再テストする前に外部ホストを修正し、両方のドメインのCookieを削除してください。

/outpost.goauthentik.io/start で404が発生します。 outpost router が存在しないか、その優先度が対象ホストの catch-all router より低くなっています。

ログインを要求されないままアプリケーションが読み込まれます。 middlewares ラベルが、存在しない middleware を指定しています。Traefik はこの状態を警告しないため、authentik@docker のタイプミスがあると middleware は実行されません。Traefik dashboard を開き、router に middleware が一覧表示されていることを確認してください。

ログインに成功した後、Authentik から403が返されます。 ユーザーは認証されていますが、認可されていません。アプリケーションに、このユーザーが満たしていない policy binding または group 要件が設定されています。管理インターフェースの Events log に、アクセスを拒否した policy が表示されます。

Keycloakがより適している場合

KeycloakはRed Hatが支援する歴史の長いプロジェクトです。従来型のエンタープライズID管理では、Keycloakのほうが適しています。特に、SAMLフェデレーション、複数の外部IDプロバイダーからのログインを同時に仲介する構成、文書化された移行手段としてのrealmのエクスポートとインポートに強みがあります。商用サポートの存在を、組織によっては評価します。

一方、Keycloakには独自のプロキシがありません。そのため、OIDC (OpenID Connect) に対応していないアプリケーションを保護するには、oauth2-proxyなどをKeycloakと併用する必要があります。Authentikには、この機能に相当する組み込みのプロキシプロバイダーがあり、すでに統合されています。そのため、さまざまなアプリケーションを混在させているセルフホスト環境では、Authentikが選ばれることが多くなります。

バックアップとアップグレード

復元には、PostgreSQLデータベース、./dataディレクトリ、.envの3つが必要です。

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gz

このダンプと.envを一緒に保存します。ダンプだけでは不十分です。セッションとトークンのデータを保護する秘密鍵が.envに保存されているためです。

アップグレードはタグの変更です。.envでAUTHENTIK_TAGを使用するリリースに設定し、docker compose pullを実行してからdocker compose up -dを実行します。Authentikは日付ベースのバージョンを使用しており、一部のリリースには直前のバージョンからの更新を前提とするマイグレーションが含まれているため、先にリリースノートを確認してください。データベースのダンプはpullの後ではなく、前に取得します。

FAQ

Authentikのセルフホストは無料ですか？

オープンソース版は無料で、上記のすべてに対応します。プロキシプロバイダー、forward auth、OIDC（OpenID Connect）、SAML、flows engineを利用できます。有料のエンタープライズ層では、サポートと一部のエンタープライズ機能が追加されます。ただし、ここで説明した構成にライセンスは必要ありません。

Authentikの使用にTraefikは必要ですか？

いいえ。forward authは、auth_requestを使用してnginxで利用できます。また、forward_authを使用すればCaddyでも利用できます。どの場合もパターンは同じです。リバースプロキシが各リクエストについてAuth​​entikに確認し、保護対象ホスト名のパスプレフィックス/outpost.goauthentik.io/をアプリではなくAuthentikにルーティングします。

保護したアプリがログインとエラーを延々と繰り返すのはなぜですか？

プロキシプロバイダーに設定した外部ホストが、ブラウザーで使用しているURLと一致していません。最も多いのは、httpとhttpsの不一致です。セッションCookieが一方のオリジン向けに発行され、別のオリジンで読み取られるため、Authentikは毎回匿名リクエストとして処理します。外部ホストを修正し、再テストする前に両方のホスト名のCookieを削除してください。

Authentikにはどの程度のRAMが必要ですか？

2026年7月時点の公式な最小要件は、CPU 2コアとRAM 2 GBです。これはPostgreSQL、server、workerを合わせた要件です。RAM 2 GBのサーバーでは、メモリープレッシャーが発生すると最初にworkerがカーネルによって終了されます。その結果、ログインページは動作していても、バックグラウンドタスクと送信メールが停止します。同じサーバーで保護対象のアプリも実行する場合は、RAM 4 GBを割り当ててください。

#authentik#sso#authentication#self-hosting#docker-compose#traefik