Keycloak, authentik или Zitadel: что выбрать для VPS

Какой SSO-сервер выбрать для одного VPS

Keycloak, authentik и Zitadel — это self-hosted серверы единого входа (SSO), которые упоминаются чаще всего, когда требуется общая авторизация для всех приложений на сервере. На одном небольшом VPS они не являются взаимозаменяемыми. authentik — это оптимальный выбор по умолчанию для сервера, на котором запущено три или четыре приложения, так как это единственный из трех вариантов, способный добавить экран входа перед приложением, у которого нет собственной системы авторизации. Keycloak подходит в том случае, если каждое защищаемое приложение уже поддерживает стандартный протокол, а вы готовы выделить память под виртуальную машину Java (JVM). Zitadel разработан для разработчиков, выпускающих продукт через API, и я бы не рекомендовал использовать его при объеме оперативной памяти менее 4 GB.

Сначала выберите решение, затем приступайте к установке. После того как выбор сделан, в практическом руководстве по установке authentik на VPS описан пошаговый процесс настройки.

Сколько оперативной памяти на самом деле нужно каждому из них?

Начните с минимальных системных требований, так как именно они определяют список кандидатов еще до оценки функциональности. Приведенные ниже цифры — это официальные данные проектов, актуальные на октябрь 2026 года. Это рекомендации поставщиков, а не результаты нагрузочного тестирования.

