Keycloak vs Zitadel: which to choose

Keycloak vs Zitadel: which fits your identity program

If you run workforce single sign-on for employees and internal applications, Keycloak usually fits better. It is licensed under Apache-2.0, so you can modify and embed the server without copyleft obligations, and it covers OpenID Connect, OAuth 2.0 and SAML 2.0 in one server. Its user federation to LDAP and Active Directory is the more established path when your users already live in a directory. The condition is that your tenancy model can be expressed as realms or Keycloak's Organizations feature, and that you are comfortable running a relational database such as PostgreSQL, MariaDB or SQL Server in production, since Keycloak requires one outside development.

If you build a B2B product where each customer manages its own users, Zitadel fits better on the tenancy side. Zitadel places organizations inside one instance, so each customer can administer its own users and projects, and each organization can use a different identity provider. Zitadel also stores every change as an event, which gives a built-in audit history of changes over an unlimited period. The conditions are different: Zitadel's core, Console and hosted login are licensed under AGPL-3.0 since v3, so your legal team must confirm that the copyleft terms work for how you modify or deploy it, and self-hosted Zitadel runs on PostgreSQL 14 to 18. Confirm that SAML and SCIM requirements in your customer contracts are met by the versions you plan to run.

The decision turns on four questions. First, license policy: whether AGPL-3.0 is acceptable for the server you operate, or whether Apache-2.0 is a hard requirement. Second, the tenancy model: realms against organizations inside an instance, and whether customers need to administer their own identity settings. Third, SAML requirements, checked against the exact protocol coverage in each release. Fourth, your team's skills: PostgreSQL operations and, if you plan to use it, Kubernetes with the official Helm chart for high availability. A small IT team without either skill should price that operating effort into the comparison before choosing.

Which platform fits which scenario

This table maps six common scenarios to the platform that usually fits better and the condition that would change the answer. Read each row as a starting point: the deciding factors are usually the license obligations you accept, how your customers' tenants must be modeled, and how much Kubernetes and database work your team can own.

Scenario	Better fit	Why and when the answer changes
Workforce SSO into Active Directory or LDAP	Keycloak	Keycloak federates users from LDAP or Active Directory and brokers logins to external OIDC or SAML providers under Apache-2.0. The answer shifts toward Zitadel only if you also need its event-sourced audit history or its LDAP and OpenLDAP provider as the main integration point.
B2B SaaS where each customer manages its own users	Zitadel for instance and organization delegation	Zitadel organizations let customers administer their own users within one instance, and each organization can use a different identity provider. Keycloak can also serve this through realms and its Organizations feature, so choose Keycloak if your team already runs realm-based tooling or you want to avoid the AGPL-3.0 review for a modified server.
Customer-facing consumer login	Either, depending on hosted login needs	Both support OIDC, OAuth 2.0 and passkeys in their own ways, and Zitadel documents passkeys with password fallback. Confirm the passkey and branding behavior you need in each product, because consumer login often depends on the hosted login pages you plan to modify.
Regulated internal estate needing SAML and LDAP federation	Keycloak	Keycloak documents SAML 2.0, LDAP and Active Directory federation, and a production database list that most database teams already support. Choose Keycloak when auditors and application owners expect Apache-2.0 terms and a long history of enterprise SSO deployments. Zitadel becomes the stronger choice only if your audit requirement centers on a complete, time-unlimited change history.
Team needing an audit trail of every identity change	Zitadel	Zitadel is built on event sourcing and stores each change as an event, which gives a built-in audit trail. Keycloak records admin events through its own mechanisms, so confirm whether that meets your evidence needs before choosing. This recommendation changes if your legal team cannot accept AGPL-3.0 terms for the server or if you lack PostgreSQL skills.
Small team without Kubernetes experience	Either on virtual machines, with a managed or supported path if needed	Both can run outside Kubernetes: Zitadel supports Linux binaries and Docker Compose, and Keycloak runs from its server distribution. Keycloak's Operator is the recommended Kubernetes route and needs Kubernetes skills, while Zitadel recommends Kubernetes with its Helm chart for high availability. Ask DeployOpen to scope the database and upgrade work before committing to either.

How each platform is built and deployed

Both platforms keep their state in PostgreSQL-class databases and both offer a Kubernetes path, but they divide the work differently. The cards below cover what each one needs underneath it, how high availability is built, and who ends up owning the database and upgrade cycle.

