Every SaaS product eventually runs into the same wall. Login works fine when you have a hundred users in one flat list. Then a customer asks for their own single sign-on setup, another wants their employees to log in through Entra ID, and a third wants to manage its own users without calling your support line. Suddenly “add a login page” has turned into a multi-tenant identity project nobody budgeted for.

Zitadel exists because a team of identity engineers in Switzerland kept running into that exact wall and got tired of rebuilding the same fix from scratch. It’s an open-source identity and access management platform built specifically around the idea that tenant isolation, not just login, should be handled at the infrastructure layer.

This guide walks through what Zitadel actually is, how its architecture works under the hood, what it can do out of the box, and where it fits compared to other open-source identity providers like Keycloak and Authentik.

What Is Zitadel?

Zitadel is identity infrastructure built for developers, designed to work for all users and applications, not just a single login form bolted onto one product. Founded in Switzerland, it’s entirely open source and written in Go, available both as a managed cloud service and as something you self-host on Linux, macOS, Docker, or Kubernetes.

It competes in the same space as Auth0, Keycloak, and Cognito, positioning itself as a modern, developer-friendly, cloud-native alternative rather than a traditional enterprise console you have to fight with. Startups reach for it for a fairly practical reason: instead of reinventing every security-critical piece of identity themselves, they plug into Zitadel and put their engineering time back into the actual product.

Under the license terms, most of the codebase is available for you to inspect, self-host, and modify freely. Zitadel is licensed under AGPL-3.0, with Apache 2.0 and MIT exceptions carved out for specific directories, which matters if your legal team cares about exactly what you’re allowed to do with the source.

The company behind it isn’t shy about why it exists. Zitadel’s founders describe enterprise identity management as having become a barrier to innovation rather than an enabler, and built the platform around the belief that identity should be treated as foundational infrastructure, the same way databases and web servers are.

How Zitadel Works: The Architecture

This is the part that actually explains why Zitadel behaves differently from most identity providers you’ve used before.

Event Sourcing at the Core

What sets Zitadel apart is its event-sourced architecture, where every change in the system is captured as an immutable event. Nothing gets silently overwritten. When a user’s password changes, when a role gets assigned, when an organization’s login policy gets updated, each of those is stored as a permanent event in a stream rather than a row that just gets updated in place.

The practical result is a relational core with an event-driven soul: every mutation is written as an immutable event for a complete, API-accessible audit trail, unlike systems that only log select activities. If a compliance team ever asks “who changed this permission and when,” the answer is already sitting in the event stream, not scattered across application logs you have to reconstruct after the fact.

Zitadel actually keeps two representations of your data side by side: the events themselves form the audit trail, while a separate relational projection is built from those events to serve normal, fast queries. You get the append-only guarantees of event sourcing without paying the price of querying an event log directly every time someone loads a user list.

The Instance, Organization, Project Hierarchy

Zitadel is built around a strict multi-tenant hierarchy: Identity System, then Organizations, then Projects, with isolated data and policy scoping at each level. That’s not marketing language, it’s the actual data model.

An Instance represents the top-level Zitadel deployment. Within it, multiple Organizations can exist, each representing a customer or partner with its own users, roles, identity providers, and branding, while Projects inside those organizations define the applications and their access policies. In plain terms: onboarding a new B2B customer with their own SSO setup, password policy, and branded login page is a matter of creating a new Organization, not a support ticket that lands on an engineer’s desk.

This is exactly the shape a B2B SaaS company needs when customers each want their own login flow, their own branding, their own federation with Azure AD or Google Workspace, and the ability to self-manage their own users and roles without your team touching it. You create an organization per customer, hand them an organization manager, and let them run their own show from there.

No External Session Store

Zitadel’s design avoids relying on an external session store, which enables horizontal scaling without the usual headache of keeping session state synchronized across nodes. Add more instances behind a load balancer, and the system doesn’t need a shared Redis cluster just to know who’s logged in. Zero-downtime updates and horizontal scalability come out of that same design choice.

API-First, All the Way Down

Every resource and action in Zitadel is available through connectRPC, gRPC, and HTTP/JSON APIs, and no feature is UI-only, everything you can do through the admin console has a corresponding API call behind it. That matters more than it sounds like it should. Plenty of identity platforms have an admin panel that quietly does things the API can’t replicate, which turns infrastructure-as-code and CI/CD pipelines into a guessing game. Zitadel’s stated goal is that the console is just another client of the same APIs everyone else uses.

Core Features

Once the architecture clicks, the feature list mostly reads as consequences of that design rather than a bolted-on checklist.

Authentication methods. Zitadel supports single sign-on and multi-factor authentication using industry-standard protocols including OpenID Connect and SAML, and users can authenticate with passwords, passkeys, WebAuthn, one-time passwords, or hardware security keys. Passwordless sign-in through Passkeys and FIDO2 lets people log in with biometrics or a hardware key without ever touching a traditional password.

Identity brokering and federation. Zitadel works with SAML, OpenID Connect, and LDAP external identity providers, and for popular services like EntraID, Okta, Google, Facebook, and GitHub, it ships pre-configured templates that expedite setup with minimal effort. In a multi-tenant application, this means you can configure a different external identity provider per organization, so one customer logs in through their own Entra ID while another uses Okta, all under the same Zitadel instance.

