Best Self-Hosted CIAM for B2B SaaS Builders

If you have looked at the pricing for some of the SaaS CIAM platforms, you have probably noticed how expensive they tend to get and have most likely considered going for a self-hosted one.

This article is about the four self-hosted CIAM platforms a small B2B SaaS team can actually run without it becoming a second full-time job: ZITADEL, FusionAuth, Logto, and Ory Hydra. They are not all the same shape, and the right one for you depends less on a feature checklist and more on the kind of B2B product you're building. I ran them side by side on a single VPS for a week to put together this comparison, and what follows is the version I'd send to a founder DM-ing me about CIAM.

One thing up front: this is about CIAM as a product feature, not internal SSO for your own team.

The Short Version

Four self-hosted CIAM platforms, one line each:

• ZITADEL if you want multi-tenancy and B2B organizations out of the box.
• FusionAuth if you want a polished admin UI and a long, predictable release history.
• Logto if you want the cleanest first-day developer experience.
• Ory Hydra if you're a protocol-level builder who wants the OAuth 2.0 engine, not an opinionated login app.

Bottom line: ZITADEL is the safest first bet for a typical B2B SaaS, and the rest of the article is where that reasoning gets unpacked.

Why CIAM Is a Different Decision Than Workforce SSO

If SSO for your internal team goes down, the damage is usually contained. Your engineers might lose access to Grafana or another internal tool for an hour. If CIAM goes down, your paying customers cannot log in to the product at all. That changes the decision from "which auth tool is convenient for our team?" to "which auth system can we trust as part of the product itself?"

CIAM, the kind of identity infrastructure a B2B SaaS needs, also needs primitives that many workforce SSO tools do not emphasize. Your customer is not a single user; it is an organization (a tenant) with its own users, roles, branding, and possibly its own SAML connection to a corporate IdP. You are not just authenticating people; you are isolating one company's users from another company's users inside the same product. This is the B2B shape the four tools below target in different ways. Keycloak now has first-class Organizations, so dismissing it as workforce-only would be outdated; I explain its omission in the FAQ.

The build-vs-buy-vs-self-host triangle also looks different here. Building OAuth from scratch is an unforced error. You're shipping a SaaS product, not an identity provider. Buying managed (Auth0, Clerk, WorkOS) is the right call when your team has zero ops bandwidth and a sane budget. I'd never tell a two-person startup to self-host auth on day one. Self-hosting becomes rational when managed CIAM's per-MAU pricing crosses the cost of infrastructure plus ongoing engineering time, or when you need direct control of the deployment and data plane. In the teams I've worked with, that point usually hits somewhere between "we have a real product" and "we have a real customer success function."

If you're looking for SSO for your own apps rather than your customers', that is a different comparison from this one. Moving on to our top picks.

The Four Tools, One by One

I picked these four because they are CIAM-shaped enough to evaluate as product infrastructure, not just internal SSO. ZITADEL, FusionAuth, Logto, and Ory all give you a real self-hosted path and enough traction to consider seriously. The library-only, workforce-SSO, and less mature options are better handled in the FAQ.

ZITADEL

ZITADEL is a Swiss-built identity platform written in Go, with an event-sourced architecture and a PostgreSQL backend. As of July 27, 2026, its latest GitHub release is the 4.16 series, current as of July 2026. ZITADEL moved from Apache 2.0 to AGPL-3.0 starting with v3; for normal SaaS use, the practical impact is usually less scary than it sounds, and I cover the details in the FAQ.

What sets ZITADEL apart for B2B SaaS: organizations and multi-tenancy are first-class primitives, not features you compose out of generic objects. You create an Organization, it gets its own users, policies, branding, and access settings, and you can grant projects to that organization so its admins manage role assignments for their own users. You don't have to invent the concept of "tenant" on top of generic users. You start with it.