Keycloak's relational database requirement

Keycloak needs a relational database in production, and the default dev-file database is not suitable for production use. Supported engines include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL. Your team chooses the engine, sizes it, and owns backups and restores. Check that your database standard is on the supported list before committing, because the choice shapes your licensing and DBA workload.

Keycloak high availability designs

Keycloak documents three high availability architectures: one cluster optionally spread across availability zones, multi-cluster v2 without an external Infinispan cluster, and the deprecated multi-cluster v1. Both supported designs depend on a synchronously replicated database, which is a hard constraint on your database topology. Plan the external load balancer and test failover before go-live, since the database replication design dictates what you can promise on recovery.

Keycloak Operator installation paths

The Keycloak Operator for Kubernetes and OpenShift installs through Operator Lifecycle Manager, which Keycloak recommends, or with kubectl. The Operator manages Keycloak, realm import and OIDC and SAML client resources, but the database remains outside its scope. Keycloak's documentation strongly recommends manual approval mode for operator updates to avoid unintended upgrades. Confirm who approves operator upgrades in your change process.

Zitadel's PostgreSQL 14 to 18 requirement

Self-hosted Zitadel uses PostgreSQL as its only documented database, with versions 14 through 18 supported. Zitadel's event store also means the database holds the full change history, so storage growth and backup size deserve a sizing review. Choosing a database engine is not a decision you face with Zitadel, but your DBA team still owns backups, restores and version currency. Confirm how your PostgreSQL platform fits this range before you start.

Zitadel's three self-hosting paths

Zitadel documents self-hosting on Linux and macOS binaries, with Docker Compose, and on Kubernetes. Binaries and Compose suit evaluation and smaller footprints, while Kubernetes is the path Zitadel recommends for high availability. Your team should decide early which path matches its platform skills, because moving between them later means migrating a running identity service. Ask Zitadel or your implementation partner to confirm the supported HA topology for your region.

Zitadel's official Helm chart

For high availability, Zitadel recommends a Kubernetes cluster deployed with the official Helm chart. The chart is licensed under Apache-2.0, which keeps deployment tooling separate from the AGPL-3.0 server. Your platform team owns the cluster, ingress, certificates and the PostgreSQL connection values, and Zitadel upgrades become chart upgrades you must test. Confirm how the chart version maps to the server release you plan to run.

Capabilities compared using supplied facts

This table sets Keycloak and Zitadel side by side on licensing, protocols, provisioning, federation, tenancy, audit, databases and self-hosting. Where a capability is not covered by documented facts, the cell names what to confirm with the vendor before you decide. Read it as a shortlist filter: the rows that differ most for your team are usually license, tenancy model and audit requirements.

Capability	Keycloak	Zitadel
License	Apache-2.0 for the server (keycloak/keycloak repository)	AGPL-3.0-only for core, Console and hosted login since v3; APIs, SDKs and Helm charts stay Apache-2.0 or MIT
Protocols	OpenID Connect, OAuth 2.0 and SAML 2.0 as the server's core protocols	OpenID Connect, OAuth 2.0 and SAML 2.0 implemented, plus a device authorization grant
SCIM v2 provisioning	Confirm current SCIM support and scope in the server administration guide for your release	SCIM v2 service provider interface for standardized user provisioning and lifecycle management
LDAP and Active Directory	Federates users from LDAP or Active Directory	Federates login with LDAP, OpenLDAP and Keycloak as upstream providers
Brokering to external providers	Brokers logins to external OpenID Connect or SAML identity providers	Federates login with Entra ID, Okta, Google, GitHub and others; each customer organization can use a different provider
Passkeys	Confirm passkey and WebAuthn options for your release in the server documentation	Passwordless login with passkeys based on FIDO2 and WebAuthn, with fallback to password login
Multi-tenancy unit	Realms, with Organizations as a feature for B2B grouping; confirm the fit for your tenant model	Instances (full data isolation) containing organizations, where projects, users and roles live
Audit model	Confirm audit event retention and export options in your deployment configuration	Event sourcing stores every change as an event, giving a built-in change history over an unlimited period
Supported databases	PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle, Amazon Aurora PostgreSQL, Azure SQL	PostgreSQL 14 to 18 for self-hosted deployments
Self-hosting options	Server distribution on virtual machines or containers, and the Keycloak Operator on Kubernetes and OpenShift	Linux and macOS binaries, Docker Compose and Kubernetes with the official Helm chart for high availability
Migration guides	Confirm migration tooling and import paths with the Keycloak project or your implementation partner	Documented guides from Auth0, Keycloak, Firebase and another Zitadel instance, including just-in-time migration

