Лучшая 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 в продакшене означает, что его аптайм теперь ваша забота. Мы под такие нагрузки используем инстансы Linux VPS от Cloudzy для такого типа нагрузки, с 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, зафиксируйте эти ограничения экспорта и миграции до выбора управляемого провайдера.