The developer experience is API-first, with current v2 REST resource APIs plus gRPC and REST access to legacy v1 services. Official and community SDKs cover the common server stacks. The admin console is functional but plainer than FusionAuth's.

My read: If you're building a B2B SaaS and you know you'll have tenants, ZITADEL is where I'd start. Among the self-hosted options, it's the one most explicitly shaped around the B2B login problem.

FusionAuth

FusionAuth is a US-based platform from Inversoft, LLC (a Delaware LLC, dba FusionAuth) that's been around longer than the other three and shows it, in a good way. The admin UI feels notably more designed than the others, the documentation is mature, and the release cadence is steady rather than breakneck. If you've ever inherited a four-year-old auth integration and silently thanked the previous engineer for picking the boring option, FusionAuth is the version of CIAM that earns that thanks.

The licensing is the thing that trips people up: FusionAuth Community is free to self-host, but the core product is not open source. The product is governed by FusionAuth's own license, and the limits matter if you plan to redistribute, embed, rebrand, resell, or host FusionAuth for your own customers. Self-hosted Community covers the core B2B SaaS case; paid plans add features such as IdP-initiated SAML, advanced MFA, and application-specific themes, while SCIM, Tenant Manager, and application-level MFA policies sit in Enterprise.

For B2B shape: FusionAuth models tenants and applications, but the abstraction is "containerized auth per tenant" rather than "B2B organizations as a domain object." It works (I've shipped products on it), but the multi-tenancy feels more like an isolation primitive than a first-class B2B model. The official SDKs and client libraries are broad:

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

The server-side libraries are thin API clients. The admin console is comparatively friendlier to hand to a non-engineer ops person than the others.

My read: If your team values UI polish and a long, predictable history more than B2B-native primitives, FusionAuth. It's the most "boring" choice here, and that's a compliment.

Logto

Logto is the newest of the four, developed by Silverhand Inc. and MPL-2.0 licensed, and the one that most obviously cares about its dashboard. First-day setup is comparatively fast. You provision, click through the wizard, and have a working OIDC provider with a decent default login UI in roughly fifteen minutes (I timed it the week I ran the four side by side). Its official quick starts cover modern frameworks and server stacks, so if your stack is "Next.js + Postgres + something," you'll feel at home.

Its B2B answer is called Logto Organizations. It covers the core B2B primitives: organization membership, organization-scoped roles, member invites, just-in-time provisioning, and enterprise SSO integration. The organization model is newer than ZITADEL's, so I would test any unusual SAML, SCIM, or federation flow against your target customers before committing.

The trade-off is maturity: Logto is the newest option here. The roadmap moves fast, which is great when a feature you need lands and uncomfortable when a breaking change does. If your B2B SaaS is on the simpler end of the multi-tenancy spectrum (a small set of orgs and no exotic federation requirements), Logto's developer experience makes the rest of the decision easier.

My read: If you want the fastest first day and your B2B needs are still relatively simple, Logto.

Ory Hydra (and the Ory Stack)

Ory Hydra is the OAuth 2.0 / OpenID Connect server from the Ory ecosystem, Apache-2.0 licensed. The full Ory stack pairs Hydra with Ory Kratos (identity and user management, self-service login, registration, MFA, and account recovery), Ory Keto (a Zanzibar-style authorization server and policy decision point), and Ory Oathkeeper (an identity and access proxy that authenticates, authorizes, and mutates incoming HTTP requests). You assemble what you need. Everything is written in Go, and the APIs are clean.

The catch (and this is not a flaw; it's a feature for the right team) is that Hydra is the engine, not the application. By design, Hydra connects to a separate login and consent app that you provide. If you want a login screen out of the box, this is not the tool. If you're building something where the auth flow is part of your product (a developer platform, a custom B2B portal, or an API-first product with bespoke onboarding), the lack of opinionated UI is exactly what you want.

The B2B story is composable rather than turnkey. You can model multi-tenancy by wiring Kratos schemas and Keto relations to your own organization layer, and it works, but you're doing the wiring. The cost is more plumbing; the benefit is control over the experience. Ory's documentation covers the protocol surface in depth, but the composable model assumes you're comfortable making protocol-level decisions yourself. If "audience claim" or "PKCE" doesn't mean anything to you, start with one of the other three.

My read: If you're building something protocol-level (auth gateway, custom flows, developer platform) and the standard apps feel constraining, Ory is the right answer. For a typical B2B SaaS that wants login working today, it's not.

How They Compare at a Glance

Here's the four-tool summary in one table, useful for the second pass, not as a substitute for reading the profiles above.

Which One Should You Start With?

Four short scenarios that cover most of the teams I'd be talking to about this.

You're building a B2B SaaS and you know you'll have tenants. Start with ZITADEL. The multi-tenancy and organization primitives are designed for exactly this, the API surface is comprehensive, and you'll spend less time inventing the tenant model than with any of the other three. The AGPL switch deserves a license review, but an unmodified, separately integrated deployment is usually a straightforward SaaS use case.

You want the polished admin UI and a stable, predictable platform. FusionAuth. The Community plan covers many teams' core needs; budget time to read the license and feature matrix carefully. Features including IdP-initiated SAML, advanced MFA, and application-specific themes require a paid plan, while SCIM, Tenant Manager, and application-level MFA policies sit in Enterprise.

Your B2B needs are simple today and you want the fastest first day. Logto. Its first-day developer experience was the quickest in my side-by-side test. Accept that you're betting on a younger ecosystem, and revisit the choice if your requirements grow into federation edge cases you have not tested.

You're building something where auth flows are part of the product experience. Ory Hydra (plus Kratos, plus Keto if you need permissions). You'll write more code. You'll have more control. If that trade isn't obvious to you, you're not the audience for Ory. Go pick one of the other three.

If two of these descriptions sound like you, default to ZITADEL. It's the broadest fit and the one I'd hand to a small founding team without asking many follow-up questions.

What Self-Hosting Costs You (Operationally)

Here's the unromantic part of the article.

Your PostgreSQL backup discipline is now a thing your business depends on. Across these deployments, the identity state you must protect can include user records, hashed credentials, MFA secrets, OAuth client credentials, and session data. Lose that state, and your customers may lose the ability to log in. Set up automated backups before your first real user signs up, test the restore, and put the backup health in the same alerting channel as your application uptime.

Release pace changes over time. ZITADEL v4.16.1 shipped on July 17, 2026 after several June releases, while every project here maintains its own cadence and compatibility policy. Treat that cadence as a maintenance concern, not a quality shortcut. Read release notes before you run docker compose pull, and schedule a recurring patch window. Skipping identity-provider updates for months can leave you behind security and compatibility fixes during your first real review.

The mundane stuff that always sneaks up on you: TLS certificate renewal (use a reverse proxy with Let's Encrypt, automate renewals, and alert on failures), outbound mailer configuration for verification emails and password resets (SES, SendGrid, Postmark: pick one and configure SPF/DKIM/DMARC properly or your password-reset emails will land in spam), OAuth client credential rotation when an engineer leaves, and rate-limiting the login endpoints so a credential-stuffing attack doesn't pin your CPU.

The thing the self-hosted route saves you in dollars, it costs you in ownership. After setup, budget a few engineering hours a month for keeping the identity layer healthy. Teams that allocate zero time usually discover the cost later, during an outage, a weird SAML edge case, or their first security review.

Where to Deploy Them

A Linux VPS running Docker Compose can be a sensible starting point for evaluation and modest workloads, but production sizing and high availability depend on traffic, security requirements, and your tolerance for downtime. Here's how the common deployment options fit:

• Shared hosting can't run any of them. They need persistent storage, custom ports, root access for the container runtime, and a real database backend. PostgreSQL is the default path for most of this list, but it is not literally the only supported database for every tool.
• Kubernetes can run all four, but the first-party path is uneven. ZITADEL, FusionAuth, and Ory publish first-party Helm charts, while Logto's self-hosting documentation focuses on Docker and VM deployment. For a small B2B SaaS that has not reached the point where Kubernetes pays for itself elsewhere, it is usually over-engineering. Reach for it when the rest of your infrastructure is already there.
• Bare metal is fine if you're already on bare metal. Most B2B SaaS teams aren't.

For a small single-node pilot, I'd start at 4 GB RAM, 2 vCPU, and 60 GB of NVMe storage, then load-test the real login flow. That is a planning baseline, not a universal production minimum. The applications are comparatively light, but PostgreSQL needs memory and password hashing needs CPU headroom. ZITADEL's production guidance recommends making four CPU cores available for password-hashing spikes.

Once the product is real and traffic is sustained, resize from measurements. Fast storage helps PostgreSQL latency, while CPU headroom matters during concurrent password hashing. Watch memory, database I/O, login latency, and CPU saturation instead of assuming one resource matters most.

Running CIAM in production means its uptime is now your problem. We run Cloudzy Linux VPS instances for this kind of workload, with NVMe storage and a 99.95% uptime SLA on the underlying platform. Cloudzy also offers a one-click ZITADEL VPS if you'd rather skip the initial provisioning script; the other three provide official container images for a Docker-based setup. For a manager-level view of how access control fits into the rest of your security posture, the IAM best-practices guide covers it from the policy side.

Frequently Asked Questions

Does ZITADEL's AGPL License Affect My SaaS?

Usually not for an unmodified, separately integrated deployment, but this is not legal advice. ZITADEL's AGPL obligations apply to ZITADEL itself. If you modify ZITADEL and operate that modified version as a network service, the license can require you to offer the corresponding source under AGPL. ZITADEL's published position is that merely using an unmodified instance as your SaaS identity service does not, by itself, require you to license your separate application under AGPL. Read ZITADEL's licensing announcement and get legal advice if you modify, redistribute, embed, or offer the software to third parties. A commercial license is also available.

Why Aren't Keycloak or Authentik on This List?

Keycloak and Authentik are excellent self-hosted identity tools (I use them), but excluding Keycloak because it lacks B2B organizations would now be wrong: current Keycloak releases include Organizations, organization groups, and delegated administration controls. I left it out because this comparison focuses on four options with a more direct small-team B2B SaaS path; Keycloak deserves its own evaluation when JVM operations, ecosystem depth, and realm-level flexibility matter. Authentik remains a stronger fit for workforce and internal-app SSO than product-native tenant modeling.

Is Self-Hosting Cheaper Than Auth0?

At low MAUs, often no. Your engineering hours cost more than Auth0's bill at the early-startup tier. Self-hosting wins economically at the scale where managed CIAM's per-MAU pricing crosses the combined cost of a small VPS plus the few engineering hours a month you'll spend on it. The exact break-even depends on your team's hourly cost, your MAU growth curve, and whether your product needs enterprise features that push you into Auth0's higher-priced tiers. Treat the savings as real but not instant.

What's the Minimum VPS Size for a Production CIAM?

For a small single-node pilot, 4 GB RAM, 2 vCPU, and NVMe storage is a reasonable starting point, not a production guarantee. Size from your database footprint, concurrent login load, password-hashing cost, and uptime target. ZITADEL's own production guidance recommends four CPU cores be available for password-hashing spikes; other tools and traffic patterns need their own load tests.

Can I Migrate From a Managed CIAM to Self-Hosted Later?

Yes, but plan it as a real project. Password resets are not inevitable: exportability and supported hash formats vary, and some targets support bulk or just-in-time user migration while others require a reset. MFA factors, OAuth clients, active sessions, email verification state, and tenant or role mappings need separate treatment. If you already suspect you'll self-host later, record those export and migration constraints before choosing the managed provider.