Найкраща self-hosted CIAM-платформа для творців B2B SaaS

Якщо ви дивилися ціни на деякі SaaS-платформи CIAM, то напевно помітили, наскільки дорогими вони стають, і, найімовірніше, замислювалися про self-hosted-варіант.

Ця стаття про чотири self-hosted CIAM-платформи, які невелика команда B2B SaaS справді може обслуговувати, не перетворюючи це на другу повну зайнятість: ZITADEL, FusionAuth, Logto та Ory Hydra. Вони влаштовані по-різному, і та, що підійде саме вам, залежить не так від переліку функцій, як від того, який B2B-продукт ви будуєте. Я тиждень ганяв їх поруч на одному VPS, щоб зібрати це порівняння, і далі йде та версія, яку я надіслав би засновнику, що написав мені в особисті про CIAM.

Одразу застереження: мова про CIAM як функцію продукту, а не про внутрішній SSO для вашої команди.

Коротко

Чотири self-hosted CIAM-платформи, по одному рядку на кожну:

• ZITADEL якщо вам потрібні мультиорендність і B2B-організації з коробки.
• FusionAuth якщо вам потрібні відточений адмін-інтерфейс і довга передбачувана історія релізів.
• Logto якщо вам потрібен найчистіший досвід розробника з першого ж дня.
• Ory Hydra якщо ви працюєте на рівні протоколу й хочете рушій OAuth 2.0, а не готовий застосунок входу.

Підсумок: ZITADEL — найбезпечніша перша ставка для типового B2B SaaS, а решта статті розбирає це обґрунтування.

Чому CIAM — це не те саме рішення, що корпоративний SSO

Якщо падає SSO для внутрішньої команди, збитки зазвичай обмежені. Ваші інженери на годину втрачають доступ до Grafana чи іншого внутрішнього інструмента. Якщо падає CIAM, платні клієнти взагалі не можуть увійти в продукт. Це змінює питання з «який інструмент автентифікації зручний нашій команді?» на «якій системі автентифікації ми можемо довірити частину самого продукту?»

CIAM, тобто та інфраструктура ідентичності, яка потрібна B2B SaaS, вимагає ще й примітивів, на яких багато інструментів корпоративного SSO не роблять акценту. Ваш клієнт — не окремий користувач, а організація (тенант) зі своїми користувачами, ролями, брендингом і, можливо, власним SAML-підключенням до корпоративного IdP. Ви не просто автентифікуєте людей: ви ізолюєте користувачів однієї компанії від користувачів іншої всередині одного продукту. Саме на цю B2B-форму націлені чотири інструменти нижче, кожен по-своєму. У Keycloak тепер є повноцінні Organizations, тож відмахуватися від нього як від інструмента лише для співробітників уже застаріло; чому його немає в списку, пояснюю у FAQ.

Трикутник «побудувати / купити / хостити самому» тут теж виглядає інакше. Писати OAuth з нуля — помилка на рівному місці. Ви випускаєте SaaS-продукт, а не провайдера ідентичності. Купити керований сервіс (Auth0, Clerk, WorkOS) — правильний вибір, коли в команди нульова ops-місткість і осудний бюджет. Стартапу з двох людей я б ніколи не радив хостити автентифікацію самому в перший же день. Self-hosting стає раціональним, коли ціна керованого CIAM за MAU перевищує вартість інфраструктури плюс постійний інженерний час, або коли потрібен прямий контроль над розгортанням і площиною даних. У командах, з якими я працював, цей момент зазвичай настає десь між «у нас є справжній продукт» і «у нас є справжня функція customer success».

Якщо вам потрібен SSO для власних застосунків, а не для застосунків ваших клієнтів, це вже інше порівняння. Переходимо до наших фаворитів.

Чотири інструменти по черзі

Я обрав саме ці чотири, бо вони достатньо CIAM-подібні, щоб оцінювати їх як продуктову інфраструктуру, а не лише як внутрішній SSO. ZITADEL, FusionAuth, Logto та Ory дають справжній шлях self-hosting і достатню популярність, щоб розглядати їх серйозно. Варіанти рівня бібліотеки, рішення для корпоративного SSO та менш зрілі продукти доречніше розібрати у FAQ.

ZITADEL

