Keycloak, authentik чи Zitadel для одного VPS

Який SSO-сервер підходить для одного VPS

Keycloak, authentik і Zitadel — це self-hosted сервери єдиного входу (SSO), які зазвичай розглядають, коли потрібен один обліковий запис для всіх застосунків на сервері. На одному невеликому VPS це не взаємозамінні рішення. authentik — безпечний варіант за замовчуванням для сервера з трьома або чотирма self-hosted застосунками, оскільки лише він із цих трьох продуктів може показувати форму входу перед застосунком, який не має власної автентифікації. Keycloak підходить, коли кожен захищений застосунок уже підтримує стандартний протокол і на сервері достатньо пам’яті для Java virtual machine (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 GB оперативної пам’яті». Це 2048 MB, а опублікований compose-файл запускає 3 контейнери: PostgreSQL, server і worker.

Keycloak публікує найточніше значення з 3. У посібнику з розрахунку ресурсів зазначено: «базове використання пам’яті Pod, включно з кешами даних Realm і 10 000 кешованих сесій, становить 1250 MB оперативної пам’яті». Ці 1250 MB потрібні лише процесу Java, без урахування бази даних. На тій самій сторінці пояснюється, чому ліміт контейнера має таке значення: Keycloak використовує 70% ліміту пам’яті як heap і додатково потребує приблизно 300 MB non-heap пам’яті. Якщо надати контейнеру 1 GB, він розрахує heap приблизно на 717 MB, але все одно потребуватиме ще 300 MB non-heap пам’яті. Отже, ліміт буде вичерпано ще до потрапляння даних сесій у кеш.

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

Отже, Keycloak і authentik можна розмістити на VPS із 4 GB, залишивши ресурси для застосунків, які ви захищаєте. Zitadel запуститься на 2 GB, але під час кожного входу конкуруватиме за пам’ять із власним PostgreSQL. Я б не запускав Zitadel на сервері з менш ніж 4 GB, а якщо на цьому ж сервері розміщено інші застосунки, то орієнтувався б на 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 за замовчуванням. Перш ніж цей порт стане доступним з інтернету, розмістіть перед ним reverse proxy зі справжнім сертифікатом.

Keycloak — це один процес і база даних, яку ви надаєте самостійно. У quickstart використовується один контейнер.

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. У production guide 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 пояснюють вибір volume і restart policy, від якого залежить, чи переживе ваш identity provider перезавантаження.

Які протоколи підтримує кожна з них?

Усі три підтримують 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 provider робить «усіх користувачів і групи в базі даних authentik доступними для пошуку через LDAP directory» за допомогою виділеного LDAP outpost; LDAPS доступний на порту 636. Режим доступу лише для читання: bind і пошук працюють, а операції запису — ні. Одноразовий код додається до пароля через крапку з комою, як у 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)" захищає всі застосунки в одному батьківському домені за допомогою одного provider. Рівень домену зручніший, але має задокументоване обмеження: він "не може застосовувати різні правила авторизації на рівні застосунків для кожного захищеного застосунку", тому всі застосунки в цьому домені використовують один набір політик.

У Keycloak цього немає. Його супутній проксі Keycloak Gatekeeper перейменували на Louketo Proxy, а потім заархівували на GitHub; останній коміт датовано August 2023. Щоб захистити застосунок без підтримки OIDC, потрібно запустити перед ним окремий компонент, зазвичай oauth2-proxy, налаштований на клієнт Keycloak. У Zitadel також немає власного режиму forward auth, тому потрібен такий самий додатковий компонент, який слід встановити, моніторити й оновлювати.

Саме на цьому додатковому переході конфігурація reverse proxy перестає бути простою. Перш ніж підключати до нього middleware автентифікації, прочитайте як Traefik проксуює кілька застосунків Docker Compose.

Наскільки складний процес оновлення?

