用海外云服务器自建 authentik 统一身份认证中心完整教程：SSO 单点登录、OIDC 与两步验证实战（2026最新版）

Meta Description: 2026 最新 authentik 自建教程：在海外云服务器用 Docker Compose 部署统一身份认证中心（IdP），配 PostgreSQL、Nginx HTTPS、OAuth2/OIDC 接入应用、LDAP 与代理提供方、两步验证 2FA，附配置价格对比表与 10 条常见问答。

关键词：authentik 搭建、自建 SSO、单点登录服务器、统一身份认证、身份提供方 IdP、authentik Docker 部署、OIDC 配置教程、OAuth2 单点登录、LDAP 统一认证、两步验证 2FA、海外云服务器

前言

当你在自己的服务器上装了十几个自建服务——Grafana、Nextcloud、Jellyfin、Portainer、Wiki.js、Vikunja、Harbor——你最头疼的往往不是「装不上」，而是「每人一套账号」。新同事入职，你要在七八个后台里各建一次用户；有人离职，你要挨个去删；谁改了密码、谁开了两步验证，全靠一张 Excel 表记着。authentik 就是来解决这件事的：它是一个开源的统一身份认证中心（Identity Provider，简称 IdP），让你的所有自建服务把「登录」这件事外包给它——用户只需要在一个地方登录一次，就能通行全部应用，这就是 SSO（单点登录）。

authentik 用 Python/Django 写成，核心以 MIT 许可证开源（仓库里的 ee/ 目录是商业版功能，其余全部开源），官方提供现成的 Docker Compose 部署方式，定位是「测试环境与小规模生产环境」。它一个镜像里同时跑 server（Web 与 API）和 worker（后台任务）两个角色，配一个 PostgreSQL，不需要 Redis，官方给出的最低要求是 2 核 CPU / 2 GB 内存。当前最新稳定版为 2026.8.4（2026-10-14 发布）。

这篇文章给出一份可直接复制执行的完整教程：从服务器选型、Docker Compose 部署、Nginx 反向代理与 HTTPS、管理员初始化，一路讲到用 OIDC 把 Grafana 接进来、用 LDAP 与代理提供方（forward auth）把「不认 OIDC」的老应用也纳管、开启两步验证、权限绑定与访问控制、安全加固、备份升级与故障排查，最后附一份配置价格对比表和 10 条常见问题。

动手之前，请记住官方反复强调的三条最容易踩的坑：① 绝不要在容器里挂载 /etc/timezone 或 /etc/localtime——authentik 内部一律用 UTC，挂了会让 OAuth 和 SAML 认证出错；② 初始化向导的地址必须以斜杠结尾（/if/flow/initial-setup/），少一个斜杠就是 404；③ 镜像 tag 不要再用 latest（官方已冻结），务必固定版本号。 另外，也不要把它和「密码管理器」混为一谈——这两者是完全不同的东西（下文会专门切开）。

🚀 需要一台海外云服务器来跑 authentik？通过 5.chengzicloud.cloud 购买阿里云国际版 / 腾讯云国际版 / AWS，享专属折扣。

一、先搞清楚：authentik 解决什么问题（与站内方案的分工）

authentik 的定位是「你是谁、你能进哪些门」——它不存你的业务数据，也不改变你的网络结构。它维护的是用户目录、组与角色、登录流程（Flow）、以及每个应用的「信任凭据」（OIDC 的 Client ID / Secret、SAML 的证书、LDAP 的绑定账号）。当用户访问受保护的应用时，应用把用户「踢」到 authentik 登录，authentik 验明身份后签一张「通行令牌」给应用，应用据此放行。

很多人在自建时会把几个「安全 / 基础设施类」服务混在一起选，其实它们回答的是完全不同的问题。下表把站内已经写过的相邻方案和 authentik 逐一切开：

一句话总结边界：authentik 不是密码管理器（不保管、不填充你的密码，那是 Vaultwarden 的事）；不是 VPN 或内网穿透（它不改变网络可达性，那是 WireGuard / frp 的事）；不是反向代理（它发给应用的是「身份」，不是「流量」）。它是横跨在这两者之间、专门回答「身份」问题的那一层。