ZITADEL — швейцарська identity-платформа на Go з event-sourced-архітектурою та бекендом на PostgreSQL. Станом на 27 липня 2026 року її останній реліз на GitHub — the 4.16 series, current as of July 2026. Починаючи з v3 ZITADEL перейшов з Apache 2.0 на AGPL-3.0; за звичайного SaaS-використання практичний ефект зазвичай менш страшний, ніж звучить, і подробиці я розбираю у FAQ.

Чим ZITADEL вирізняється для B2B SaaS: організації та мультиорендність — примітиви першого класу, а не функції, які ви збираєте з універсальних об'єктів. Ви створюєте Organization, вона отримує власних користувачів, політики, брендинг і налаштування доступу, а ви можете надати їй проєкти, щоб її адміністратори самі керували призначенням ролей своїм користувачам. Вам не треба вигадувати поняття «тенант» поверх звичайних користувачів. Ви починаєте вже з ним.

Досвід розробника API-first: актуальні REST-ресурсні API v2 плюс gRPC- і REST-доступ до застарілих сервісів v1. Офіційні та community-SDK покривають поширені серверні стеки. Адмін-консоль робоча, але простіша, ніж у FusionAuth.

Моя думка: Якщо ви будуєте B2B SaaS і знаєте, що у вас будуть тенанти, я б почав із ZITADEL. Серед self-hosted-варіантів це той, що найвиразніше вибудуваний навколо задачі B2B-логіну.

FusionAuth

FusionAuth — американська платформа від Inversoft, LLC (LLC із Делаверу, що працює під маркою FusionAuth), яка на ринку довше за решту трьох, і це помітно в хорошому сенсі. Адмін-інтерфейс відчувається помітно продуманішим, документація зріла, а ритм релізів рівний, а не гарячковий. Якщо вам колись діставалася чотирирічна інтеграція автентифікації і ви мовчки дякували попередньому інженеру за те, що він обрав нудний варіант, FusionAuth — та версія CIAM, яка цю подяку заслуговує.

Спотикаються зазвичай на ліцензуванні: FusionAuth Community можна хостити в себе безкоштовно, але ядро продукту не є відкритим вихідним кодом. Продукт регулюється власною ліцензією FusionAuth, і ці обмеження важливі, якщо ви плануєте розповсюджувати, вбудовувати, ребрендувати, перепродавати або хостити FusionAuth для власних клієнтів. Self-hosted Community покриває базовий сценарій B2B SaaS; платні плани додають функції такі як SAML, ініційований з боку IdP, просунута MFA та теми для конкретних застосунків, тоді як SCIM, Tenant Manager і політики MFA на рівні застосунку є в Enterprise.

Про B2B-форму: FusionAuth моделює тенанти й застосунки, але абстракція — це радше «контейнеризована автентифікація на тенанта», ніж «B2B-організації як доменний об'єкт». Це працює (я випускав на ньому продукти), але мультиорендність відчувається радше примітивом ізоляції, ніж повноцінною B2B-моделлю. Офіційні SDK та клієнтські бібліотеки широкі:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

Серверні бібліотеки — це тонкі API-клієнти. Адмін-консоль порівняно легше передати не-інженеру з експлуатації, ніж в інших.

Моя думка: Якщо ваша команда цінує відточений інтерфейс і довгу передбачувану історію вище за нативні B2B-примітиви — беріть FusionAuth. Це найбільш «нудний» варіант тут, і це комплімент.

Logto

Logto — наймолодший із чотирьох, розробляється Silverhand Inc. і поширюється за ліцензією MPL-2.0, і це той, кому дашборд явно небайдужий. Запуск у перший день порівняно швидкий. Ви розгортаєте, проходите майстер і приблизно за п'ятнадцять хвилин отримуєте робочий OIDC-провайдер із пристойним типовим екраном входу (я засікав того тижня, коли ганяв усі чотири поруч). Офіційні quick start'и покривають сучасні фреймворки та серверні стеки, тож якщо ваш стек — «Next.js + Postgres + щось», ви почуватиметеся як удома.

Його відповідь на B2B називається Logto Organizations. Він покриває базові B2B-примітиви: членство в організації, ролі в межах організації, запрошення учасників, just-in-time-провізіювання та інтеграцію корпоративного SSO. Модель організації молодша, ніж у ZITADEL, тож будь-який нестандартний SAML-, SCIM- чи федеративний потік я б протестував на ваших цільових клієнтах, перш ніж брати зобов'язання.