Станом на серпень 2026 року актуальні версії: Keycloak 26.7.1, authentik 2026.5.6 і Zitadel v4.16.3. Усі три продукти виконують міграції схеми в PostgreSQL, тобто кожне оновлення змінює базу даних. Перед кожним оновленням створюйте резервну копію бази даних. Ця звичка важливіша за будь-яку функцію в цьому порівнянні.

authentik має найсуворіше правило і чітко його формулює: «Оновлення потрібно виконувати послідовно між основними версіями; не можна переходити безпосередньо зі старішої основної версії на найновішу». Перед переходом до наступної версії потрібно встановити найновіший patch-реліз поточної версії, а «authentik не підтримує пониження версії». Якщо проєкт із календарною нумерацією версій відстає на рік, одне оновлення перетворюється на послідовність оновлень, кожне з окремою міграцією бази даних.

У посібнику з оновлення Keycloak зазначено порядок дій: переглянути зміни міграції з попередньої версії, оновити сервер, а потім оновити адаптери. Міграція бази даних виконується автоматично. Також її можна експортувати й застосувати вручну, що зручно, якщо потрібно переглянути зміни до їх застосування. У Keycloak основні витрати пов’язані саме з таким переглядом. У нотатках до релізів є застарілі функції та зміни поведінки, які легко пропустити, але помилки через це можуть дорого коштувати.

Zitadel відокремлює фази init і setup від запущеного сервера. У рекомендаціях для production радять зберігати їх окремо, щоб масштабування не повторювало операції налаштування. На одному VPS це здебільшого означає, що етап setup має завершитися до того, як API повідомить про готовність. Саме тому compose-файл містить health checks, а команда запуску використовує --wait.

Для кого призначений кожен проєкт і де кожен із них має обмеження

Keycloak — сервер ідентифікації Red Hat, розрахований на організації з realms, groups, role mappings і наявним корпоративним каталогом. Це найповніша реалізація стандартів серед трьох рішень. Він втрачає переваги на VPS із 2 GB RAM, де працюють чотири self-hosted застосунки, половина з яких не підтримує OIDC. JVM споживає 1250 MB, вам доводиться вивчати модель realm, розроблену для компанії, а для застосунків, які вам фактично потрібні, усе одно доводиться встановлювати oauth2-proxy.

authentik створений для self-hosting, і це видно з переліку функцій. Він підтримує forward auth і надає LDAP provider, а login flows можна створювати у візуальному редакторі. Він втрачає переваги, коли потрібні контрактна підтримка від постачальника або release train зі стабільнішим циклом випусків. Calendar versioning без можливості downgrade і пропуску версій створює реальне операційне навантаження, а редактор flow — це окрема модель, яку потрібно вивчати, якщо фактична проблема полягає лише в одному OIDC client.

Zitadel призначений для розробників, які вбудовують автентифікацію у власний продукт, що постачається користувачам, і потребують потужного API та multi-tenancy як базових функцій. Саме в цьому сценарії він і має обмеження. Чотири контейнери, відсутність forward auth і база даних, розрахована на 4 GB на core, — невідповідна конфігурація для одного VPS, за яким працюють password manager і wiki.

Що я б запускав на одному VPS і як

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

Якщо можливо, виділіть для нього 4 GB, а 2 GB — лише якщо інші застосунки невеликі. Не відкривайте порт 9000 для публічного інтернету та завершуйте TLS на reverse proxy перед ним. Щоночі створюйте дампи PostgreSQL і зберігайте їх за межами цього сервера, оскільки identity provider без резервної копії є єдиною точкою відмови для кожного застосунку за ним. Запускайте стек від імені окремого непривілейованого облікового запису, а не root: у матеріалі налаштування користувачів із мінімальними привілеями на VPS описано потрібні обліковий запис і права власника файлів.

Вибирайте Keycloak, якщо всі застосунки, які ви захищаєте, уже підтримують OIDC або SAML, або якщо вам потрібна детальна модель ролей, яку надають realms у Keycloak. Вибирайте Zitadel, якщо ви створюєте застосунок, у якому реєструватимуться інші користувачі, і вам потрібні його API та модель tenant. Жоден із цих варіантів не призначений для сценарію з трьома застосунками на одному сервері, про який ідеться в цій статті.