What the Apache-2.0 and AGPL-3.0 licenses mean for each

Keycloak's server is licensed under Apache-2.0, a permissive license that lets you run, modify and redistribute the server if you keep the required notices. The license file in the repository is the authoritative text for the release you deploy. Keycloak is an open source identity and access management server and a Cloud Native Computing Foundation incubating project. Red Hat also ships the Red Hat build of Keycloak, a supported distribution based on the upstream project that replaces Red Hat Single Sign-On.

Server license: Apache-2.0 applies to the upstream server, so running it in your own cloud accounts, data centers or air-gapped networks carries no commercial license requirement under that license.
Modifications: Apache-2.0 does not require you to publish changes to the server, but attribution and license notices must stay intact when you redistribute.
Red Hat build: The Red Hat build of Keycloak is a separate product with its own subscription and support terms. Its product page showed version 26.6 as the latest, so confirm version alignment with upstream before you plan a move.
Upstream release cadence: Since Keycloak 26.0 the project plans four minor releases a year and says breaking changes in a minor release will be opt-in, which shapes how you schedule upgrades.
Extensions: Themes, custom providers and third-party plugins carry their own license terms and fall outside the server license.

Check the LICENSE file for the exact release you plan to deploy and confirm the license of every extension you add.

How realms, organizations and event sourcing change the B2B design

In Keycloak, the main isolation boundary is the realm. Each realm holds its own users, clients, roles, identity providers and login settings, and the admin console and tokens are scoped to that realm. A B2B product on Keycloak usually runs either one shared realm with customer structure modeled inside it, or one realm per customer where strict separation matters more than operational overhead. Every realm adds configuration to manage, so the number of realms a product runs is a design decision to make early, and it is worth testing how your provisioning pipeline behaves when realms number in the hundreds. Confirm with the Keycloak documentation how the built-in Organizations feature maps onto your tenant model before you commit.

Zitadel separates tenancy into three levels. An *instance* is a virtual tenant with full data isolation, an *organization* sits inside an instance and is where users and projects live, and projects group applications, roles and grants. For a product whose customers manage their own users, the organization is the natural unit: each customer gets an organization, and per-customer identity providers can be attached to it. Use the Zitadel organizations documentation to confirm which administrative rights can be delegated to a customer at the organization level and which stay with the platform team.

Zitadel is built on event sourcing, so each change to users, organizations and settings is stored as an event, which gives a built-in audit trail of all changes over an unlimited period. For audit evidence, this means you can reconstruct what a configuration looked like at a given time, which is a different property from a log of administrative actions. Keycloak records administrative and login events through its event and admin event logging, and forwards them to your logging stack, so the retention, tamper resistance and completeness of that record depend on how you configure and store it. Before choosing, ask your auditor or compliance lead which evidence they need, for example change history, access history or both, and test that each platform produces it in your environment.

What running each platform in production demands

Both platforms are self-hosted and both need a production database, so most of the operating work sits in the same places: the database, high availability, upgrades and observability. The cards below show where the two diverge and who in your team, or your implementation partner, should own each task.

Database administration

Keycloak needs a relational database in production, with PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL among the supported options. Zitadel's self-hosted path uses PostgreSQL 14 to 18 only, and its event-sourced store means the database holds every change as an event. Your database team owns backups, restore tests, sizing and capacity growth. Check whether your standard database engine is on each list before you commit, and confirm with the vendor how event history growth affects backup windows and retention.

High availability and synchronous replication

Keycloak documents a single cluster optionally spread across availability zones, a multi-cluster v2 design without an external Infinispan cluster, and the deprecated v1 design. Both supported designs need a synchronously replicated database, so your platform team must build and test that replication, plus an external load balancer. Zitadel recommends a Kubernetes cluster with the official Helm chart for high availability. Ask an implementation partner or your own platform staff to document the failover test, since the replication topology drives recovery time.

Kubernetes deployment path

