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 МБ оперативной памяти». Эти 1250 МБ предназначены для сервера Keycloak с учетом указанных кэшей. Руководство рассматривает базу данных отдельно, поэтому PostgreSQL требует дополнительной памяти сверх этого объема. На той же странице объясняется, почему лимит контейнера так важен: Keycloak использует 70% лимита памяти под heap и примерно 300 МБ не-heap памяти сверху. В приведенном примере базовые 1250 МБ превращаются в лимит памяти 1360 МБ. Если выделить контейнеру 1 ГБ, он вычислит heap размером около 717 МБ, а с учетом примерно 300 МБ не-heap памяти итоговое значение составит около 1017 МБ. Это не оставляет запаса под лимитом, в то время как базовая цифра из руководства с учетом кэшей realm и 10 000 сессий составляет 1250 МБ.

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

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

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

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

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 по умолчанию. Установите перед этим портом обратный прокси с настоящим сертификатом, прежде чем открывать доступ к нему из Интернета.

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 (transport layer security), поэтому контейнер, запущенный таким образом и впоследствии удаленный, унесет с собой все ваши данные (realm). Для промышленной эксплуатации используйте start, настоящий PostgreSQL через KC_DB и публичное доменное имя через 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

Установите 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-сервер в качестве identity provider в ZITADEL».

Обслуживание LDAP означает, что приложение, работающее только по протоколу LDAP, может выполнять bind к вашему SSO-серверу, как если бы он был каталогом. Это умеет только authentik. Его LDAP-провайдер позволяет «делать всех пользователей и группы в базе данных authentik доступными для поиска через LDAP-каталог» с помощью выделенного LDAP-аутпоста, при этом LDAPS доступен на порту 636. По умолчанию пользователь может искать только свои данные и группы, поэтому сервисная учетная запись, через которую приложение выполняет bind, должна иметь разрешение «Search full LDAP directory» для просмотра всех объектов. Документация описывает только операции 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 для аутентификации.

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

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

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

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

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

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

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

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