Identity infrastructure, not a login component
ZITADEL takes responsibility for the part of an application that is easiest to underestimate. It authenticates people and machines, issues standards-based tokens, connects outside identity providers, enforces multi-factor policies, and gives administrators a place to manage access. OIDC, SAML, SCIM, passkeys, one-time codes, service accounts, token exchange, and impersonation all sit under one system.
Its most convincing use case is B2B software. ZITADEL models an identity system containing organizations and projects, with policies and roles scoped through that hierarchy. A SaaS vendor can let customer administrators manage their own members without pretending each customer is an unrelated deployment. Domain discovery and identity brokering can direct users toward their organization's provider, while branding can vary by organization.
The API-first claim has substance. Resources and operations are available through REST-shaped HTTP, gRPC, and ConnectRPC interfaces. Actions and webhooks can react to identity events or enrich tokens. Every mutation enters an immutable event stream, giving the audit trail more structure than a collection of selected log messages. This is valuable when identity must feed a SIEM, provisioning system, customer portal, or internal control plane.
Three minutes gets a lab, not production
The README's Compose command is a fair way to see the product. The current stack starts Traefik, a ZITADEL API service, a separate Login V2 service, and PostgreSQL. Health checks and pinned image variables are already present. Optional profiles add Redis caching and OpenTelemetry collection. That is a thoughtful demonstration package.
The accompanying environment file is equally clear that its defaults are insecure and intended only for local development. Before network exposure, operators must replace the master key and database credentials. A new deployment requires a master key of exactly 32 characters. The external domain, public scheme, ports, trusted proxy ranges, and TLS mode also need deliberate values. PostgreSQL must be backed up and monitored like the authentication dependency it is.
Production therefore looks like operating a database-backed platform, not dropping one executable beside an application. Teams need high availability, secret management, certificate handling, email delivery, alerting, recovery drills, and staged upgrades. ZITADEL documents Kubernetes, horizontal scaling, and zero-downtime updates, but documentation does not supply the people on call when every customer is locked out. ZITADEL Cloud is the rational comparison, not merely a fallback, for teams that want the feature model without owning the control plane.
There is also a routing constraint to confirm early. An open request says self-hosted ZITADEL needs a separate domain or subdomain rather than a path such as /auth under an existing application host. That can matter in enterprises with strict DNS and outbound allowlists. Do not design the public URL after integrating clients, because issuer and redirect addresses become part of the security contract.
Strong features need exact flow testing
Login V2 is capable and still visibly moving. Current open reports describe a passkey login getting stuck when the same user also has password and TOTP configured, expired account selection doing nothing for users linked to multiple identity providers, and domain discovery hiding an external provider when local password login is enabled. These are specific combinations, not proof that ordinary login fails. They are exactly the combinations sophisticated buyers are likely to use.
The latest release, v4.17.1 on August 14, fixed several authentication-sensitive paths. It blocks Login V2 authentication for users in deactivated organizations, checks permission before issuing passkey enrollment codes, prevents a browser path from requesting OTP return codes, and requires an MFA prompt before second-factor enrollment. Fast corrective releases are reassuring. The content of those fixes also argues for pinned versions, preproduction policy tests, and prompt security updates.
Event sourcing has its own operational edge. A detailed August report from a self-hosted Kubernetes user says frequent grant reconciliation could leave a user grant present in the event store but absent from the projection used by the API and console. Re-creation then failed because the uniqueness reservation remained. The reporter traced this to a known projection race whose fix existed on the main branch but not the installable v4 release they checked. Treat this as a workload-specific open report, not a universal failure, and reproduce high-frequency grant automation before committing.
One simpler gap may decide regulated deployments: a long-running open request asks for prevention of password reuse and cites PCI DSS password-history needs. Organizations with that exact control should verify the current product rather than assume a mature IAM platform includes every password policy. Passkeys or federated login may reduce password dependence, but they do not rewrite a written compliance requirement.
Healthy enough to trust, active enough to watch
The repository was pushed on August 17, 2026, three days after v4.17.1. Recent issue and pull-request activity spans security checks, Login V2, SAML logout, translations, dependencies, API errors, and outside contributions. GitHub's open count of 1,124 combines issues and pull requests, so it should be read as a large product work queue, not 1,124 confirmed defects. The speed of review and release work is a stronger health signal than the raw number.
Documentation is one of ZITADEL's advantages. It covers concepts, API references, application quickstarts, federation, B2B onboarding, self-hosting, updates, scaling, audit export, and release support. The repository is AGPL-3.0 with documented exceptions for some directories, so teams distributing modifications or providing network access should review the licensing policy with their normal counsel.
Choose ZITADEL when identity is a platform capability and customer organizations are central to the product. Choose Keycloak when its long history and ecosystem matter more, authentik for access-proxy-heavy self-hosting, or Logto for a more application-centered path. ZITADEL is powerful enough to justify real evaluation, but too consequential for a checklist decision. Build a tenant model, migrate sample users, exercise every recovery and federation route, load-test grant automation, and restore PostgreSQL before calling the selection complete.