二、部署前的三条前置条件（先确认，再动手）

第 1 步：选系统——优先 Ubuntu 22.04 / 24.04 或 Debian 12/13

官方通过 Docker 分发，理论上任意现代 Linux 都行。但 centos 7 已于 2024 年 6 月 EOL，不建议再用于新部署；建议直接用 Ubuntu 22.04 / 24.04 或 Debian 12/13。容器方案的好处是：宿主机只需要有 Docker 与 Compose v2，应用本身依赖的 Python 运行时、系统库全部打包在镜像里，宿主的 glibc 版本不参与——CentOS 7 的 glibc 2.17 不会成为障碍（这是本站 It 类文章的第六例，前五例是 Immich / RustDesk / AdGuard / Umami / Loki）。

第 2 步：确认资源下限——2 核 2G 起步，数据库内置

官方 Requirements 原文只有两条：一台至少 2 核 CPU、2 GB 内存的主机，以及 Podman 或 Docker Compose（Compose v2）。注意 authentik 从 2026 版起不再需要 Redis——官方 compose 里只有 postgresql、server、worker 三个服务。也就是说，这一台机器就是「认证中心」的全部：数据库、Web、后台任务都在上面。

第 3 步：先锁定一个「专属域名」和一个「端口」

SSO 的信任关系是围绕域名建立的：应用的回调地址、Cookie 的域、OIDC 的签发者（issuer）全都写死了域名。所以第一件事是给它一个独立子域名，例如 sso.example.com，并准备好 DNS 解析。不要打算把它放到 https://example.com/authentik/ 这种子目录下——虽然 authentik 支持设置 AUTHENTIK_WEB__PATH 做子路径部署，但绝大多数 OAuth 客户端对子路径的兼容性不好，独立子域名是最省心的做法。

三、第一步：用 Docker Compose 部署 authentik + PostgreSQL

第 1 步：安装 Docker 与 Compose v2

Ubuntu / Debian 上按官方源安装（含 docker-compose-plugin，即 Compose v2）：

sudo apt update
sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
docker compose version

最后一行应打印 Docker Compose version v2.x。以后所有命令都用 docker compose（带空格，v2 插件形式），不要用老的 docker-compose。

第 2 步：建目录，拉取官方 compose.yml

sudo mkdir -p /opt/authentik && cd /opt/authentik
sudo wget https://docs.goauthentik.io/compose.yml -O docker-compose.yml

这份 compose 里已经写好了三个服务（postgresql、server、worker），并把镜像固定为 ${AUTHENTIK_TAG:-2026.8.4}——也就是说默认就是当前稳定版，这是一个很好的默认值，后面升级时只改 .env 里的版本号即可。

第 3 步：生成两个密钥并写入 .env

官方明确给出了生成命令（tr -d '\n' 是必要的，否则换行会被写进 .env）：

echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
chmod 600 .env

再按需追加两项（可选）：

#把宿主机暴露端口固定下来（默认 9000/9443；要让 Nginx 走 80/443 就改成 80/443）
echo "COMPOSE_PORT_HTTP=9000" >> .env
echo "COMPOSE_PORT_HTTPS=9443" >> .env
#固定版本号，避免被动升级
echo "AUTHENTIK_TAG=2026.8.4" >> .env

关于 AUTHENTIK_ERROR_REPORTING__ENABLED=true：官方文档把「开启错误上报」作为可选步骤列出，它是把匿名错误日志与性能数据发往官方使用的 Sentry（sentry.io），默认是关闭的。出于隐私考虑，除非你在排障，生产环境建议保持关闭；要自己收数据就配置 AUTHENTIK_ERROR_REPORTING__SENTRY_DSN 指向自建 Sentry。

🔴 一条硬性禁令：官方警告，不要在容器里挂载或更新 /etc/timezone / /etc/localtime。authentik 内部所有操作一律使用 UTC，界面上的时间会按用户时区自动本地化；一旦挂载宿主机时区，OAuth 与 SAML 的时间戳校验就会出错（官方 issue #3005 记录过这个问题）。所以 compose 里不要加任何时区挂载。