Компроміс — зрілість: Logto тут наймолодший варіант. Дорожня карта рухається швидко, і це чудово, коли прилітає потрібна вам функція, і неприємно, коли прилітає ламка зміна. Якщо ваш B2B SaaS перебуває на простому кінці спектра мультиорендності (невеликий набір організацій і жодних екзотичних вимог до федерації), досвід розробника в Logto робить решту рішення простішою.

Моя думка: Якщо вам потрібен найшвидший перший день, а B2B-вимоги поки порівняно прості — Logto.

Ory Hydra (і стек Ory)

Ory Hydra — це OAuth 2.0 / OpenID Connect сервер з екосистеми Ory, поширюється за ліцензією Apache-2.0. Повний стек Ory доповнює Hydra компонентами Ory Kratos (ідентичність і керування користувачами, самообслуговуваний вхід, реєстрація, MFA та відновлення акаунта), Ory Keto (сервер авторизації в стилі Zanzibar, що виступає точкою ухвалення рішень щодо політик) та Ory Oathkeeper (проксі ідентичності й доступу, який автентифікує, авторизує та модифікує вхідні HTTP-запити). Ви збираєте те, що потрібно. Усе написано на Go, і API чисті.

Заковика (і це не недолік; для відповідної команди це плюс) у тому, що Hydra — це рушій, а не застосунок. За задумом Hydra підключається до окремого застосунку логіну та згоди , який надаєте ви. Якщо вам потрібен готовий екран входу, це не той інструмент. Якщо ви будуєте щось, де потік автентифікації — частина продукту (платформа для розробників, кастомний B2B-портал чи API-first-продукт із власним онбордингом), то відсутність нав'язаного UI — саме те, що треба.

B2B-історія тут композиційна, а не «під ключ». Мультиорендність можна змоделювати, підв'язавши схеми Kratos і відношення Keto до вашого власного шару організацій, і це працює, але проводку прокладаєте ви. Ціна — більше сантехніки, вигода — контроль над досвідом. Документація Ory глибоко покриває поверхню протоколу, але композиційна модель припускає, що ви готові самі ухвалювати рішення на рівні протоколу. Якщо «audience claim» чи «PKCE» вам нічого не кажуть, почніть з одного з трьох інших.

Моя думка: Якщо ви будуєте щось на рівні протоколу (auth-шлюз, кастомні потоки, платформа для розробників) і стандартні застосунки здаються тісними, Ory — правильна відповідь. Для типового B2B SaaS, якому потрібен робочий вхід уже сьогодні, — ні.

Порівняння з першого погляду

Ось зведення по чотирьох інструментах в одній таблиці: корисне для другого проходу, але не замінює профілі вище.

З якого почати?

Чотири короткі сценарії, що покривають більшість команд, з якими я б це обговорював.

Ви будуєте B2B SaaS і знаєте, що у вас будуть тенанти. Почніть із ZITADEL. Примітиви мультиорендності та організацій зроблені саме під це, поверхня API вичерпна, і на винайдення моделі тенанта ви витратите менше часу, ніж із будь-яким із трьох інших. Перехід на AGPL заслуговує юридичної перевірки, але немодифіковане, окремо інтегроване розгортання зазвичай є простим SaaS-сценарієм.

Вам потрібен відточений адмін-інтерфейс і стабільна передбачувана платформа. FusionAuth. План Community закриває базові потреби багатьох команд; закладіть час на уважне читання ліцензії та матриці функцій. Такі можливості, як SAML, ініційований з боку IdP, просунута MFA та теми для конкретних застосунків, потребують платного плану, а SCIM, Tenant Manager і політики MFA на рівні застосунку є в Enterprise.

Ваші B2B-потреби сьогодні прості, і вам потрібен найшвидший перший день. Logto. Його досвід розробника в перший день виявився найшвидшим у моєму паралельному тесті. Прийміть, що ви ставите на молодшу екосистему, і перегляньте вибір, якщо вимоги доростуть до межових випадків федерації, яких ви не перевіряли.

Ви будуєте щось, де потоки автентифікації — частина продуктового досвіду. Ory Hydra (плюс Kratos, плюс Keto, якщо потрібні дозволи). Ви напишете більше коду. У вас буде більше контролю. Якщо цей обмін вам не очевидний, ви не аудиторія Ory. Оберіть один із трьох інших.