Keycloak ships a Kubernetes Operator installed through Operator Lifecycle Manager, which Keycloak recommends, or with kubectl, and it manages Keycloak, realm import and client custom resources. Zitadel's Kubernetes route centers on its official Helm chart, while it also documents Linux and macOS binaries and Docker Compose. Platform staff who already run Operators will find the Keycloak path familiar. Teams without Kubernetes skills should budget for it or ask a partner to build the cluster layer, and confirm which Helm chart version matches the server release you plan to run.

Upgrade cadence and change control

Keycloak plans four minor releases a year and a major release every two to three years, and says breaking changes in minor releases will be opt-in. Keycloak's Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Schema migration runs automatically at startup by default, but large deployments can apply SQL manually. Your change board should set the upgrade window, test each minor release in staging, and confirm how Zitadel's release tags map to its own upgrade guidance before you schedule either platform.

Metrics and observability

Keycloak publishes a metrics guide for its server, so your monitoring team can wire it into existing dashboards and alerting. Zitadel's event store adds an audit trail of changes that your security team may want to query, but how that trail is exported to a SIEM is a question to confirm with the vendor. Decide who owns alert thresholds on login latency and token errors, and whether logs and events feed your existing platform. Both need a named owner before go-live.

Implementation work and who does it

Initial implementation covers hosting, database setup, federation to your directory, protocol clients for each application, and a hardening review. Keycloak's realm model and Zitadel's instance and organization model each need an early design decision, because changing it later is expensive. In-house platform staff can handle routine operation, while a partner such as DeployOpen can plan, implement and document the build under a fixed written scope. Ask any partner for the written deliverables, the handover plan and who keeps the runbooks current after go-live.

What drives the running cost of each platform

The running cost of either platform is mostly people and infrastructure, not licence fees. Keycloak is Apache-2.0 and Zitadel's core is AGPL-3.0, so neither requires a licence purchase to run. The recurring spend comes from the nodes, the production database (Keycloak supports PostgreSQL 14 to 18 among other databases, and self-hosted Zitadel supports PostgreSQL 14 to 18), staff time for upgrades and on-call, and any support subscription you choose. Infrastructure is the most predictable line. Staff time is the least predictable, and it grows with the number of realms or instances, custom authenticators, and identity provider connections you maintain.

Support is where the two platforms differ most. For Keycloak, a supported distribution comes through Red Hat's build of Keycloak, which is a separate subscription. For Zitadel, production use of the core under AGPL-3.0 may need the commercial license that Zitadel offers, so confirm with Zitadel whether your deployment model and embedding plans require it. Check Zitadel's pricing page for current terms, since no figure is stated here. One-time costs include the initial build, database and high availability design, integration of each application and identity provider, and migration of existing users. Recurring costs include the subscription, upgrades (Keycloak plans four minor releases a year), patching, monitoring, and backup testing.

When requesting a quote from DeployOpen, note that DeployOpen publishes no price list and that a quote follows from written scope. Ask for the scope to list each component separately: the number of environments, the database and high availability design, each application and identity provider to integrate, any custom code to maintain, the upgrade cadence, and the on-call expectations. Ask whether the quote covers one-time build work, a recurring retainer for upgrades and support, or both. Also ask which support subscription, if any, the scope assumes, and how a later move between the two platforms would be priced. Your own infrastructure team should confirm the cloud or data center costs, since those sit outside any DeployOpen quote.

Moving from Keycloak to Zitadel, or the reverse, step by step

This sequence moves identities, clients and federated sources from one platform to the other without a single cutover event, so each relying party can be proven on the target before users depend on it. The output is a retired source platform with a documented record of what moved, what was rebuilt and what was verified.