第 4 步：启动并确认三个容器

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

docker compose ps 应看到三个服务都是 running（或 healthy）状态。postgresql 的 healthcheck 用的是 pg_isready，server 与 worker 会等它健康后才启动。第一次启动会执行数据库迁移，可能需要一两分钟；用 sudo docker compose logs -f server 观察，看到 Gunicorn / uvicorn 开始监听即可。

启动后，直接访问 http://<服务器IP>:9000 就能看到登录界面。能打开就说明骨架没问题，接下来才是把它正式暴露到公网。

四、第二步：Nginx 反向代理 + HTTPS + 真实客户端 IP

第 1 步：先收紧容器端口，只绑本机

默认 compose 把 9000/9443 映射到 0.0.0.0，等于把认证中心直接挂在公网上裸奔。正确做法是改成只绑 127.0.0.1，让 Nginx 去暴露它：

    ports:
      - "127.0.0.1:9000:9000"
      #- "127.0.0.1:9443:9443"   # 只用 HTTP 上联 Nginx 时可注释掉

改完 sudo docker compose up -d 重建即可。

第 2 步：配置 Nginx（含 WebSocket 转发）

authentik 的界面（尤其涉及实时更新的页面）会用到 WebSocket。Nginx 有两处必须配：map 里的 Connection 变量，以及在 location 里转发 Upgrade / Host 头。这是全网出现频率最高的 authentik 报错根源——少了 Host 头会导致 CSRF 校验失败，页面点任何按钮都报 CSRF Failed。

upstream authentik {
    server 127.0.0.1:9000;
    keepalive 10;
}

#WebSocket 与普通请求共用同一入口，需要按需切换 Connection 头
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      '';
}

server {
    listen 80;
    server_name sso.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name sso.example.com;

    ssl_certificate     /etc/letsencrypt/live/sso.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/sso.example.com/privkey.pem;
    add_header Strict-Transport-Security "max-age=63072000" always;

    location / {
        proxy_pass http://authentik;
        proxy_http_version 1.1;

        #① 让 authentik 知道「用户看到的是 https、访问的是哪个域名」
        proxy_set_header Host              $http_host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host  $http_host;

        #② WebSocket 支持
        proxy_set_header Upgrade     $http_upgrade;
        proxy_set_header Connection  $connection_upgrade;
    }
}

写完 sudo nginx -t && sudo systemctl reload nginx。

如果你希望 Nginx 直连 authentik 的 HTTPS 监听（9443）而不是 HTTP（9000），把 proxy_pass 改成 https://authentik、上游端口改成 9443 即可（nginx 的 proxy_ssl_verify 默认关闭，因此自带证书不会报错）。

第 3 步：让 authentik 正确识别「真实客户端 IP」（95% 的人会漏）

authentik 只有在「信任的上游代理」名单里看到 Nginx 的 IP 时，才会采信 X-Forwarded-For 里的客户端 IP。这个名单就是 AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS，默认值已经覆盖 127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、fe80::/10、::1/128。因此当 Nginx 与 authentik 在同一台机器上（走 127.0.0.1）时，无需额外配置即可正确取到客户端 IP。

但如果你的架构是「Cloudflare → Nginx → authentik」，或 Nginx 在另一台内网机器上且网段不在默认名单里，就必须显式追加，否则审计日志里所有事件的来源 IP 都是代理地址，按 IP 做限流和封禁也就全部失效：

#例：Nginx 部署在 172.20.0.0/16 网段
echo 'AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS=["127.0.0.0/8","10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","172.20.0.0/16"]' >> .env
sudo docker compose up -d

五、第三步：初始化管理员与「上线必改」的五项

第 1 步：打开初始化向导（注意结尾的斜杠）

浏览器访问：

https://sso.example.com/if/flow/initial-setup/

结尾的斜杠不能少——官方特别提示，带斜杠才是初始化向导，少了斜杠会直接 404。向导会让你为默认超级用户 akadmin 设置邮箱与密码。这里要分清两件事：akadmin 的登录名永远是 akadmin，而它旁边还能设一个「显示名 / 邮箱」用于展示。