Якщо два з цих описів про вас, за замовчуванням беріть ZITADEL. Він підходить найширше, і саме його я б дав невеликій команді засновників, не ставлячи багато додаткових питань.

У що вам обходиться self-hosting (операційно)

А тепер неромантична частина статті.

Ваша дисципліна резервного копіювання PostgreSQL тепер те, від чого залежить бізнес. У цих розгортаннях стан ідентичності, який треба захищати, може включати записи користувачів, хешовані облікові дані, секрети MFA, облікові дані OAuth-клієнтів і дані сесій. Втратите цей стан — і ваші клієнти можуть позбутися можливості входити. Налаштуйте автоматичні бекапи до того, як зареєструється перший справжній користувач, протестуйте відновлення й виведіть здоров'я бекапів у той самий канал алертів, що й аптайм застосунку.

Темп релізів із часом змінюється. ZITADEL v4.16.1 вийшов 17 липня 2026 року після кількох червневих релізів, при цьому кожен проєкт тут тримає власну каденцію та політику сумісності. Ставтеся до цієї каденції як до питання супроводу, а не як до швидкого мірила якості. Читайте release notes перед тим, як запускати docker compose pull, і заплануйте регулярне вікно для патчів. Пропуск оновлень провайдера ідентичності на місяці здатен залишити вас позаду виправлень безпеки та сумісності на першій же серйозній перевірці.