Перші типові причини збоїв

У Keycloak немає даних після перезапуску. Ви запустили його з start-dev, який використовує локальну базу даних для розробки. У контейнері без volume видалення контейнера видаляє realm. Перейдіть на start, указавши в KC_DB=postgres справжню базу даних.

Контейнер worker authentik зникає на малопотужному сервері. Worker і server використовують один і той самий image та запускають процеси Python, а PostgreSQL також потребує частину ресурсів хоста з 2 GB пам’яті. Виконайте docker compose ps, щоб перевірити, який сервіс завершив роботу, а потім перегляньте dmesg на наявність завершення через нестачу пам’яті, перш ніж шукати помилку в застосунку.

Console Zitadel не працює за вашим reverse proxy. API Zitadel використовує gRPC, якому потрібен HTTP/2 на всьому шляху до upstream. На сторінці вимог зазначено, що reverse proxy має підтримувати upstream-з’єднання HTTP/2; там також наведено протестовані версії Traefik v3.x, NGINX v1.x, Caddy v2.x і Apache httpd 2.4.x. Якщо proxy знижує версію upstream-з’єднання до HTTP/1.1, сторінка входу завантажується, але Console не працює.

Кожен застосунок повертає вас на сторінку входу. Публічний URL SSO-сервера та URL, налаштований у застосунку, мають точно збігатися, включно зі схемою та портом. У Keycloak це називається параметром hostname, а в Zitadel — external domain. Якщо значення не збігаються, застосунок перенаправляє на сторінку входу, яку сервер не розпізнає як власну, і браузер переходить між ними по колу.

FAQ

Який із трьох варіантів підходить для VPS із 2 GB RAM?

authentik і Keycloak. Заявлена вимога authentik — хост щонайменше з 2 ядрами CPU і 2 GB RAM, а в посібнику з вибору розміру Keycloak базове споживання пам’яті сервера без бази даних становить 1250 MB. На VPS із 2 GB RAM обидва варіанти матимуть дуже мало вільних ресурсів після додавання застосунків, які потрібно захищати, тому комфортним мінімумом вважайте 4 GB RAM. Zitadel вказує 2 GB RAM для першого запуску, але в рекомендаціях для production вимагає 4 ядра CPU для хешування паролів і 4 GB RAM на ядро бази даних. Тому 2 GB RAM — не реальний варіант для розгортання.

Чи можуть Keycloak або Zitadel захистити застосунок, у якому немає власної автентифікації?

Не самостійно. Жоден із них не постачається з компонентом forward auth. Старий супутній proxy для Keycloak, Louketo Proxy, заархівований на GitHub; його останній коміт датовано August 2023, тому не варто будувати рішення на його основі. Розмістіть oauth2-proxy або подібний компонент між reverse proxy і застосунком та вкажіть у ньому OIDC-клієнт на SSO-сервері. authentik підтримує це нативно через proxy provider у режимі "Forward auth (single application)" або "Forward auth (domain level)".

Який із них може працювати як LDAP-сервер для застосунку, що підтримує лише LDAP?

authentik. Його LDAP provider працює на outpost і робить користувачів та групи в authentik доступними для пошуку через LDAP; LDAPS доступний на port 636. Це режим лише для читання: bind і search працюють, а операції запису — ні. Keycloak і Zitadel працюють у протилежному напрямку: обидва читають дані з наявного LDAP-каталогу як із джерела користувачів, але жоден не відповідає на LDAP bind від застосунку.

Чи можна пропускати версії під час оновлення authentik?

Ні. У документації зазначено, що оновлення потрібно виконувати послідовно за major release і не переходити безпосередньо зі старої major version на найновішу. Спочатку встановіть останній patch release у межах поточної версії, а потім переходьте на наступну версію по одній. Перед кожним кроком створюйте резервну копію PostgreSQL, оскільки authentik не підтримує downgrade, а міграції виконуються лише в напрямку оновлення.