Zitadel vs Casdoor

Which Zitadel vs Casdoor scenario fits your team

This table maps common team situations to the platform that fits better and the supplied facts behind each choice. The scenarios are illustrative, so check each row against your own tenancy model, protocol needs, database standard and license policy before deciding.

How Zitadel and Casdoor are built and what that means for operations

Zitadel and Casdoor both run as Go services with a database behind them, but they store state differently and ship through different release habits. The cards below take the parts that shape daily operations in turn: the runtime, the database, deployment methods, event-sourced storage and release cadence.

Zitadel vs Casdoor protocols, databases and licensing side by side

This table compares protocol coverage, licensing, federation and database support for Zitadel and Casdoor, using only documented facts. Where a row shows a gap in the supplied documentation, the confirm column tells you what to test in a proof of concept before deciding.

What drives the running cost of Zitadel and Casdoor

Licensing and editions: what AGPL-3.0 and Apache-2.0 each require

Where Zitadel and Casdoor implementations run long

Moving between Zitadel and Casdoor: what transfers and what is rebuilt

This sequence shows which identity objects can be carried across, which must be rebuilt in the target, and how to cut applications over without a login outage. Each step ends with a check you can verify before moving on.

1. Inventory organizations, users, groups and applications

   Start by listing every organization, user, group, role, application and client registration in the source instance, with its redirect URIs, scopes, signing settings and the protocol each application uses (OIDC, OAuth 2.0, SAML 2.0 or LDAP). Assign the work to the identity owner and an application owner for each client. The step is done when the inventory has one row per application and each row names its owner, its protocol and the environment it serves. Treat this list as the migration scope for every later step.

2. Confirm what credentials and MFA secrets can move

   Decide, for each user population, whether password hashes and MFA enrollments can be exported and imported. Ask Zitadel and Casdoor directly what their import formats accept, which hash algorithms they support, and whether TOTP seeds or passkey credentials can be carried over. Zitadel documents migration guides from Auth0, Keycloak, Firebase and another Zitadel instance, using approaches such as just-in-time migration; confirm the Casdoor migration path in its documentation before assuming any. The check is a written answer per credential type. Where a secret cannot move, plan for users to re-enroll MFA and reset passwords.

3. Rebuild the tenant structure in the target

   Recreate the tenant model in the target platform. In Zitadel, map each customer to an organization inside an instance, with projects that group applications, roles and grants. In Casdoor, create the organizations that share the instance, each with its own users, groups, roles, applications and branding. Keep names and identifiers stable so that claims and tenant references in your applications still resolve. The output is a target structure that matches the inventory, verified by listing each organization and confirming that its applications and roles exist.

4. Map SAML and OIDC client configuration

   Translate each client registration into the target's configuration. Carry over redirect URIs, allowed scopes, token lifetimes, claim mappings and SAML entity IDs, assertion consumer URLs and signing certificates. Generate new client secrets in the target rather than copying them, and record which application receives which secret through your secret store. The check is a test login per application against a non-production copy, with the claims the application reads confirmed field by field.

5. Import users through SCIM or a syncer

   Populate users and group membership with the method each platform supports. Zitadel provides a SCIM v2 service provider interface for standardized provisioning and lifecycle management. Casdoor describes syncers that import users from LDAP, Active Directory and Keycloak, and it also speaks SCIM 2.0; confirm which path fits your source directory and whether it preserves group membership. Run the import into a staging organization first, then compare user counts and group memberships with the source inventory. The step closes when the reconciliation shows no unexplained differences.

6. Cut over application by application with parallel logins

   Move applications one at a time, not the whole estate at once. For each application, enable the target login alongside the source, route a small set of test users to the target, and confirm that sessions, role claims and logout behave as expected. Keep the source client active until every user in that application's population has signed in successfully on the target at least once. Record the cutover date and the rollback path for each application. The step is complete when each application shows successful target logins and no open authentication errors in its logs.

7. Retire the source instance after audit log retention

   Before decommissioning the old instance, decide how its audit records will be kept. Zitadel is event-sourced and stores every change as an event, which gives a built-in change history over an unlimited period; Casdoor's audit retention should be confirmed in its own documentation. Export or archive the logs your compliance program requires, confirm the retention period with your auditors or internal policy owner, and then disable the source clients. The check is a signed archive record plus a confirmed list of closed client registrations. Only then delete the source database and its backups on the schedule your policy sets.

Questions buyers ask before choosing Zitadel or Casdoor