Буденні речі, які завжди підкрадаються: оновлення TLS-сертифікатів (використовуйте зворотний проксі з Let's Encrypt, автоматизуйте продовження й налаштуйте алерти на збої), конфігурація вихідної пошти для листів підтвердження та скидання пароля (SES, SendGrid, Postmark: оберіть один і як слід налаштуйте SPF/DKIM/DMARC, інакше листи скидання полетять у спам), ротація облікових даних OAuth-клієнтів, коли йде інженер, і обмеження частоти запитів на ендпоінтах входу, щоб атака credential stuffing не поклала ваш CPU.

Порада: якщо ви використовуєте managed Postgres, не вважайте, що рантайм-користувач БД може ще й створити схему. Створіть базу й користувача заздалегідь, видайте потрібні права власності або встановлення й запустіть первинне налаштування тими обліковими даними, яких очікує конкретний інструмент. Інакше перший запуск упаде на невиразній помилці прав доступу до бази, і ви спалите годину, ганяючись не за тим.

Що шлях self-hosting заощаджує в доларах, те він забирає у власності. Після налаштування закладіть кілька інженерних годин на місяць на підтримання шару ідентичності у здоровому стані. Команди, які виділяють нуль часу, зазвичай виявляють цю ціну пізніше: під час збою, на дивному межовому випадку SAML або на першій перевірці безпеки.

Де їх розгортати

Linux-VPS із Docker Compose може бути розумною відправною точкою для оцінювання та помірних навантажень, але продакшн-сайзинг і висока доступність залежать від трафіку, вимог безпеки та вашої терпимості до простоїв. Ось як розташовуються типові варіанти розгортання:

• Спільний хостинг не потягне жоден із них. Їм потрібні постійне сховище, власні порти, root-доступ для контейнерного рантайму та справжній бекенд бази даних. PostgreSQL — шлях за замовчуванням для більшості з цього списку, але це буквально не єдина підтримувана база для кожного інструмента.
• Kubernetes потягне всі чотири, але офіційний шлях нерівний. ZITADEL, FusionAuth, і Ory публікують власні Helm-чарти, тоді як документація Logto щодо self-hosting зосереджена на розгортанні через Docker і віртуальні машини. Для невеликого B2B SaaS, який ще не доріс до точки, де Kubernetes окупається в інших місцях, це зазвичай оверінжиніринг. Беріться за нього, коли там уже живе решта вашої інфраструктури.
• Bare metal підійде, якщо ви вже на ньому. Більшість B2B SaaS-команд — ні.

Для невеликого одновузлового пілота я б почав із 4 GB RAM, 2 vCPU та 60 GB NVMe-сховища, а потім навантажив тестами реальний потік входу. Це база для планування, а не універсальний продакшн-мінімум. Застосунки порівняно легкі, але PostgreSQL потрібна пам'ять, а хешуванню паролів — запас CPU. Рекомендації ZITADEL для продакшену радять тримати доступними чотири ядра CPU для піків хешування паролів.

Коли продукт стане реальним, а трафік сталим, переглядайте розміри за вимірами. Швидке сховище допомагає латентності PostgreSQL, а запас CPU важливий за одночасного хешування паролів. Стежте за пам'яттю, дисковим I/O бази, латентністю входу та завантаженням CPU, замість того щоб вважати, ніби один ресурс важливіший за всі.

Запуск CIAM у продакшені означає, що його аптайм тепер ваш клопіт. Ми під такі навантаження використовуємо інстанси Cloudzy Linux VPS для такого типу навантаження, зі сховищем NVMe та SLA доступності 99,95 % на базовій платформі. Cloudzy також пропонує ZITADEL VPS в один клік якщо волієте обійтися без початкового скрипта провізіювання; решта три надають офіційні образи контейнерів для встановлення на Docker. Управлінський погляд на те, як контроль доступу вбудовується в решту вашої безпеки, дає посібник із найкращих практик IAM розбір з погляду політик.

Часті запитання

Чи впливає ліцензія AGPL у ZITADEL на мій SaaS?

Зазвичай ні — для немодифікованого, окремо інтегрованого розгортання, але це не юридична консультація. Зобов'язання AGPL у ZITADEL стосуються самого ZITADEL. Якщо ви модифікуєте ZITADEL і експлуатуєте цю модифіковану версію як мережевий сервіс, ліцензія може вимагати надати відповідний вихідний код під AGPL. Опублікована позиція ZITADEL: просте використання немодифікованого інстансу як identity-сервісу вашого SaaS саме по собі не зобов'язує ліцензувати ваш окремий застосунок під AGPL. Прочитайте оголошення ZITADEL про ліцензування і отримайте юридичну консультацію, якщо ви модифікуєте, розповсюджуєте, вбудовуєте або пропонуєте ПЗ третім особам. Комерційна ліцензія теж доступна.

Чому Keycloak чи Authentik немає в цьому списку?

Keycloak та Authentik — чудові self-hosted інструменти ідентичності (я ними користуюся), але виключати Keycloak на тій підставі, що в ньому немає B2B-організацій, сьогодні було б помилкою: поточні релізи Keycloak містять Organizations, групи організацій і засоби делегованого адміністрування. Я лишив його за дужками, бо це порівняння зосереджене на чотирьох варіантах із прямішим шляхом для невеликої команди B2B SaaS; Keycloak заслуговує окремої оцінки, коли важливі експлуатація JVM, глибина екосистеми та гнучкість на рівні realm. Authentik і далі краще пасує до корпоративного SSO і внутрішніх застосунків, ніж до продуктового моделювання тенантів.

Чи дешевший self-hosting, ніж Auth0?

За низьких MAU часто ні. Ваші інженерні години коштують дорожче за рахунок Auth0 на рівні раннього стартапу. Self-hosting виграє економічно на масштабі, де ціна керованого CIAM за MAU перевищує сумарну вартість невеликого VPS плюс ті кілька інженерних годин на місяць, які ви на нього витратите. Точна точка беззбитковості залежить від погодинної вартості вашої команди, кривої зростання MAU і того, чи потрібні продукту корпоративні функції, що виштовхують вас у дорожчі тарифи Auth0. Вважайте економію реальною, але не миттєвою.

Який мінімальний розмір VPS для продакшн-CIAM?

Для невеликого одновузлового пілота 4 GB RAM, 2 vCPU та NVMe-сховище — розумна відправна точка, а не гарантія для продакшену. Рахуйте розмір від обсягу бази, навантаження одночасних входів, вартості хешування паролів і цілі щодо аптайму. Власні рекомендації ZITADEL для продакшену радять тримати доступними чотири ядра CPU для піків хешування; іншим інструментам і профілям трафіку потрібні власні навантажувальні тести.

Чи зможу я пізніше мігрувати з керованого CIAM на self-hosted?

Так, але плануйте це як повноцінний проєкт. Скидання паролів не є неминучим: експортованість і підтримувані формати хешів різняться, а деякі цільові системи підтримують масову або just-in-time міграцію користувачів , тоді як інші вимагають скидання. MFA-фактори, OAuth-клієнти, активні сесії, стан підтвердження email і зіставлення тенантів чи ролей потребують окремого опрацювання. Якщо ви вже підозрюєте, що згодом перейдете на self-hosting, зафіксуйте ці обмеження експорту та міграції до вибору керованого провайдера.