设置完成后用 akadmin 登录 https://sso.example.com/ 进入管理后台。左侧是主菜单：Applications（应用）、Providers（提供方）、Outposts（出站节点）、Directory（用户/组/角色）、Flows and Stages（流程与阶段）、System（系统与任务）。

第 2 步：把「上线必改」的五项一次性做完

1. 改掉 akadmin 的默认登录名：新建一个你自己名字的超级用户，用它登录，然后把 akadmin 停用（或改成一个只有你知道的强用户名）。默认超级用户是全网扫描器的第一目标。
2. 关闭「自助注册」：authentik 默认的注册流程在部分版本里是开放的。到 Flows and Stages 里检查注册流程（默认某个 enrollment flow）是否绑定在登录页上，纯内网/团队使用就直接禁用，账号一律由管理员创建。
3. 配置 SMTP 邮件：密码重置、邮箱验证、通知规则都依赖它。在 System → Settings 里填 SMTP 主机 / 端口 / 账号 / 密码（也可用环境变量 AUTHENTIK_EMAIL__*）。
4. 确认 AUTHENTIK_SECRET_KEY 已固定：它是用于 Cookie 签名的密钥，一旦更换，所有已登录会话立即失效；反过来，如果它不固定（比如每次容器重建都重新生成），用户就会莫名其妙地反复掉线。按第 3 步写入的 .env 是持久化的，确保别把它放进会被覆盖的编排里。
5. 确认没有挂载宿主机时区（见上一节的硬性禁令），并把 AUTHENTIK_LOG_LEVEL 保持默认的 info——不要用 trace，官方警告 trace 会把会话 Cookie 等敏感信息写进日志。

第 3 步：设置默认的「登录即失效」策略

authentik 官方推荐的最佳实践还包括：为超级用户开启两步验证（下文有专门一节）、把后台的 System → Overview 里的健康检查过一遍（会显示数据库、任务队列、出站节点的状态）。顺便说一句，authentik 的事件（Events）审计日志是免费功能，每一次登录、每一次后台改动都会被记录，建议定期导出留档。

六、第四步：接入第一个应用——用 OIDC 把 Grafana 接进来

理论讲再多不如接一个真实应用。我们以站内已经部署过的 Grafana 为例，走一遍标准 OIDC 流程。

第 1 步：在 authentik 里创建应用与提供方

1. 进入 Applications → Providers → Create，选 OAuth2/OpenID Provider；
2. 授权流程（Authorization flow）保持默认的「default-provider-authorization-implicit-consent」（内部应用不需要用户手动同意授权）；
3. 客户端类型选 Confidential（服务端应用，有 Secret）；
4. 在 Redirect URIs 里填 Grafana 的回调地址：https://grafana.example.com/login/generic_oauth；
5. 保存后，在提供方详情页记下三样东西：Client ID、Client Secret、以及右上角的 OpenID Configuration Issuer（形如 https://sso.example.com/application/o/grafana/）。

然后到 Applications → Create，给这个应用起个名字（如 Grafana），并把上一步的 Provider 绑上去。应用名会自动成为它的 slug（如 grafana），也就是 OIDC 的 issuer 路径——这个 slug 后面要和 Grafana 配置里的一致。

第 2 步：在 Grafana 侧填上 OIDC 参数

在 Grafana 的配置文件或容器环境变量里加入（OAuth 的通用写法，Grafana 支持 generic_oauth）：

[auth.generic_oauth]
enabled = true
name = authentik
client_id = <上一步的 Client ID>
client_secret = <上一步的 Client Secret>
scopes = openid profile email
auth_url = https://sso.example.com/application/o/authorize/
token_url = https://sso.example.com/application/o/token/
api_url = https://sso.example.com/application/o/userinfo/

第 3 步：验证并理解「端点速查表」

重启 Grafana 后，登录页会出现「Sign in with authentik」。点进去，如果配置正确，会跳到 SSO 域名完成登录，再跳回来。若报错，90% 是这三处不匹配：回调地址（Redirect URI）没完全一致、issuer 域名写错、或反向代理没传 Host 头导致 CSRF 失败。