[
  {
    "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 ГБ оперативной памяти», что составляет 2048 МБ. В официальном файле compose запускается 3 контейнера: PostgreSQL, сервер и worker.

Keycloak публикует наиболее точные данные из 3. В руководстве по подбору ресурсов указано, что «базовое потребление памяти для пода, включая кэши данных Realm и 10 000 сессий, составляет 1250 МБ RAM». Эти 1250 МБ покрывают только сам Java-процесс, без учета базы данных. На той же странице объясняется, почему лимит контейнера так важен: Keycloak выделяет 70% лимита памяти под heap и использует около 300 МБ вне heap. Если выделить контейнеру 1 ГБ, он вычислит heap размером около 717 МБ, а дополнительные 300 МБ вне heap доведут общий объем до 1017 МБ. Это не оставляет запаса под лимитом, в то время как базовая цифра из руководства с учетом кэшей и 10 000 сессий составляет 1250 МБ.

Страница Zitadel для Docker Compose также требует 2 ГБ, те же 2048 МБ, и эта цифра актуальна как для быстрого старта, так и для домашней лаборатории или этапа предпродакшена. Для более серьезных нагрузок следует изучить страницу с рекомендациями для production. Сам процесс Zitadel требует «примерно 512 МБ RAM и может работать менее чем на одном ядре CPU». База данных — наиболее ресурсоемкая часть: «около одного ядра CPU на 100 запросов в секунду (req/s) и 4 ГБ RAM на ядро». Для хеширования паролей требуется «4 ядра CPU», так как всплеск попыток входа вызывает скачок нагрузки на процессор. Официальный compose-файл версии v4 запускает 4 контейнера еще до добавления чего-либо: Traefik в качестве прокси, Zitadel API, отдельный контейнер Login UI и PostgreSQL. Redis и OpenTelemetry collector находятся в составе опциональных профилей compose.

Таким образом, Keycloak и authentik помещаются на VPS с 4 ГБ RAM, оставляя место для приложений, которые вы защищаете. Zitadel запустится на 2 ГБ, но при каждом входе пользователя будет конкурировать за память со своим же экземпляром PostgreSQL. Я бы не стал запускать Zitadel на системе с объемом памяти менее 4 ГБ, а на сервере, где также размещены другие приложения, я бы предпочел 8 ГБ.

Что именно запускается на вашем сервере

authentik состоит из PostgreSQL и двух копий одного образа: сервера и воркера. Сервер обрабатывает HTTP-запросы и содержит встроенный аутпост. Воркер выполняет фоновые задачи, такие как синхронизация каталогов и отправка электронной почты. Стандартная установка лаконична.

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

Сервер открывает порты 9000 и 9443. При первом обращении к порту 9000 запускается мастер начальной настройки, где вы задаете пароль для пользователя по умолчанию akadmin. Перед тем как открывать доступ к этому порту из Интернета, установите перед ним reverse proxy с действительным сертификатом.

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

start-dev предназначен для ознакомления. Он работает с локальной базой данных для разработки и без TLS (transport layer security), поэтому при удалении такого контейнера все настройки realm будут потеряны. Для production-среды используйте start, подключив полноценную PostgreSQL через KC_DB и настроив публичное доменное имя через KC_HOSTNAME. Руководство по эксплуатации Keycloak в production также указывает, что весь обмен данными с сервером требует защищенного канала, поэтому использование 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

Перед первым запуском установите ZITADEL_MASTERKEY в файле .env. Это 32-символьный ключ, который Zitadel использует для шифрования секретов в базе данных; его потеря приведет к невозможности доступа к этим данным. Если вы новичок в запуске подобных стеков, в статье основы Docker Compose для VPS описаны параметры томов и политики перезапуска, от которых зависит, сохранится ли работоспособность вашего провайдера идентификации после перезагрузки.

Какие протоколы поддерживает каждый из них?

Все три решения поддерживают OpenID Connect (OIDC) — уровень авторизации поверх OAuth 2.0, используемый современными приложениями, а также SAML 2.0 (security assertion markup language) — более старый стандарт, который до сих пор поставляется с корпоративным ПО. Основное различие заключается в LDAP (lightweight directory access protocol), где один термин описывает две противоположные задачи.

Чтение из LDAP означает, что SSO-сервер проверяет пароли по уже существующему у вас каталогу. Keycloak реализует это через федерацию пользователей (user federation). Zitadel также поддерживает эту функцию: в его документации описано, как «подключить LDAP-сервер в качестве поставщика идентификационных данных в ZITADEL».

Обслуживание LDAP означает, что приложение, работающее только по протоколу LDAP, может выполнять bind к вашему SSO-серверу, как если бы он был каталогом. Это умеет только authentik. Его LDAP-провайдер делает «всех пользователей и группы в базе данных authentik доступными для поиска через LDAP-каталог» с помощью выделенного LDAP-аванпоста (outpost), при этом LDAPS доступен на порту 636. Документация описывает только операции bind и search и не упоминает операции записи, поэтому рассматривайте его как каталог только для чтения. Одноразовый код добавляется к паролю через точку с запятой, как в password;123456, а SMS-аутентификаторы при выполнении bind не поддерживаются.

Если в вашем списке есть приложение, поддерживающее только LDAP, на этом сравнение заканчивается. Keycloak и Zitadel не смогут ответить на такой запрос bind, поэтому вам придется запустить второй каталог параллельно с ними и поддерживать синхронизацию двух списков пользователей.

Как быть с приложениями, в которых вообще нет системы входа?

Решением является forward auth — сценарий, с которым постоянно сталкиваются владельцы self-hosted серверов. Ваш reverse proxy запрашивает у SSO-сервера разрешение на выполнение запроса перед тем, как передать его upstream-сервису. Само приложение при этом ничего не знает об SSO. Оно получает запросы, которые прокси уже проверил, обычно передавая имя пользователя в заголовке.

Proxy provider в authentik поддерживает этот механизм в трех документированных режимах. Режим "Proxy" предполагает, что authentik outpost сам передает трафик в upstream-приложение. "Forward auth (single application)" оставляет трафик на вашем существующем reverse proxy, используя authentik только для проверки аутентификации. "Forward auth (domain level)" защищает все приложения в рамках одного родительского домена с помощью одного провайдера. Уровень домена наиболее удобен, но имеет документированное ограничение: он «не позволяет применять разные правила авторизации на уровне приложений для каждого защищенного сервиса», поэтому все приложения в этом домене используют один набор политик.

В Keycloak такой функциональности нет. Его сопутствующий прокси, Keycloak Gatekeeper, был переименован в Louketo Proxy, достиг конца жизненного цикла в ноябре 2020 года и был переведен в архив на GitHub в декабре 2020 года. Чтобы защитить приложение без поддержки OIDC, необходимо запустить перед ним отдельный компонент, обычно oauth2-proxy, настроенный на работу с клиентом Keycloak. У Zitadel также нет собственного режима forward auth, поэтому решение то же самое — установка, мониторинг и обновление дополнительного компонента.

Этот дополнительный узел — именно то место, где конфигурация reverse proxy перестает быть простой, поэтому ознакомьтесь с тем, как Traefik обслуживает несколько приложений Docker Compose, прежде чем подключать к нему middleware для аутентификации.

Насколько сложен путь обновления?

По состоянию на октябрь 2026 года актуальными релизами являются Keycloak 26.8.0, authentik 2026.8.3 и Zitadel v4.19.4. Все три продукта выполняют миграцию схемы базы данных PostgreSQL, поэтому каждое обновление подразумевает изменение структуры данных. Всегда делайте резервную копию базы данных перед началом. Эта привычка важнее любой функции, описанной в данном сравнении.

У authentik самые строгие правила, сформулированные предельно ясно: «Обновления должны выполняться последовательно по мажорным версиям; не переходите напрямую со старой мажорной версии на самую последнюю». Необходимо сначала обновиться до последнего патча внутри текущей версии, прежде чем переходить к следующей, при этом «authentik не поддерживает откат версий». Отставание на год в проекте с календарным версионированием превращает одно обновление в целую цепочку, каждое звено которой требует собственной миграции базы данных.

Руководство по обновлению Keycloak предписывает следующий порядок: изучить изменения миграции по сравнению с предыдущей версией, обновить сервер, затем обновить адаптеры. Миграция базы данных выполняется автоматически, либо вы можете экспортировать её и применить вручную — это полезно, если вы хотите ознакомиться с изменениями до их внесения. Сложность Keycloak заключается именно в этом изучении. В примечаниях к релизам содержатся сведения об устаревших функциях и изменениях в поведении, которые легко пропустить, но последствия этого могут быть дорогостоящими.

Zitadel разделяет этапы инициализации (init) и настройки (setup) и этапы работы сервера. Рекомендации по эксплуатации в production советуют держать их раздельно, чтобы масштабирование не приводило к повторному выполнению настроечных операций. На одном VPS это означает, что этап настройки должен завершиться до того, как API сообщит о своей готовности (healthy), поэтому compose-файл содержит проверки работоспособности (health checks), а команда запуска использует --wait.

Для кого предназначен каждый проект и в чем его недостатки

Keycloak — это сервер идентификации от Red Hat, созданный для организаций, использующих области (realms), группы, сопоставления ролей и существующие корпоративные каталоги. Это наиболее полная реализация стандартов из трех представленных. Он проигрывает в сценарии с VPS объемом 2 GB, на котором запущено четыре self-hosted приложения, половина из которых не поддерживает OIDC. Вы тратите 1250 MB оперативной памяти на JVM, изучаете модель областей, спроектированную для компании, и все равно устанавливаете oauth2-proxy для приложений, которые вам действительно нужны.

authentik создан для аудитории self-hosting, что отражено в списке его функций. Он поставляется с поддержкой forward auth и LDAP-провайдером, а также позволяет создавать процессы входа в визуальном редакторе. Он проигрывает, когда вам требуется поддержка от вендора без корпоративного бюджета или стабильный цикл релизов, который не меняется каждые несколько недель. Поддержка доступна только при наличии платной подписки: тикеты в рамках подписки Enterprise стоят от $1k, а выделенная поддержка с SLA в Enterprise Plus начинается от $20k в год. Календарное версионирование без возможности отката или пропуска версий создает реальную операционную нагрузку, а редактор процессов — это целая модель, которую нужно изучать, когда ваша реальная задача — настройка одного OIDC-клиента.

Zitadel создан для разработчиков, внедряющих аутентификацию в свой продукт, с мощным API и мультиарендностью в качестве базовых функций. Он проигрывает именно в этом сценарии. Четыре контейнера, отсутствие forward auth и база данных, требующая 4 GB на ядро, — это неподходящий формат для одного VPS, на котором работают менеджер паролей и вики-система.

Что я запускаю на одном VPS и как это сделать

Для одного VPS с тремя или четырьмя self-hosted приложениями используйте authentik. Все три решения предоставляют экран входа в систему. Решающим фактором является то, что некоторые ваши приложения не поддерживают OIDC, а authentik решает эту проблему с помощью встроенной функции forward auth, не требуя дополнительных компонентов.

Выделите 4 GB оперативной памяти, если это возможно, и 2 GB только в том случае, если остальные приложения потребляют мало ресурсов. Не открывайте порт 9000 для доступа из публичного интернета и выполняйте TLS termination на reverse proxy перед ним. Делайте ежедневные дампы PostgreSQL и сохраняйте их вне сервера, так как провайдер идентификации без резервной копии является единой точкой отказа для всех защищаемых им приложений. Запускайте стек от имени выделенного непривилегированного пользователя, а не от root: в настройке пользователей с минимальными привилегиями на VPS описаны необходимые требования к учетной записи и правам доступа к файлам.

Выбирайте Keycloak, если все защищаемые приложения уже поддерживают OIDC или SAML, или если вам требуется детальная модель ролей, которую предоставляют realms в Keycloak. Выбирайте Zitadel, если вы разрабатываете приложение, в котором должны регистрироваться другие пользователи, и вам нужны его API и модель арендаторов (tenant model). Ни один из этих вариантов не подходит для сценария «три приложения на одном сервере», который рассматривается в этой статье.

Типичные сценарии сбоев

В Keycloak нет данных после перезапуска. Вы запустили его с помощью start-dev, который использует локальную базу данных для разработки. В контейнере без подключенного тома удаление контейнера приводит к удалению realm. Перейдите на start с использованием KC_DB=postgres, настроенного на реальную базу данных.

Контейнер worker в authentik исчезает на сервере с малым объемом ресурсов. Worker и server используют один и тот же образ и оба содержат процессы Python, а PostgreSQL требует свою долю памяти на хосте с 2 GB RAM. Выполните docker compose ps, чтобы подтвердить, какой именно сервис завершил работу, а затем проверьте dmesg на предмет принудительного завершения процесса из-за нехватки памяти (OOM kill), прежде чем искать ошибку в самом приложении.

Консоль Zitadel не работает за вашим прокси. API Zitadel использует gRPC, которому требуется HTTP/2 на всем пути до upstream-сервера. В документации указано требование к reverse proxy поддерживать HTTP/2 для upstream-соединений и перечислены протестированные версии: Traefik v3.x, NGINX v1.x, Caddy v2.x и Apache httpd 2.4.x. Если прокси понижает версию соединения до HTTP/1.1, страница входа загружается, но сама консоль перестает работать.

Каждое приложение возвращает вас на экран входа. Публичный URL сервера SSO и URL, настроенный в приложении, должны совпадать в точности, включая схему и порт. В Keycloak это называется настройкой hostname, в Zitadel — внешним доменом (external domain). При несовпадении приложение перенаправляет на страницу входа, которую сервер не распознает как свою, и браузер начинает бесконечно переключаться между ними.

FAQ

Что из этой тройки подойдет для VPS с 2 GB RAM?

authentik и Keycloak. authentik требует минимум 2 ядра CPU и 2 GB RAM, а руководство по Keycloak указывает базовое потребление памяти в 1250 MB для сервера без учета базы данных. Оба решения работают на пределе при 2 GB, если добавить к ним защищаемые приложения, поэтому 4 GB — это комфортный минимум. В руководстве по развертыванию Zitadel через compose также указаны 2 GB для домашней или полупромышленной среды, однако для полноценной эксплуатации рекомендуется 4 ядра CPU для хеширования паролей и 4 GB RAM на каждое ядро базы данных. Ожидайте нехватки ресурсов при появлении реального трафика авторизации.

Могут ли Keycloak или Zitadel защитить приложение, у которого нет собственной системы входа?

Сами по себе — нет. Ни один из них не содержит встроенного компонента forward auth. Старый прокси-компаньон для Keycloak, Louketo Proxy, прекратил поддержку в ноябре 2020 года, а его репозиторий на GitHub находится в архиве с декабря 2020 года, поэтому строить на нем инфраструктуру нельзя. Вам потребуется установить oauth2-proxy или аналогичный компонент между reverse proxy и приложением, направив его на OIDC-клиент на сервере SSO. authentik выполняет это нативно с помощью своего proxy provider в режиме "Forward auth (single application)" или "Forward auth (domain level)".

Кто из них может выступать в роли LDAP-сервера для приложения, которое поддерживает только LDAP?

authentik. Его LDAP-провайдер работает через outpost и позволяет искать пользователей и группы из authentik по протоколу LDAP, при этом LDAPS доступен на порту 636. Документация описывает только операции bind и search, поэтому рассматривайте этот функционал как доступный только для чтения. Keycloak и Zitadel работают в обратном направлении: оба могут считывать данные из существующего LDAP-каталога как из источника пользователей, но ни один из них не отвечает на LDAP bind со стороны приложения.

Можно ли пропускать версии при обновлении authentik?

Нет. Документация гласит, что обновления должны выполняться последовательно по мажорным версиям, и нельзя переходить с устаревшей мажорной версии сразу на самую актуальную. Сначала обновитесь до последнего патч-релиза внутри текущей версии, а затем переходите к следующей версии пошагово. Перед каждым этапом делайте резервную копию PostgreSQL, так как authentik не поддерживает откат версий, а миграции базы данных выполняются только в прямом направлении.