Keycloak、authentik 和 Zitadel：一台 VPS 选哪个

一台 VPS 适合哪种 SSO 服务器

Keycloak、authentik 和 Zitadel 都是自托管单点登录（SSO）服务器。只要有人希望服务器上的所有应用共用一个登录入口，通常就会考虑它们。在一台小型 VPS 上，它们不能互相替代。对于运行三四个自托管应用的服务器，authentik 是稳妥的默认选择，因为三者中只有它可以在没有内置登录功能的应用前面提供登录页面。如果你要保护的每个应用都已支持标准协议，并且服务器有足够内存运行 Java 虚拟机（JVM），应选择 Keycloak。Zitadel 面向通过 API 发布产品的开发者；在低于 4 GB 内存的服务器上，我不会尝试部署它。

先完成选择，再进行安装。确定方案后，请参阅 在 VPS 上手动安装 authentik，其中按步骤介绍了配置过程。

每个服务实际需要多少 RAM？

先确定资源下限，因为在评估功能之前，它就决定了候选范围。下面的数字来自各项目自行发布的资料，信息读取时间为 2026 年 10 月。这些是供应商建议，不是负载测试结果。

[
  {
    "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 文件运行 3 个容器：PostgreSQL、server 和 worker。这个主机配置必须覆盖全部 3 个组件，包括数据库。

Keycloak 发布了 3 个项目中最具体的数值。其容量规划指南指出：“包含 Realm 数据缓存和 10,000 个缓存会话的 Pod，基础内存使用量为 1250 MB RAM。”这 1250 MB 是 Keycloak server 及这些缓存所需的内存。该指南单独规划数据库，因此 PostgreSQL 还需要额外的内存。页面还说明了容器内存限制为何如此重要：Keycloak 会将内存限制的 70% 用作堆内存，并额外使用约 300 MB 非堆内存；其示例将 1250 MB 的基础需求换算为 1360 MB 的内存限制。为容器分配 1 GB 时，计算出的堆内存约为 717 MB；加上约 300 MB 非堆内存，总量约为 1017 MB。在该限制下几乎没有余量，而指南给出的、包含 Realm 缓存和 10,000 个会话的基础需求为 1250 MB。

Zitadel 的 compose 页面同样要求 2 GB，即 2048 MB，并将其列为整篇指南的前置条件，适用于从快速入门到 homelab 或半生产阶段的部署。若要进行更高规模的规划，应参考其生产环境页面。Zitadel 进程本身需要“约 512MB RAM，并且可以使用少于 1 个 CPU 核心运行”。数据库才是主要的内存消耗部分：“每 100 个请求/秒（req/s）约需要 1 个 CPU 核心和每个核心 4GB RAM”。密码哈希还需要“提供 4 个 CPU 核心用于此用途”，因为登录请求突增会导致 CPU 使用率急剧上升。官方 v4 compose 在不添加其他组件的情况下运行 4 个容器：Traefik 作为代理、Zitadel API、单独的 Login UI 容器，以及 PostgreSQL。Redis 和 OpenTelemetry collector 位于可选的 compose profiles 后面。

因此，Keycloak 和 authentik 可以运行在 4 GB VPS 上，并为受保护的应用留出一些余量。Zitadel 可以在 2 GB 上启动，但每次登录都会与自带的 PostgreSQL 争用内存。我不会在低于 4 GB 的环境中运行 Zitadel；如果同一台主机还承载应用，我会选择 8 GB。

每个组件在你的服务器上实际运行什么

authentik 由 PostgreSQL 和同一镜像的两个副本组成，分别是 server 和 worker。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 -d

server 发布 9000 和 9443 端口。首次访问 9000 端口时会进入初始设置流程，你可以在其中为默认的 akadmin 用户设置密码。在该端口可以从互联网访问之前，应在前面配置使用有效证书的反向代理。

Keycloak 由一个进程和一个由你提供的数据库组成。快速入门配置只需一个容器。

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.8.1 start-dev

start-dev 用于查看和试用。它使用本地开发数据库，且不启用 TLS（传输层安全），因此以这种方式启动、随后又删除的容器会一并删除你的 realm。生产环境应改用 start，通过 KC_DB 连接真实的 PostgreSQL，并通过 KC_HOSTNAME 使用公网主机名。Keycloak 的生产指南还说明，与服务器之间的所有通信都需要安全通道，因此 HTTPS 在这里不是可选项。

Zitadel 就是上文介绍的四容器堆栈。

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 用于加密数据库中机密信息的 32 字符密钥，因此丢失它就意味着无法再访问这些机密信息。如果你刚开始运行这类堆栈，可以参阅 VPS 的 Docker Compose 基础知识，其中介绍了决定身份提供商能否在重启后恢复的卷和 restart policy 配置。

每个产品支持哪些协议？

三者都支持 OpenID Connect (OIDC)。这是构建在 OAuth 2.0 之上的登录层，现代应用通常使用它。三者也都支持 SAML 2.0（安全断言标记语言），这是企业软件仍在发布中使用的较旧标准。真正的区别在于 LDAP（轻量级目录访问协议）。同一个词涵盖了两种相反的用途。

从 LDAP 读取表示 SSO 服务器针对已有目录验证密码。Keycloak 通过用户联合实现这一点。Zitadel 也支持此功能：其文档介绍了如何“将 LDAP 服务器连接为 ZITADEL 中的身份提供商”。

提供 LDAP 服务表示只支持 LDAP 的应用可以连接到 SSO 服务器，就像连接目录服务器一样。只有 authentik 支持此功能。其 LDAP 提供商通过专用 LDAP outpost，使“authentik 数据库中的所有用户和组都可通过 LDAP 目录搜索”，并可在端口 636 上使用 LDAPS。默认情况下，已绑定的用户只能搜索自己的详细信息和所属组。因此，应用用于绑定的服务账户需要具备“Search full LDAP directory”权限，才能查看所有用户。其文档只介绍绑定和搜索，没有说明写入操作，因此应将其视为只读目录。一次性代码通过分号追加到密码后面，如 password;123456 所示；绑定期间不支持 SMS 验证器。

如果你的应用列表中有一个应用只支持 LDAP，比较到这里就结束了。Keycloak 和 Zitadel 无法响应这种绑定请求，因此你需要在它们旁边运行第二个目录，并让两套用户列表保持同步。

没有登录功能的应用怎么办？

Forward auth 是解决方案，也是自托管服务器经常遇到的场景。反向代理会先向 SSO 服务器询问请求是否获准，然后再将请求转发到上游。后端应用无需了解 SSO。它收到的是代理已经检查过的请求，通常还会在请求头中包含用户名。

authentik 的 proxy provider 支持 3 种有文档说明的模式。“Proxy”模式让 authentik outpost 自行将流量转发到上游应用。“Forward auth (single application)”模式保留现有反向代理处理流量，仅使用 authentik 执行身份验证检查。“Forward auth (domain level)”模式通过单个 provider 保护同一父域名下的所有应用。域级模式更方便，但有一个文档明确说明的限制：它“无法为每个受保护的应用强制执行不同的应用级授权规则”。因此，该域名下的所有应用都共享同一组策略。

Keycloak 没有这些功能。它的配套代理 Keycloak Gatekeeper 后来更名为 Louketo Proxy，于 November 2020 结束生命周期，并于 December 2020 在 GitHub 上归档。要保护不支持 OIDC 的应用，您需要在应用前面运行独立组件，通常是 oauth2-proxy，并将其指向 Keycloak client。Zitadel 也没有自己的 forward auth 模式，因此同样需要安装、监控和升级额外组件。

额外增加这一跳后，反向代理配置就不再简单。因此，在将 auth middleware 接入之前，请先阅读 Traefik 如何为多个 Docker Compose 应用提供前置代理。

升级路径有多复杂？

截至 2026 年 10 月 25 日，当前版本分别为 Keycloak 26.8.1、authentik 2026.8.5 和 Zitadel v4.20.0。三者都会对 PostgreSQL 执行架构迁移，因此每次升级都会修改数据库。每次升级前都先备份数据库。这个习惯比本次比较中的任何功能都更有价值。

authentik 的规则最严格，而且说明得很明确：“升级必须按照主版本顺序进行；不得直接从较旧的主版本跳到最新版本。”在进入下一个版本前，先升级到当前版本系列中的最新补丁版本；并且“authentik 不支持降级”。对于采用日历版本的项目，如果落后一年，原本的一次升级就会变成一连串升级，每次升级都有自己的数据库迁移。

Keycloak 的升级指南规定了应遵循的顺序：先查看上一版本以来的迁移变更，再升级服务器，最后升级适配器。数据库迁移会自动运行；也可以将迁移导出后手动应用。需要在变更生效前阅读迁移内容时，手动方式很有用。Keycloak 的代价在于阅读工作。其发行说明包含弃用项和行为变更，容易被跳过，但遗漏后处理成本很高。

Zitadel 将初始化和设置阶段与运行中的服务器分开。其生产环境指南建议保持这种分离，避免扩容时重复执行设置工作。在单台 VPS 上，这通常意味着 API 报告健康状态前，设置步骤必须完成。因此，compose 文件提供了健康检查，启动命令使用 --wait。

每个项目面向的用户，以及各自的不足

Keycloak 是 Red Hat 的身份服务器，面向使用 realm、组、角色映射和现有企业目录的组织。它是这三个项目中标准实现最完整的一个。但在一台运行四个自托管应用的 2 GB VPS 上，其中一半应用不支持 OIDC 时，它就不合适。Keycloak 服务器本身就要占用 1250 MB，还不包括数据库。您需要学习一套面向企业设计的 realm 模型，最后仍要为实际需要保护的应用安装 oauth2-proxy。

authentik 面向自托管用户，这一点从功能列表中就能看出。它内置 forward auth 和 LDAP provider，并通过可视化编辑器构建登录流程。但如果您希望在没有企业级预算的情况下获得厂商支持，或者希望使用不会每隔几周就变更一次的发布节奏，它就不合适。支持仅随付费订阅提供：$1k 以上的 Enterprise 订阅包含工单支持，Enterprise Plus 提供带 SLA 的专属支持，起价为每年 $20k。使用日历版本号、无法降级且不能跳过版本，会带来实际的运维工作。当您的实际问题只是配置一个 OIDC 客户端时，流程编辑器还意味着需要学习一整套模型。

Zitadel 面向将身份验证集成到所发布产品中的开发者，并将强大的 API 和多租户作为一等功能。但在这个场景中，它恰好不合适。四个容器、不支持 forward auth，以及按每个 core 4 GB 规划的数据库，对于一台部署了密码管理器和 wiki 的 VPS 来说并不合适。

我会在一台 VPS 上运行什么，以及如何运行

如果一台 VPS 上运行三个或四个自托管应用，请使用 authentik。三者都会提供登录界面。决定性因素是，部分应用永远不会支持 OIDC，而 authentik 内置了 forward auth，可以直接解决这个问题，不需要再部署旁边的其他组件。

如果条件允许，为它分配 4 GB；只有在旁边的应用都很小的情况下，才使用 2 GB。不要让端口 9000 暴露在公网，将 TLS 终止放在前置反向代理上。每天夜间导出 PostgreSQL，并将备份存储在服务器之外，因为没有备份的身份提供商会成为其后所有应用的单点故障。使用专用的非特权账户运行整个堆栈，不要使用 root：在 VPS 上设置最小权限用户介绍了所需的账户和文件所有权配置。

如果所有受保护的应用都已支持 OIDC 或 SAML，或者需要 Keycloak realm 提供的细粒度角色模型，请改用 Keycloak。如果你正在为其他用户构建注册使用的应用，并且需要它的 API 和租户模型，请选择 Zitadel。这两者都不适用于本文讨论的单台服务器运行三个应用的场景。

你首先会遇到的故障模式

Keycloak 重启后没有数据。 你使用 start-dev 启动了它，该方式使用本地开发数据库。在没有卷的容器中，删除容器也会删除 realm。改用 start，并通过 KC_DB=postgres 将其连接到实际数据库。

小型主机上的 authentik worker 容器消失。 worker 和 server 使用同一个镜像，并且都会运行 Python 进程；PostgreSQL 也需要占用 2 GB 主机内存中的一部分。运行 docker compose ps 确认哪个服务退出，然后检查 dmesg 中是否存在因内存不足而被终止的记录，再开始查找应用本身的错误。

Zitadel 的 Console 在代理后无法工作。 Zitadel API 使用 gRPC，因此到上游的整个连接都必须使用 HTTP/2。要求页面要求反向代理支持到上游的 HTTP/2 连接，并列出了经过测试的 Traefik v3.x、NGINX v1.x、Caddy v2.x 和 Apache httpd 2.4.x 版本。如果代理将到上游的连接降级为 HTTP/1.1，登录页面可以加载，但 Console 会失败。

每个应用都会将您重定向回登录页面。 SSO 服务器的公网 URL 必须与应用中配置的 URL 完全一致，包括 scheme 和端口。Keycloak 将其称为 hostname 设置，Zitadel 将其称为 external domain。两者不一致时，应用会将您重定向到一个服务器不认为属于自己的登录地址，浏览器便会在两个地址之间反复跳转。

FAQ

三者中哪一个适合 2 GB 的 VPS？

authentik 和 Keycloak。authentik 明确要求主机至少具备 2 个 CPU 核心和 2 GB 内存；Keycloak 的规模指南指出，在不包含数据库的情况下，服务器的基础内存需求为 1250 MB。一旦加入受保护的应用，两者在 2 GB 内存下都会显得吃力，因此建议将 4 GB 作为舒适的起步配置。Zitadel 的 compose 指南也列出了 2 GB 的要求，并展示了如何在家庭实验室或半生产环境中运行，但其生产环境指南建议为密码哈希分配 4 个 CPU 核心，并为每个数据库核心分配 4 GB 内存，因此实际登录流量到来后，2 GB 预计会变得紧张。

Keycloak 或 Zitadel 能保护没有自带登录功能的应用吗？

不能单独实现。两者均不提供前向认证（forward auth）组件。Keycloak 的旧版配套代理 Louketo Proxy 已于 2020 年 11 月停止维护，其 GitHub 仓库也已于 2020 年 12 月归档，因此不应基于此构建。你需要将 oauth2-proxy 或类似组件置于反向代理与应用之间，并将其指向 SSO 服务器上的 OIDC 客户端。authentik 通过其代理提供程序（proxy provider）以“前向认证（单应用）”或“前向认证（域名级）”模式原生支持此功能。

哪一个可以为仅支持 LDAP 的应用充当 LDAP 服务器？

authentik。其 LDAP 提供程序运行在 outpost 上，使 authentik 中的用户和组可通过 LDAP 进行搜索，并支持在 636 端口使用 LDAPS。其文档仅涵盖绑定（bind）和搜索（search）功能，因此请将其视为只读。Keycloak 和 Zitadel 的方向则相反：两者均从现有的 LDAP 目录读取数据作为用户源，均无法响应来自应用的 LDAP 绑定请求。

升级 authentik 时可以跳过版本吗？

不可以。文档明确指出升级必须遵循主要版本发布的顺序，不应从旧的主要版本直接升级到最新版本。应先升级到每个版本内的最新补丁版本，然后逐个版本进行升级。在每一步操作前请备份 PostgreSQL，因为 authentik 不支持降级，且迁移操作仅支持向前执行。