OIDC 的四个关键端点（把 grafana 换成你的应用 slug 即可）：

授权的签名算法默认 RS256，由 authentik 自带的「authentik Self-signed Certificate」签名；支持的授权类型（grant types）以授权码（authorization_code）和刷新令牌（refresh_token）为主，机密客户端还支持 client_credentials，设备类应用可用 device_code。

小技巧：官方维护了一个 integrations 站点，收录了 180 多个常见应用的对接方法（Nextcloud、Portainer、Jellyfin、Wiki.js、Vikunja、Harbor 等都在内）。接新应用时先查它，比对着通用 OIDC 文档猜字段快得多。

七、第五步：把剩下的应用也接进来（三种接法怎么选）

不同的自建服务对身份协议的支持程度差别很大，authentik 提供三条路把它们都收编：

• OIDC / OAuth2：应用原生支持 OIDC 时首选，最干净。代表：Grafana、Nextcloud、Wiki.js、Portainer、Vikunja、Harbor、Jellyfin（插件）。
• SAML 2.0：只支持 SAML 的老式企业应用，authentik 同样可以签 SAML，用证书做信任。
• LDAP：应用支持 LDAP 目录时用它（authentik 通过 LDAP Outpost 对外提供 LDAP 协议，应用当作普通 LDAP 服务器连），适合 GitLab 这类把 LDAP 作为「账号来源」的服务。
• 代理提供方（Proxy Provider / forward auth）：这是最强的兜底方案——应用完全不支持任何身份协议（比如一个只会返回静态页面的内部后台）时，让 Nginx 去问 authentik「这人登录了吗」，登录了才放行。应用本身一行代码都不用改。

代理提供方分两种模式：单应用模式（每个应用一个外部域名、一套策略，控制最细）与域级模式（同一父域下所有应用共享一次认证，配置最省，但无法对单个应用做差异化授权）。它们的原理是：只有应用域名下的 /outpost.goauthentik.io 路径被转发给 authentik 出站节点，应用流量本身仍由你的 Nginx 直送上游。Nginx 侧的核心骨架是：

location / {
    auth_request     /outpost.goauthentik.io/auth/nginx;
    error_page 401   = @goauthentik_proxy_signin;
    auth_request_set $auth_cookie $upstream_http_set_cookie;
    add_header       Set-Cookie $auth_cookie;
    #把身份以请求头透传给上游应用
    auth_request_set $authentik_username $upstream_http_x_authentik_username;
    proxy_set_header X-authentik-username $authentik_username;
    proxy_pass http://你的上游应用;
}

location @goauthentik_proxy_signin {
    internal;
    add_header Set-Cookie $auth_cookie;
    return 302 /outpost.goauthentik.io/start?rd=$request_uri;
}

location /outpost.goauthentik.io {
    proxy_pass https://sso.example.com;
    proxy_set_header Host $http_host;
}

（完整模板见官方 server_nginx 文档页，Caddy / Traefik / HAProxy / Envoy 也各自有现成模板。）

无论用哪种接法，Outpost（出站节点）都是同一个概念：它是 authentik 派出的「哨兵」，内嵌的那个出站节点会随 server 一起运行；也可以单独部署独立出站节点去连远程应用。这也是官方 compose 里为什么要把 /var/run/docker.sock 挂给 worker 容器——出站节点是以容器形式拉起的，需要这个 socket。

八、开启两步验证（MFA）与访问控制

两步验证：TOTP 与 WebAuthn

authentik 内建多种 MFA 阶段（Stage）：TOTP（手机验证器 App，如 Google Authenticator）、WebAuthn（安全密钥 / 指纹 / Passkey，防钓鱼能力最强）、Duo、短信（Twilio），以及一次性静态令牌。做法是在 Flows and Stages → Stages 里创建一个 MFA 阶段，再把它挂到登录流程（Flow）上。建议：给所有超级用户强制开启，普通用户用「可选 + 引导」。

访问控制：绑定（Bindings）、策略（Policies）与组

