zitadel writes every change as an event, then compares itself to rivals

The audit trail is not a log, it is the write path

The differentiators section makes an architectural claim rather than a feature claim, and it is the one to understand first.

It says every mutation is written as an immutable event for a complete, API-accessible audit trail, and contrasts this with systems that log only select activities, describing its own output as a comprehensive event stream that can be audited or streamed to external systems through webhooks.

The README sums this up as a relational core with an event-driven soul.

For an identity platform that is a strong fit, because an audit trail of every change is exactly what a compliance reviewer asks for and it is very hard to retrofit. It also has a cost: every change leaves an immutable event behind, so the stream's retention and backup need planning.

If you are evaluating on audit requirements, this is the strongest argument for the project. If you are evaluating on operational simplicity, it is the strongest argument against it.

The comparison table grades three named competitors, and one cell is unexplained

There is a feature table near the top of the front page with four columns: this project, and three competitors, which it names as a commercial identity product, an open-source one, and two hosted providers treated as one column.

Nine rows are scored, using tick marks for yes, crosses for no, and a yellow circle for partial across every competitor. Scored this way, the project's column is all ticks, and in the SaaS and self-host parity row Keycloak and Auth0/Okta are marked not applicable.

Two rows are worth pausing on because they are where the project claims a difference. One is the audit trail, where its own entry is a descriptive claim with an asterisk after it. The other is multi-tenancy, where it claims infrastructure-level tenants with instances at high scale and describes a competitor's equivalent as realms with scaling limits.

So the table is marketing in tabular form, placed above the documentation links. That is common and not improper, but it means the table is the vendor grading rivals, and a prospective user is being handed the comparison rather than the criteria.

For an honest evaluation, check the self-hosted and cloud documentation for the specific behaviours you care about rather than taking a row of ticks as settled.

The quick start installer fetches from the development branch

The self-hosted quick start is one command chain and it is worth reading closely.

curl -LO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml \
  && curl -LO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example \
  && cp .env.example .env \
  && docker compose up -d --wait

Two files are fetched, and the environment file is copied over the example without being edited. Then compose is started and waited on.

The detail is that both URLs point at the main branch rather than at a release tag. So the documented three minute install uses whatever compose and environment files are on the main branch at that moment, not files tied to a release tag.

For an identity service that is the wrong default, and it is worth being precise about why. The project's release history is orderly, with v4.19.5, v4.20.0 and v4.20.1 released between 2026-10-15 and 2026-11-03, so there is a stable artefact to pin to. Choosing the branch instead means the files you deploy from depend on when you ran the command.

The page also links separate full guides for compose and for Kubernetes. Those are the routes to read if the deployment has to be reproducible.

AGPL, a separate licensing document, and a support offer on the front page

The project is licensed under the Affero General Public License version 3, and there is a second licensing document at the root of the repository alongside the licence text itself.

A separate licensing document in an open source project is usually there because the terms are not fully captured by the licence identifier, most commonly because commercial use is available under separate terms.

That reading is supported by what the front page offers. There is a hosted service with regional availability listed for four areas and pay-as-you-go pricing, a pricing page, and a line inviting anyone needing professional support for a self-hosted deployment to get in touch.

The core is genuinely open, and it is genuinely capable. The licensed features listed include single sign-on, username and password, passkeys to the FIDO2 standard, multi-factor by several methods, directory federation and social logins, an OpenID Connect certification, SAML, device authorization, machine-to-machine flows by three methods, token exchange and impersonation, custom sessions, hosted login, identity brokering, business-to-business onboarding, delegated role management and domain discovery.

The practical question is whether the tier you need is in the licensed core or above it. The separate licensing document, LICENSING.md, is the place to check, and it is worth reading before you commit an identity architecture to it.

The meeting schedule is a tracked file at the repository root

Among the top-level entries are several documents you would not expect to find in a repository root, and one of them is unusual enough to be worth naming.

It is a file describing a meeting schedule.

Alongside it are an architecture document for the API, a terminology document, an adopters list, a security policy, a code of conduct, a contributing guide, and an agents file. There is also a rules file for one particular editor at the root, and a directory of skills.

Publishing a meeting schedule as a tracked file is a governance choice rather than a technical one, and it is a good one: it means when the project discusses its direction, when, is committed rather than remembered.

The terminology document is the one with practical value for an integrator. Identity platforms accumulate vocabulary that means something slightly different from the obvious meaning, and in a project with this much hierarchy, having the definitions written down is what stops a developer from guessing what a given level contains.

Together these suggest a project that has thought hard about how it wants to be worked on, not only how it wants to be built.

The tests embed a database, a cache and a virtual authenticator

Read the development dependencies and the testing approach is legible.

There is an embedded PostgreSQL distribution, used so the suite can start a real database rather than mock one. There is a Redis implementation in memory, also a test substitute. There is a SQL mocking library. There is a virtual WebAuthn authenticator, which means passkey flows can be exercised without hardware. And there is a fake data generator for fixtures.

So the suite is integration-heavy by design. For an identity platform that is the right trade, because the things that break are the things unit tests cannot reach: a migration against a real engine, a session against a real cache, a passkey ceremony against a real authenticator state machine.

The cost is that the suite is slower and heavier than a mocked one, and it needs the embedded database to start correctly on your platform.

There is also a JavaScript interpreter embedded in the binary, with a Node compatibility shim beside it.

The observability dependencies point at one cloud provider specifically: a cloud profiler and two vendor-specific OpenTelemetry exporters for metrics and traces. That is a hint about where the maintainers run it, and it is worth checking against your own platform before you depend on the built-in telemetry.

A JavaScript workspace sits on top of the Go monorepo

The repository is primarily Go, with a module definition, a main entry point and the usual command, internal and package directories. On top of that there is a JavaScript workspace with its own manifest, lock file and build tool.

That manifest is almost empty. It declares a package manager version, a scope, a private flag, and two scripts, one of which is a cleanup that removes the build cache and the installed dependency tree. Its development dependencies are a protobuf toolchain, a release tool, a task runner, a stylesheet compiler, a syntax highlighter and a process-wait utility.

None of that is a frontend application. It is a build orchestration layer, and the absence of a web framework in the list is the tell.

The wider tree has the same doubled character. There is both a package directory and an internal directory, both an applications directory and a console directory. Protobuf definitions sit beside generated API specifications, and there is a directory of embedded static assets, which is how the web interface gets compiled into the binary.

The practical consequence for a contributor is that you need the Node toolchain and the Go toolchain, plus the protobuf generator, to produce a build from source. That is a wide surface for an identity service, and it is the main thing to weigh before planning a fork.

Editorial conclusion

ZITADEL suits a team building a multi-tenant product where organisations, projects and identity scoping have to nest properly, and where an audit trail is a compliance requirement rather than a nice-to-have. Two things to weigh. That every mutation is written as an immutable event, so plan the event stream's retention and backup before you go live. And that the comparison table on the front page is the vendor grading competitors, so read the self-hosted and cloud documentation rather than treating that table as an evaluation.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. zitadel/zitadel on GitHub