Organizations and projects are first-class boundaries
ZITADEL is designed for B2B identity rather than a single application's login screen. Its hierarchy separates an identity system, customer organizations, and projects, with roles and policies scoped at several levels. The feature set includes OIDC, SAML 2.0, SCIM 2.0, passkeys, MFA, identity brokering, service accounts, token exchange, delegated role management, and custom sessions. Every resource is available through connectRPC, gRPC, or HTTP APIs.
That breadth is most useful when customers administer their own members and applications share one identity platform. A small product with one tenant and a few social providers may spend more time understanding organizations, grants, instances, projects, actions, and policies than it saves. ZITADEL should replace a real IAM problem, not a password form. The README's 3-minute Compose claim describes first startup, not production readiness.
The event stream improves audits and raises database stakes
Every mutation is recorded as an immutable event, which gives ZITADEL an API-accessible audit trail and a source for external webhooks or security systems. The relational core uses PostgreSQL 14 or newer. The project documents horizontal scaling and zero-downtime updates without an external session store. Those properties are attractive when identity changes must be traceable across many customer organizations.
Event-driven storage also makes database operations part of authentication. Backups must preserve more than a current user table, and restoration needs testing against projections and application behavior. Signing keys, SMTP credentials, external identity-provider secrets, redirect policies, and a break-glass administrator all need separate handling. A Compose container reaching a healthy state does not answer how users sign in during a region failure or a damaged migration.
What happened when we ran it
Our harness classified commit a1a4572 as a Node pnpm workspace and installed it in 225 seconds. The dependency tree added 2,123 packages and occupied 1,873 MB. The checkout before installation was already 250.9 MB with 9,927 files and about 912,264 source lines. This is the largest repository in the requested set by both file and source-line count.
No root build script or target was exposed to the harness, so the build was skipped. No root test script or target was exposed either, so tests were skipped. The repository did contain a tests directory and 10 CI workflow files. Skipping is not passing: our measurements do not prove that the Go server, login application, console, database migrations, or protocol suites compile and pass at commit a1a4572.
The run used a Node 22 Debian container with 3 CPUs, 8 GB of RAM, and no secrets. It did not start PostgreSQL, migrate a database, issue tokens, or exercise OIDC. The 225-second result is still useful for contributors working in the web monorepo, but production evaluation needs the documented server build, a real database, TLS, email, and a client application that verifies login and logout flows.
v4.17.1 fixed four authentication mistakes
Release v4.17.1 arrived on August 14, 2026 with four narrowly described fixes. It blocks Login V2 authentication for users whose organization is deactivated, enforces a permission check when issuing passkey enrollment codes, prevents a browser from requesting OTP codes through returnCode, and requires an MFA prompt before 2FA enrollment. That release content is exactly why identity software needs prompt patch review rather than casual quarterly upgrades.
Current work continues in the same area. Pull request 12616 says TOTP codes could be reused within their valid window and proposes recording a salted HMAC after successful use. Another pull request applies configured root CAs during LDAP StartTLS. These are active changes, not proof that every deployment is exposed. They are reasons to subscribe to advisories, pin supported releases, rehearse upgrades, and map each enabled protocol to its own regression tests.
v4.17.1 still has OIDC and API consistency reports
Issue 12645 reports that response_mode=fragment double-encodes OIDC state in versions 4.16.0 and 4.17.1, while query mode returns it correctly. A state mismatch can break a relying party even when authentication itself succeeds. Teams using fragment mode should reproduce the report with their client library and track the upstream issue before rollout.
Issue 12642 describes inconsistent no-op writes in v4.17.1. Some endpoints return 200 when the desired setting already exists, while policy, application, identity-provider, and other commands may return 400 NoChangesFound. That matters for declarative provisioning, which often repeats the same desired state. Wrap calls carefully, distinguish a true invalid request from an unchanged value, and test reconciliation twice.
AGPL licensing belongs in the architecture review
The main repository uses AGPL-3.0, while the licensing policy provides Apache-2.0 and MIT exceptions for specific directories. That is not the same as a permissive license across the product. A company modifying or serving ZITADEL should have counsel review the exact deployment, modifications, distribution, and exception boundaries before implementation starts. The cloud service is an alternative when operating or licensing the server is unattractive.
GitHub recorded 14,862 stars, 1,137 open issues and pull requests combined, and a last push on August 26, 2026. The combined count is not 1,137 bugs; it includes a large, active contribution queue. ZITADEL deserves a proof of concept when multi-tenant IAM is already a platform requirement. Our 1,873 MB pnpm result warns contributors about scale, while the untested server path means the final decision should rest on a full deployment exercise, protocol tests, restore rehearsal, and an upgrade plan.