authentik 的授权模型很简单但很强：「应用」与「提供方」各自可以绑定策略。最常用的是组绑定——只有当用户属于某个组时，才能访问某个应用。例如「财务组才能进财务看板」「运维组才能进 Grafana 的管理后台」。再配合 Property Mapping（属性映射），你可以把用户在 authentik 里的组名映射成应用能读懂的角色，实现「在 authentik 里改一次组，应用的权限自动跟着变」。

九、安全加固清单

1. 端口只绑 127.0.0.1：9000/9443 绝不能直接对公网开放，一切流量走 Nginx。
2. 启用 HTTPS 且强制跳转：Cookie 与令牌都在链路上跑，明文就是自杀。
3. Nginx 必须传 Host 与 X-Forwarded-Proto：否则 CSRF 校验失败（表现为「点什么都报 CSRF Failed」）。
4. 改掉 akadmin、关闭自助注册、禁用不再使用的账号。
5. 只信任该信任的代理：AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS 只加真实代理网段，不要图省事加 0.0.0.0/0——那等于允许任何人伪造来源 IP。
6. 慢启动防护用 Fail2Ban：为 Nginx 的 authentik 访问日志写一条过滤器，对 login 相关路径的 4xx/5xx 做封禁（可参考站内《网站安全加固指南》）。
7. 给超级用户开 MFA，并定期查看 Events 审计日志里来自陌生地理位置的登录。
8. 保留 AUTHENTIK_SECRET_KEY 与数据库密码的备份（放密码管理器里），但永远不要把 .env 提交进 Git。

十、备份、升级与故障排查

备份：数据库 + data 目录 + .env，一个都不能少

cd /opt/authentik
sudo docker compose exec -T postgresql pg_dump -U authentik -d authentik -Fc > "authentik-$(date +%F).dump"
sudo tar czf "authentik-data-$(date +%F).tar.gz" data .env

三样东西缺一不可：PostgreSQL 的 dump（用户、组、应用、全部配置）、data/ 目录（上传的媒体、自定义模板、证书）、.env（AUTHENTIK_SECRET_KEY 与数据库密码）。恢复时用 pg_restore 灌回 dump，再把 data/ 与 .env 放回原位即可。备份的异地留存与保留策略可参考站内《服务器备份与容灾恢复方案》。

升级：读发布说明 → 备份 → 改版本号 → 重启

#1) 先备份（见上）
#2) 读该版本的 release notes，确认有无需要手工处理的迁移
#3) 改 .env 里的版本号
sed -i 's/^AUTHENTIK_TAG=.*/AUTHENTIK_TAG=2026.8.4/' .env   # 改成目标版本
#4) 拉取并重建，server 启动时会自动执行数据库迁移
sudo docker compose pull && sudo docker compose up -d

authentik 采用 年.月.补丁 的版本号（如 2026.8.4），每月一个次版本。两条纪律：一是升级前必须备份，因为数据库迁移不可逆；二是不要用 latest tag（官方已把 latest 冻结在旧版本上，靠它升级会踩坑），永远固定到具体版本号再升。

故障排查速查表

健康检查端点（可接入站内 Uptime Kuma 或 Prometheus + Grafana）：/-/health/live/（进程活着就 200）、/-/health/ready/（数据库连得上才 200）、出站节点 /-/outpost.goauthentik.io/ping。核心、worker 与出站节点都会在单独的 9300 端口暴露 Prometheus 指标，官方还提供了一份现成的 Grafana 面板可以直接导入。

十一、海外云服务器配置推荐与价格对比

authentik 的负载特点是「请求量小、但每次登录都要算密码哈希与签名」——它不像流媒体那样吃带宽，也不像日志系统那样吃磁盘，真正吃的是 CPU 与内存（Django 进程 + PostgreSQL）。官方最低要求写的是 2 核 2G，因此不要选 1 核 1G 的最低档——docker compose pull 加上迁移与首启动，1G 内存很容易在启动阶段被 OOM。

下表的价格为 2026 年 10 月直读 DigitalOcean 与 AWS Lightsail 官方定价页的档位-规格映射（阿里云国际版 / 腾讯云国际版给区间，因活动浮动较大）：