Inventory clients, protocols and user stores
Build a complete list of every relying party, including its protocol (OpenID Connect, OAuth 2.0 or SAML 2.0), redirect URIs, signing certificates, scopes and roles. Record every federated source, such as LDAP, Active Directory or an external identity provider, and note where each user's password or second factor actually lives. Owners of each application should sign off on their entry. Done means every client has one line in the inventory with an owner, and every user store is named.
Decide the tenant model before building
Map how the source platform separates customers and workforce users, such as Keycloak realms, into the target model. Zitadel organizes tenants as instances, organizations inside instances and projects that group applications, roles and grants. Decide whether each Keycloak realm becomes an organization, an instance or a project, and confirm that per-customer identity providers and admin delegation work as your design requires. Done means a signed-off mapping table exists and has been tested against one realistic sample tenant.
Stand up the target platform and its database
Deploy the target in a test environment using a supported deployment method. Self-hosted Zitadel documents Linux and macOS binaries, Docker Compose and Kubernetes, and recommends the official Helm chart for high availability. Self-hosted Zitadel uses PostgreSQL 14 to 18. Confirm the database version, backup and restore procedure, and high availability design with your database team before any user data is loaded. Done means the instance starts, survives a restart and a database restore test, and passes a basic login.
Migrate users and confirm what credentials carry over
Zitadel documents migration guides for Keycloak and other sources, using approaches such as just-in-time migration. Choose between a bulk import and a just-in-time approach for each user store. Confirm in the guide and in a test environment exactly which credential types and password hashes transfer, and which users must re-enroll passkeys or second factors. Users are expected to keep their identifiers and profile attributes where the guide allows. Done means a test cohort logs in on the target with the expected credentials, and every gap is written down.
Rebuild policies, themes and client definitions
Client definitions and their basic configuration are the parts most likely to carry over with adjustment, but confirm that in testing. Rebuild what does not transfer in a usable form: realm or organization structure, authentication policies, authorization rules, custom login themes and branded pages. Recreate each client on the target, then reconfigure the relying party with the new issuer, endpoints, keys and SAML metadata. Done means each relying party's configuration change is recorded and each application completes a full sign-in and sign-out in test.
Run both platforms in parallel
Keep the source platform live while a pilot group of applications and users authenticates against the target. Monitor failed logins, token issuance, session behavior and SAML assertion handling on both sides. Confirm that user changes made on one side are handled as your design expects, because a split source of truth is the most common cause of access errors in this phase. Done means the pilot runs without unresolved authentication defects for the agreed observation period, and the owners of each application confirm acceptance in writing.
Cut over and retire the source platform
Move the remaining relying parties in batches, starting with the lowest-risk applications, and keep a documented rollback path for each batch until its acceptance is signed. Once every client has moved, stop writes to the source platform, take a final backup under your retention rules, and disable its endpoints. Retire the source only after a fixed period of successful operation that your security and compliance owners set. Done means no client points at the old issuer, the final backup is verified, and the decommission record is filed.

Questions buyers ask before choosing Keycloak or Zitadel

Does the AGPL-3.0 license force us to publish our changes to Zitadel?

Only in specific cases. The AGPL-3.0 license applies to the Zitadel core, Console and hosted login that Zitadel moved to AGPL-3.0 with v3.0 on March 31, 2025, according to the Zitadel blog. Its network clause is the point to review: if you modify the server and make it available to users over a network, the modified source generally has to be offered to those users under the same license. Running an unmodified server for internal use creates little obligation. APIs, SDKs, proto definitions, Helm charts and Terraform configurations stay Apache-2.0, so most client code you write is not affected. Keycloak is Apache-2.0, so this specific obligation does not arise. Have your counsel review your modification and distribution plans against the Zitadel LICENSING.md file before you commit.

How long does a migration to Keycloak or Zitadel take?

The duration depends on the number of applications, user stores, protocols and cutover rules, so no fixed timeline applies to every estate. The largest drivers are the number of OIDC and SAML clients that must be re-registered, whether users are migrated in bulk or just in time, and whether passwords and MFA enrollments can move with them. Zitadel documents migration guides from Auth0, Keycloak, Firebase and another Zitadel instance, and describes approaches such as just-in-time migration, which can shorten the period when both systems run. Keycloak's realm export and import and its LDAP or Active Directory federation can shift the work toward directory cleanup. Ask any implementation partner for a written scope that lists each application, the cutover method and the rollback plan, since that document sets the schedule.

Can an in-house team run Keycloak or Zitadel without outside help?

Yes, many teams do, provided they have people who already operate the relevant infrastructure. Keycloak runs from a server distribution on virtual machines or through the Keycloak Operator on Kubernetes, and the Operator is installed through Operator Lifecycle Manager, the method Keycloak recommends, or with kubectl. Zitadel self-hosting covers Linux and macOS binaries, Docker Compose and Kubernetes, and the project recommends Kubernetes with the official Helm chart for high availability. The effort rises with the number of tenants, the upgrade cadence and the on-call expectations. Keycloak plans four minor releases a year, and its Operator documentation strongly recommends manual approval mode for updates. Plan internal ownership for upgrades, monitoring and incident response, not just the first deployment.