Domain-based routing. Domain discovery ensures users are redirected to the correct external identity provider based on their email address or username, using organization domains configured by administrators. A user typing their work email doesn’t need to know or care which identity provider sits behind it.

Provisioning and extensibility. Zitadel provides SCIM 2.0 provisioning for automated user lifecycle management, plus support for webhooks, custom actions, and token enrichment. Those custom Actions let you execute your own code on events, which is how teams bolt on business logic (like syncing a new user into a CRM the moment they register) without forking the platform.

Self-service. Self-registration, account recovery, verification, and other self-service workflows are included, so users can reset their own passwords and organizations can onboard new employees without opening a support ticket every time.

Deployment Options

Zitadel offers a managed cloud solution, or self-hosting on Linux, macOS, Docker, or Kubernetes. Zitadel Cloud and the self-hosted version run the exact same codebase, so you aren’t choosing between a “real” product and a stripped-down open-core version, you’re choosing who operates it.

Getting a self-hosted instance running is not a weekend project the way some identity providers are. A Docker Compose setup can be up and running in under three minutes using the project’s published compose file. Under the hood it’s built container-first on an event-sourcing architecture with CQRS, and it supports both PostgreSQL and CockroachDB as its data store, giving you a choice depending on whether you already run one or the other.

Pricing

Zitadel offers a free plan that includes 100 daily active users, unlimited total users, and access to the platform’s core features, which is generous enough for most side projects and early-stage products to never pay a cent. On the managed cloud side, the free tier covers up to 25,000 monthly active users, with paid Pro plans starting around $100 a month for teams that outgrow it. Self-hosting, naturally, is free regardless of scale, you just take on the infrastructure and operational responsibility yourself.

Zitadel vs. Other Open-Source Identity Providers

Zitadel isn’t the only open-source name in this space, and it’s worth being honest about where it sits relative to the two most commonly compared alternatives. If you’re also weighing Keycloak or Authentik, our breakdown of Authentik vs Keycloak: Key Differences covers how those two stack up on protocol depth, setup experience, and scalability, which is useful context before adding a third option to the shortlist.

Against both of them, Zitadel’s honest positioning is narrower and more specific. It is not as feature-rich as Keycloak, and not as broadly user-friendly as Authentik, but if multi-tenancy is your primary requirement, Zitadel is the strongest open-source option available. Its native multi-tenancy, designed into the system from day one rather than bolted on as an afterthought, is what tends to sway B2B SaaS teams that need to manage many organizations, each with their own users, roles, policies, and branding, over other platforms that require workarounds to get there.

Where Keycloak has more overall protocol depth and Authentik has a friendlier general-purpose admin experience, Zitadel’s pitch is: if your product is B2B and your customers each need their own isolated identity setup, this is the tool built around that exact problem rather than one that can technically do it with enough configuration.

Who Should Use Zitadel?

Zitadel makes the most sense for teams building B2B SaaS, platforms, or multi-tenant products where tenant isolation and roles genuinely matter, and for technical teams comfortable working with APIs, tokens, and infrastructure who want more flexibility than a purely proprietary SaaS option provides.

If your product is still early and you only need basic email or social login with minimal configuration, a simpler tool like Firebase Authentication may honestly be enough. But once you’re moving toward complex enterprise requirements, cross-tenant permissions, or strict deployment constraints, Zitadel starts to look a lot more compelling than building that logic yourself on top of something more generic.

Frequently Asked Questions

Is Zitadel free to use? Yes. The self-hosted version is free regardless of user count. The managed cloud service has a free tier covering up to 25,000 monthly active users, with paid plans starting around $100 a month beyond that.

What programming language is Zitadel written in? Zitadel is written in Go and ships as a single binary, which is part of why self-hosted deployments start up quickly compared to JVM-based identity providers.

Does Zitadel support passwordless login? Yes. Zitadel supports passkeys, WebAuthn, and FIDO2 for passwordless authentication, alongside traditional passwords, one-time passcodes, and hardware security keys.

How is Zitadel different from Keycloak? Zitadel is built around native multi-tenancy from the ground up, which makes it a strong fit for B2B SaaS products serving many isolated customer organizations. Keycloak has more overall feature and protocol depth and a longer enterprise track record, but multi-tenant isolation is not its primary design focus the way it is for Zitadel.

Can I self-host Zitadel instead of using the cloud version? Yes. Zitadel Cloud and the self-hosted version run the same codebase, so self-hosting on Docker, Kubernetes, Linux, or macOS gives you the same feature set as the managed offering, minus the operational overhead being handled for you.

Does Zitadel support SCIM provisioning? Yes. Zitadel provides SCIM 2.0 support for automating user provisioning and deprovisioning from external systems like an HR platform or a company directory.

Final Thoughts

Zitadel solves a specific, well-defined problem: giving B2B SaaS products a way to hand each customer their own isolated identity setup without engineering a bespoke multi-tenancy layer on top of a generic auth tool. The event-sourced architecture and API-first design are what make that possible, and they’re also what set it apart from older identity providers that added multi-tenancy as an afterthought rather than a foundation.

If your roadmap includes serving multiple business customers, each wanting their own SSO, branding, and user management, it’s worth spending an afternoon with Zitadel’s official documentation before you commit to a different platform. The setup is fast enough that you’ll know within a day whether it fits.

For more breakdowns of identity platforms, self-hosted infrastructure, and DevOps tooling, keep exploring the guides on CourseDrill.