\* Lightsail 低档位标注的 2 vCPU 为突发型（burstable），持续高负载会受 CPU 积分限制；把这个认证中心当作团队基础设施使用时，建议从 $24 档（2 核 4G）起步。DigitalOcean 另有 $4/月（512 MiB）与 $6/月（1 GiB）两档，但都不满足 authentik 的 2G 建议，不建议用于本方案。

声明：本文价格数据采集于 2026 年 10 月，仅为公开官网参考区间，实际以各家官网实时价格为准，金额单位均为美元（USD）。

选型口径（针对 authentik）：

• 个人 / 家庭自建（几台服务、三五个账号）：2 核 2G 就够（DO $18 / Lightsail $12），数据库与认证中心同机。此时 authentik 只在你偶尔登录时才忙一下，负载极低。
• 10~50 人小团队：建议 2 核 4G（$24 档）。人数上升带来的是 PostgreSQL 连接数与登录并发，内存要留够；shm_size: 512mb（官方默认）也建议一并调大。
• 要做高可用（HA）：单机一旦挂了，所有应用都登不进去——所以生产环境更该关心备份与恢复速度，而不是一味堆配置。想要真正的高可用，可以把 server 与 worker 多副本部署在多个节点上共享同一个 PostgreSQL，但这已经超出「小规模生产」的范畴。
• 已有数据库服务器：如果团队已经有独立的 PostgreSQL 主机，可以复用（见站内《MySQL / PostgreSQL 数据库服务器搭建指南》），把数据放到独立磁盘上，主机的磁盘 I/O 更可控。

🚀 需要海外云服务器来部署 authentik？通过 5.chengzicloud.cloud 购买阿里云国际版 / 腾讯云国际版 / AWS，享专属折扣。

十二、常见误区速查

部署 authentik 时，下面这几个「想当然」最容易踩：

1. 「先把 9000 端口开出去看看效果」——错。9000 一旦对公网开放，等于把整个账号体系的门锁放在门外。从一开始就只绑 127.0.0.1，用 Nginx 暴露。
2. 「用 latest 镜像最省事」——错。官方已把 latest 冻结在旧版本，用它永远不会得到新版；而且每次 pull 都可能被动升级。固定版本号才是正解。
3. 「把宿主机时区挂进去，时间才准」——错。authentik 内部一律用 UTC，挂载 /etc/timezone / /etc/localtime 反而会让 OAuth / SAML 认证失败。这一条官方专门用红色警告写明。
4. 「authentik 就是密码管理器」——不是。它不保管、不填充你的个人密码（那是 Vaultwarden 的活），它管的是「服务怎么验你这个人」。
5. 「它要装 Redis」——不用了。2026 版的 compose 只有 PostgreSQL、server、worker 三个服务，不要照抄网上旧教程去加 Redis。
6. 「子路径部署（/authentik/）也没差」——技术上可行（AUTHENTIK_WEB__PATH），但大量 OAuth 客户端对子路径兼容性差。用独立子域名。

推荐方案

• 只要「一次登录、通行全部自建服务」的个人 / 家庭用户：一台 2 核 2G 海外云服务器（DO $18 / Lightsail $12）+ Docker Compose + Nginx HTTPS，接上 3~5 个应用（Grafana、Nextcloud、Portainer）就足够。SSO 带来的体验提升，远超这每月十几美元。
• 10~50 人小团队：2 核 4G（$24 档）+ PostgreSQL 每日 pg_dump + data/ 与 .env 异地备份 + Fail2Ban + 强制 MFA。把「反向代理传 Host 头」和「SECRET_KEY 固定」这两件事做对，稳定性就超过 90% 的自建 IdP。
• 更大的组织 / 已有多套系统：把「接应用」这件事标准化——能用 OIDC 的就上 OIDC，只支持 LDAP 的走 LDAP Outpost，什么都不支持的老系统用代理提供方兜底，再用组绑定统一授权。此时 authentik 就不再是一个「登录组件」，而是和你所有基础设施长在一起的身份底座。

如果你还没决定用哪家云，或想直接省掉选型这一步，5.chengzicloud.cloud 提供阿里云国际版 / 腾讯云国际版 / AWS 等海外云服务器的购买与部署支持。