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, сервер и воркер.

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

Страница Zitadel для 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 находятся в составе опциональных профилей compose.

Таким образом, Keycloak и authentik помещаются на VPS с 4 ГБ RAM, оставляя место для защищаемых приложений. Zitadel запустится на 2 ГБ, но при каждом входе пользователя будет конкурировать за память с собственным экземпляром PostgreSQL. Я бы не стал запускать Zitadel на системе с менее чем 4 ГБ RAM, а на сервере, где также размещены другие приложения, я бы предпочел 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.7.1 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-аутпоста, при этом 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, а затем переведен в архив на GitHub; последний коммит датируется августом 2023 года. Чтобы защитить приложение без поддержки OIDC, перед ним запускают отдельный компонент, обычно oauth2-proxy, который направляют на клиент Keycloak. У Zitadel также нет собственного режима forward auth, поэтому решение то же самое: установка, мониторинг и обновление дополнительного компонента.

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

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

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

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

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

Zitadel разделяет фазы инициализации и настройки от работы самого сервера. Рекомендации по эксплуатации в production советуют держать их отдельно, чтобы масштабирование не приводило к повторному выполнению этапа настройки. На одном VPS это означает, что этап настройки должен завершиться до того, как API сообщит о своей готовности. Именно поэтому в файле 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-провайдером, а также позволяет создавать сценарии входа в визуальном редакторе. Он проигрывает, когда вам требуется контракт на поддержку от вендора или график релизов, который не меняется каждые несколько недель. Календарное версионирование без возможности отката и пропуска версий создает реальную операционную нагрузку, а редактор сценариев — это отдельная модель, которую нужно изучать, когда ваша реальная задача — настроить всего один OIDC-клиент.

Zitadel создан для разработчиков, внедряющих аутентификацию в свой продукт, с мощным API и поддержкой мультиарендности (multi-tenancy) как базовой функции. Он проигрывает именно в этом сценарии. Четыре контейнера, отсутствие 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 ОЗУ?

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

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

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

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

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

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

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