What does running either platform require from our database, Kubernetes and application teams?

Each platform needs a production relational database, and that is the first dependency to settle. Keycloak supports PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and others, and its high availability designs require a synchronously replicated database. Zitadel self-hosting uses PostgreSQL, with versions 14 through 18 supported. Your database team owns backups, replication and restore testing. Your platform team owns the Kubernetes or virtual machine layer, load balancing and certificates. Application owners must register clients, define roles and test each login flow after every upgrade. Keycloak can also federate users from LDAP or Active Directory, so directory owners may need to be involved too. Confirm each group's commitment before choosing.

How is the cost of running Keycloak or Zitadel quoted?

A quote follows from a written scope. Both products are open source, so the software license itself carries no fee for Keycloak under Apache-2.0 and Zitadel's core under AGPL-3.0, while Zitadel also offers a commercial license for cases where AGPL terms do not fit. Your cost therefore comes from infrastructure, database operations, implementation, customization, integration, testing, documentation and ongoing support. Infrastructure and database costs recur each month. Implementation is usually one-time, while upgrades and support recur. DeployOpen does not publish a price list. Ask every vendor, including DeployOpen, to itemize the work in the scope, the environments covered, the support hours and the assumptions about your identity sources and applications. Check Zitadel's pricing page for any commercial terms you need to confirm.

Do Keycloak realms or Zitadel organizations fit our B2B model?

The better fit depends on whether your customers should manage their own users and identity providers. In Zitadel, an organization is comparable to a tenant in a SaaS system, and several organizations can exist within one instance, which suits B2B products whose customers manage their own users. Zitadel also lets each customer organization use a different identity provider. Keycloak models tenants as realms, each with its own users, clients and settings, and its Organizations feature is a separate consideration you should test. Realms give strong separation but increase administration per tenant. Organizations within one realm reduce that load but need careful role design. Build a small proof of concept with two sample customers, each with its own identity provider, and check the delegation model your customers need.

When should we bring in an implementation partner for Keycloak or Zitadel?

Bring in a partner when internal capacity, time or security review requirements are tight, or when the migration crosses many applications and identity sources. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen also prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications. Ongoing support, upgrades and continuous testing are available as retainers. Ask for a written scope that names the environments, the identity sources, the applications and the handover documentation before you decide.

Which is easier to upgrade over time, Keycloak or Zitadel?

Both need a deliberate upgrade process, and the difference lies in release cadence and schema handling. Keycloak plans four minor releases a year and a major release every two to three years, and says breaking changes in a minor release will be opt-in. Keycloak migrates its database schema automatically at startup by default, and it also supports manual migration, which its upgrading guide suggests for large deployments. Zitadel publishes releases on its GitHub releases page, and its current release is v4.19.5. Your upgrade effort depends on the number of custom extensions, themes, client integrations and the size of your test environment. Ask each vendor for its documented upgrade and rollback procedure before you commit.

How DeployOpen works on this

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Keycloak vs Zitadel, that means starting from your tenancy model, license position and database standard, then building and documenting the platform you actually choose.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We confirm whether you need realms or organizations, and whether your customers manage their own identity providers.
We review the AGPL-3.0 position for Zitadel and the Apache-2.0 terms for Keycloak against how you modify or embed the server.

How we build

We deploy into your cloud accounts, data centers or air-gapped network, with the database you have chosen for production.
We configure protocols, identity brokering or per-customer identity providers, and SCIM provisioning where your applications need it.
We test login, token, audit trail and high availability behavior against your own applications before go-live.

How we hand over

We document architecture, tenancy design, configuration, backup and restore steps, and the upgrade procedure for your team.
We prepare the controls and evidence your compliance assessors will ask for, without issuing any audit report or certification ourselves.
We walk your platform and security engineers through administration, so routine changes stay in your team's hands.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers once the platform is live.
Upgrade planning covers each platform's release cadence and the database migration approach you select.
Ask for a written quote that lists scope, deliverables, testing, documentation and handover, so cost follows from that scope.

Keycloak vs Zitadel