Auth0 cost vs self-hosted ZITADEL or Keycloak

Where Auth0 cost ends and self-hosting cost begins

A renewal, a plan change or a data residency requirement is usually what forces a cost review of Auth0, and the honest answer to whether self-hosting ZITADEL or Keycloak costs less is that it depends. It depends on monthly active users, the number of enterprise connections you must maintain, the availability target you have to meet and the engineering time you can spare to run the platform. Auth0 bundles those items into its plan, so the comparison is only fair when you price each one on the self-hosted side as well. Both open-source cores carry no licence fee, but the terms differ. Keycloak is licensed under Apache License 2.0, which permits modification and redistribution with few obligations. ZITADEL moved its core, Console and hosted login to the GNU Affero General Public License 3.0 with v3.0, while its APIs, SDKs and Helm charts remain Apache 2.0. If your team modifies the ZITADEL core and offers it to users over a network, have counsel confirm what the AGPL requires before you commit. Commercial distributions also carry fees: the Red Hat build of Keycloak is a supported product with its own subscription, and hosted or enterprise editions of either project are priced separately.

Software licence is usually the smallest recurring line once you self-host. The larger lines are people and infrastructure: the engineers who patch and upgrade the platform, the PostgreSQL service that Keycloak and ZITADEL both need (ZITADEL supports PostgreSQL 14 through 18), the load balancers and nodes for a highly available cluster, backups, monitoring, and on-call coverage. Keycloak also requires a synchronously replicated database for its supported high availability designs, which raises the infrastructure line. Ask for each of these as a separate estimate in any quote, and mark which items are one-time (installation, migration, hardening) and which recur (hosting, upgrades, support contracts, staff time). Before you compare totals, write down your expected monthly active user growth, the count of enterprise identity providers you need, and the uptime you must commit to customers. Those three inputs change the answer more than any licence term. Then ask your current vendor for a written view of the same figures, and ask a self-hosting partner for a fixed-scope quote that lists each component above.

Which cost components change when you self-host customer login

This table sets each Auth0 cost component against its ZITADEL or Keycloak counterpart and marks whether it is one-time or recurring. Neither Keycloak nor ZITADEL charges a licence fee to download, so the comparison turns on who is paid for infrastructure, support and engineering time. Read it as a checklist to fill in with your own user counts and quotes.

Cost component	Auth0 side	ZITADEL or Keycloak side	One-time or recurring
Subscription or licence	Paid plan tier billed by Auth0 (Okta), with the Free tier excluded from some features such as password hash exports	No licence fee to download. ZITADEL core is AGPL-3.0 and Keycloak is Apache 2.0. Optional vendor support contracts are separate	Auth0: recurring. Open source: none for the software
MAU or user-based charges	Metered by monthly active users, so spend rises as active login volume grows	No per-user software charge. Cost grows with compute, storage and database size as users increase	Auth0: recurring and scales with users. Self-hosted: recurring infrastructure only
Add-on features (Organizations, enterprise connections, advanced security)	Organizations, enterprise connections and advanced security sit in plan tiers or add-ons. Confirm current inclusions and limits with Auth0 in writing	ZITADEL organizations and Keycloak's Organizations feature are part of the software. Confirm feature coverage against your requirements in your own test	Auth0: recurring. Self-hosted: one-time configuration effort
Infrastructure (compute, network, backups)	Included in the vendor service	Virtual machines or Kubernetes nodes in your cloud account or data center, plus load balancers, DNS and backup storage	Recurring
PostgreSQL	Not applicable (vendor-managed data store)	Required for ZITADEL (PostgreSQL 14 to 18 supported). Keycloak supports PostgreSQL 14 to 18 among other databases. Managed or self-run options each carry their own cost	Recurring, plus one-time setup
High availability	Included in the vendor service. Confirm the availability terms in your contract	Multiple nodes, a Kubernetes cluster with the official ZITADEL Helm chart, and a synchronously replicated database for Keycloak clustering	One-time design, then recurring capacity
Implementation and configuration	Tenant setup, Actions or Rules, connections and application SDK integration	Realm or instance design, identity provider federation, login flows, branding and client configuration	One-time, usually the largest upfront item
Migration of users and password hashes	Bulk user export through the Dashboard or Management API. Password hashes need a support request on paid plans, with no guaranteed delivery date	Migration guides and just-in-time approaches for ZITADEL. Keycloak imports exported users and hashes. Test hash compatibility before cutover	One-time
Support	Included with the plan at the level your contract states	Community support is free. Commercial support or a retainer with a vendor or partner is paid by you. Ask for response terms in writing	Recurring if you buy support
Upgrades and testing	Handled by the vendor, with change notices from Auth0	Your team or a partner applies releases, tests login flows and manages database migrations. Keycloak plans four minor releases a year	Recurring
Internal engineering skills	Administrators configure the tenant and follow vendor documentation	Staff who run Kubernetes or Docker, PostgreSQL, monitoring, backups and incident response on identity infrastructure	Recurring staff time, often the largest ongoing cost

How Auth0 plan tiers, Organizations and enterprise connections add cost

Auth0 cost grows along several axes at once, and the largest lever is usually the plan tier combined with monthly active user (MAU) counts. Each tier carries its own MAU allowance, feature set and overage terms, so the first task is to pull the current plan limits from your Auth0 contract and recent invoices rather than relying on memory or on older pricing pages, because these terms change. Record how many MAUs you billed in each of the last several months, not just the peak, and note which features your applications depend on, such as custom domains, MFA, or advanced attack protection. Those features often decide which tier you must buy, even when user counts alone would fit a cheaper one.

B2B growth adds a second cost axis. Organizations and enterprise connections such as SAML or OIDC single sign-on per customer are typically gated by plan level or sold as add-ons, so every new enterprise customer can change the bill. Ask your Auth0 account team in writing which Organizations limits, connection limits and add-ons apply to your contract, what triggers an overage, and which add-ons teams commonly enable after launch, such as extra log retention or additional environments. Mirror the same questions for ZITADEL and Keycloak in your model: on those platforms the recurring cost is infrastructure, database and staff time rather than a per-user meter.

Plan the password hash export as a cost and risk item, not a footnote. Auth0 does not include password hashes in standard user exports. Paid plans can request them through a support ticket, Auth0 does not guarantee a delivery date, and the option is not available on the Free tier. If you need users to keep their passwords after a move, budget engineering time for waiting on that ticket, for testing imported hashes, and for a fallback where users reset passwords. Confirm the request process and expected turnaround with Auth0 in writing before you commit to a migration date, and keep that answer in your cost review.

What moves the Auth0 vs Keycloak or ZITADEL comparison

The cost gap between a hosted Auth0 tenant and a self-hosted ZITADEL or Keycloak deployment depends on a small set of variables. Each one shifts spending between subscription fees and the people, infrastructure and support that a self-hosted service requires.

Monthly active user growth

Auth0 bills by monthly active users, so spend rises with every new active account and tier change. Self-hosted cost is driven mainly by infrastructure sizing, database capacity and on-call effort, which grow in steps rather than per user. Ask Auth0 for the price of your current MAU band and the next two bands, then model the self-hosted footprint for the same user counts. Illustrative: a consumer app growing quickly pushes cost toward the MAU side, while a stable B2B base favors self-hosting.

Organizations and per-customer identity providers

B2B SaaS teams that give each customer its own members, login connection and domain multiply configuration, support tickets and token mapping work. ZITADEL structures tenants as instances, organizations and projects, and Keycloak models tenants as realms. Both can carry this load, but the chosen model determines how many realms or instances you run and how much automation you need to provision them. Check the cost of Auth0 Organizations on your plan and the operational effort of onboarding each new customer in your chosen self-hosted model.

Enterprise SSO connections

Each enterprise connection, whether SAML or OIDC to a customer's identity provider, can be a separately priced item on hosted plans and a configuration and testing task on self-hosted systems. Self-hosted cost moves with the number of connections you must test, renew certificates for and troubleshoot. ZITADEL and Keycloak both support federation to external providers, so confirm which connection types your customers require and whether those types appear on your Auth0 plan.

Availability and recovery targets

A self-hosted identity service becomes a critical dependency for every login, so the cost of high availability is a direct function of your uptime target. Keycloak's supported high availability designs require a synchronously replicated database, and ZITADEL recommends Kubernetes with the official Helm chart for high availability. Hosted Auth0 carries availability within its service terms. Ask Auth0 which uptime commitment your plan includes, and budget for redundant nodes, a replicated PostgreSQL cluster, tested failover and a restore procedure you have rehearsed.

Log volume and retention

Login events, audit trails and security logs accumulate with user volume and the retention period your compliance program requires. Hosted plans may limit retention or charge for log exports, while a self-hosted deployment stores logs on storage you buy and operate, plus the SIEM that receives them. Confirm the log retention your auditors expect, how long Auth0 keeps logs on your plan and the volume your login traffic generates. Storage, indexing and log shipping are the self-hosted line items to estimate.

Skills already on the platform team

The largest self-hosted cost is often the time of engineers who operate the identity service, not the software license. A team that already runs PostgreSQL, Kubernetes and OIDC integrations will absorb upgrades, backups and incident response at a lower cost than a team learning these skills during the migration. Keycloak releases four minor versions a year, and its Operator recommends manual approval for updates, so upgrade effort recurs. Assess your team's existing experience, decide who owns on-call for identity, and price that role into the comparison.

What running ZITADEL or Keycloak costs in engineering time

ZITADEL is a single server product with three documented deployment paths: Linux and macOS binaries, Docker Compose, and Kubernetes. The official Helm chart is the route the vendor recommends for high availability, so a team that already runs Kubernetes will spend its effort on chart values, ingress, secrets and backups rather than on a new platform. Every path stores state in PostgreSQL, and ZITADEL supports PostgreSQL 14 through 18, so the database version must be chosen against your existing support policy before installation.

Deployment path: Binaries and Compose suit a pilot or a single-node service. A production tenant base that must survive node loss points to Kubernetes with the Helm chart, which adds cluster operations to the scope.
Database ownership: Decide who runs PostgreSQL, its backups, failover and patching. A managed PostgreSQL service shifts that work to the provider but adds a recurring fee.
Instance count: An instance is a virtual tenant with full data isolation. Running one instance per customer multiplies upgrades, monitoring and backup jobs, while organizations inside one instance keep the operational footprint small.
Project design: Projects group applications, roles and grants. Poor project design shows up later as role sprawl that application teams must untangle during each migration or audit.
Licensing review: The core is AGPL-3.0, so the legal review of modifications and hosted use is an upfront task for legal counsel.

Before you request a quote, confirm the supported PostgreSQL versions against your database standard, and ask for the expected instance model and how each deployment path will be backed up and restored.

Keycloak is a Java server whose effort profile depends on the database, the high availability design and the Operator. Its supported production databases include PostgreSQL 14 to 18, along with MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Aurora PostgreSQL and Azure SQL. The default dev-file database is for development only, so production effort starts with choosing one of these supported engines and standing it up with replication.

High availability architecture: Keycloak documents a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without external Infinispan, and the deprecated multi-cluster v1 that used a separate Infinispan cluster per site. Both supported designs need a synchronously replicated database, which constrains database and network design and often adds cost.
Operator and approval mode: The Keycloak Operator is installed through Operator Lifecycle Manager, with kubectl, or with an experimental Helm chart. It manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources. The documentation strongly recommends manual approval mode for operator updates, which means someone must review each upgrade.
Release cadence: Since Keycloak 26.0 the project plans four minor releases a year and a major release every two to three years, with breaking changes in minor releases made opt-in. Each release is a recurring testing cycle for your realms and custom providers.
Schema migration: Keycloak migrates its schema at startup by default, while large deployments can apply the SQL manually. Choosing manual migration adds a change step but gives a reviewable change record.
Export limits: The kc.sh export and import commands are not a complete backup mechanism, and all nodes must be stopped while they run. Plan database-level backups and restore tests instead.

Before you request a quote, ask for the high availability design, the database engine and replication model, and the upgrade calendar and approval process that the proposal assumes.

How to build the comparison with your own numbers

This sequence turns Auth0's pricing and your own usage into a three-year cost model, so that Auth0, ZITADEL and Keycloak are compared line by line on the same assumptions.

Export current usage and contract facts from Auth0
Platform or identity owners pull the current monthly active user count, the number of enterprise connections, and the Organizations count from the Auth0 dashboard and the current order form or contract. Record the plan tier, the contract term and the renewal date next to each figure. Confirm the counting rules for monthly active users with Auth0 in writing, because the billable definition controls the result. The step is done when every usage figure has a source document and a date attached.
Inventory every add-on and connection in use
Engineering and product leads list each Auth0 feature your applications depend on, such as Organizations, enterprise connections, custom domains, MFA, attack protection, log streaming and any Enterprise add-on named in the contract. For each item, note which applications use it and whether it is required for login or only for reporting. Ask Auth0 which items are included in your tier and which are billed separately. The step is done when you have a single list where each add-on is marked as required, optional or unused.
Define availability and recovery targets
Security, operations and the business owner agree on the uptime expectation for login, the acceptable recovery time after a failed node or database, and the acceptable data loss window for user records. These targets decide how many nodes, which database layout and which backup frequency the self-hosted option needs. Keep the targets written down, since a design that meets them is more expensive than one that does not, and that difference belongs in the model. The step is done when the targets are approved and attached to the comparison.
Price infrastructure and PostgreSQL at your own rates
The cloud or data center team prices the compute, load balancing, storage, backups and network for a ZITADEL or Keycloak cluster that meets the targets, using your negotiated rates rather than list prices. Include a highly available PostgreSQL deployment with the replication your design needs, since Keycloak documents that its supported high availability designs require a synchronously replicated database. Price each environment separately, including staging, and mark which costs are one-time setup and which recur monthly. The step is done when infrastructure has a monthly figure per environment with the rate card cited.
Estimate engineering hours for operations
The platform team estimates the annual hours for installation, version upgrades and testing, database maintenance, monitoring setup, security patching, backup restore tests and on-call coverage. Use the Keycloak release cadence as an input, since the project plans four minor releases a year, and add time for reviewing opt-in breaking changes. Record the hours by role, then convert them with your internal loaded cost. The step is done when each recurring activity has an hours estimate and an owner.
Decide whether a support contract is needed
Platform leads decide whether the team can carry the operational risk alone or needs a vendor or partner support contract for incidents, upgrades and security fixes. Compare community-only options with paid support tiers from the vendor or a partner, and check which tiers include service levels and which are ticket-based. If a contract is needed, request its price and scope in writing and add it as a recurring line. The step is done when the support decision is recorded with its reason and its cost line, or with a note that none is required.
Model three growth scenarios over three years
Finance and the platform lead build three user growth scenarios, such as flat, moderate and fast growth in monthly active users, over a three-year horizon. For each scenario, calculate the Auth0 cost from the plan tiers and add-ons, and the self-hosted cost from the infrastructure, database, engineering and support lines, noting where a step increase in capacity changes the infrastructure line. Label any scenario as illustrative if it is not based on your forecast. The step is done when the three scenarios produce a yearly total for each option with the assumptions listed beside them.
Separate one-time migration cost and request line-item quotes
Keep migration costs, including export, password hash handling, connection rebuilding, application changes and testing, in a separate table from recurring operating costs, so that the three-year totals are not mixed with one-off project spend. Request line-item quotes from Auth0 for the same plan and add-ons, and from DeployOpen for implementation, hardening and support based on a written scope, so both sides list the same components. Compare the totals only after each quote uses the same user counts, horizon and availability targets. The step is done when the one-time table, the recurring table and the quotes reconcile to the same assumptions.

Costs teams forget on each side of the comparison

Auth0 invoices are only part of the picture. Exit work on the Auth0 side and day-two operations on the self-hosted side both carry costs that rarely appear in a first comparison. The cards below list the items to price before choosing a path.

Export and migration effort

Bulk user exports through the Dashboard or the Management API produce NDJSON or CSV files, but standard exports do not include password hashes. Those hashes require a support ticket on paid plans, and Auth0 does not guarantee a delivery date, so the timing belongs in your migration plan. Ask who on your side owns the ticket, the verification of imported users and the fallback if hashes arrive late.

Rebuilding Actions and tenant configuration

Auth0 Actions, rules, connections, applications and custom domains do not move as data. Each one has to be recreated and tested in the target, usually by engineers who know the flows well. Inventory every Action and connection before you estimate effort, because the work scales with the number of login flows rather than the number of users.

Contract renewal timing

Auth0 costs recur as long as the tenant is active, and a move needs a parallel run that overlaps two bills. Check your notice period and whether plan tier changes apply mid-term. Start the export and migration plan early enough that renewal does not force a rushed cutover.

Backup and restore testing

Keycloak documents that its realm export and import process has limitations as a backup and restore mechanism, and that all nodes must be stopped while it runs. Budget for a database-level backup strategy, plus recurring restore tests in a non-production environment. Confirm the recovery time you need before you accept the design.

Staged upgrades and manual approval

The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Plan for a staging environment, change windows and regression testing of login flows on each minor release, because that work recurs for the life of the system. Schedule it as a standing cost, not an occasional task.

Certificate, secret and monitoring upkeep

Signing keys, TLS certificates, client secrets and database credentials all expire or need rotation, and a missed rotation can lock out every application at once. Monitoring and alert tuning also take ongoing effort, since login metrics need thresholds that separate normal peaks from attacks. Assign owners for both, and include security testing of the login surface, such as token handling and redirect rules, in the recurring plan.

What the one-time migration adds to the first-year bill

Migration is a one-time cost, and it belongs in a separate line of the business case. It sits on top of the recurring costs of running ZITADEL or Keycloak and of the Auth0 subscription you keep paying while you move. Model it as its own block with its own owner, so the first-year total is not mistaken for the steady-state run rate. Most of the work is in the source tenant: the bulk user export job, the separate password hash request, and the reconfiguration of every connection and login flow. Start with the export. Auth0 can produce a users export job from the Dashboard or through the Management API (POST /jobs/users-exports) in NDJSON or CSV format, as described in the Auth0 bulk user export documentation. Password hashes are not in that file. On paid plans they require a separate support ticket, the delivery date is not guaranteed, and the option is not available on the Free tier. Confirm with Auth0 whether that request is included in your plan or handled as a chargeable service, and plan for users who must reset passwords if the hashes never arrive.

Then budget for the parallel-running period, which is usually the largest unplanned item. Both systems must accept logins while applications move over, and each customer organization that uses its own enterprise connection must be recreated as an identity provider on the new platform. ZITADEL documents migration approaches such as just-in-time migration, which can reduce the bulk work but still needs testing per application. Keycloak imports realms from JSON with kc.sh import, but the export and import guidance warns about its limits as a backup mechanism, so treat it as a migration tool rather than a permanent data path. The one-time cost grows with the number of applications, custom Actions and enterprise connections, because each one needs its own rebuild and test. Before you sign anything, ask each vendor what migration help is included, whether hash import support is part of a service, and what a fixed-scope engagement would cover. Confirm the answers in writing, since they set the one-time line in your first-year total.

Questions buyers ask before comparing Auth0 cost with self-hosting

How much more effort is self-hosting ZITADEL or Keycloak than running Auth0?

Self-hosting moves work from the vendor to your team, so the effort is larger and it recurs. Auth0 handles the hosting, database, patching and availability of the service, and you pay for that through monthly active user (MAU) plans. With ZITADEL or Keycloak, your team owns the runtime, the PostgreSQL database, the cluster, certificates, backups, monitoring, and every upgrade. Keycloak's documentation describes three high availability designs, and both supported designs need a synchronously replicated database. Ask your platform team to estimate hours per month for operations and to list which of these tasks they already perform for other services.

Can our team run ZITADEL or Keycloak without outside help?

A team with Kubernetes, PostgreSQL and identity protocol experience can run either product, but the first deployment and the first upgrade are where gaps show. ZITADEL documents self-hosting with Docker Compose or Kubernetes and recommends the official Helm chart for high availability. Keycloak offers an Operator that manages Keycloak and client custom resources. The skills that matter most are OIDC and SAML configuration, secrets handling, and incident response for the login path. If those skills are thin, a fixed-scope implementation can cover design, hardening and handover before your team takes over.

How long does a migration from Auth0 take, and what drives that time?

The duration depends mostly on the work outside the user export, not on the export itself. Auth0 can export users as NDJSON or CSV through the Dashboard or the Management API, but password hashes require a support request on paid plans, and Auth0 does not guarantee a delivery date for them. Other drivers include how many Actions and Rules must be ported, how many social and enterprise connections need recreating, how many applications change SDKs, and how much testing your login flows require. Ask for a written scope that lists each of these items before agreeing to a timeline.

What does the platform team need to provide for a self-hosted identity service?

The platform team provides the infrastructure, the operational process and the people on call. Typical needs include a Kubernetes cluster or container hosts, a PostgreSQL service (ZITADEL supports versions 14 through 18, and Keycloak lists PostgreSQL 14 to 18 among its supported databases), load balancing, TLS certificates, a secrets store, centralized logs and metrics, and a tested backup and restore procedure. Keycloak's export and import commands are documented with limitations as a backup mechanism and require all nodes to be stopped while they run, so plan backups at the database layer. Confirm these needs with your own infrastructure owners before comparing costs.

Can our existing database team run PostgreSQL and high availability for the identity service?

Often yes, but the identity service adds requirements the database team should review before accepting the work. Both products use PostgreSQL, and both documents describe supported versions and production configuration. Keycloak's high availability designs require a synchronously replicated database, which affects replica placement and failover testing. The database team should agree on backup retention, point-in-time recovery, connection limits and maintenance windows that match the login service's availability target. Ask them to confirm which PostgreSQL versions they support and whether they already run synchronous replication for other production systems.

How should we plan for Keycloak and ZITADEL upgrades?

Plan upgrades as a recurring workload with test environments, release reading and a rollback path. Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, and it says breaking changes in minor releases are opt-in. Keycloak's Operator documentation strongly recommends manual approval mode for operator updates, and its database schema migrates automatically at startup by default, with a manual option for large deployments. ZITADEL publishes frequent releases on GitHub, and its license changed with v3.0, so check release notes and licensing terms at each major step. Budget staff time for regression testing of every login flow.

Do we need a support contract to run ZITADEL or Keycloak in production?

No contract is required by the open-source licenses, but the decision depends on who answers when the login path fails. Keycloak is Apache 2.0 licensed and ZITADEL is AGPL-3.0 with Apache 2.0 and MIT exceptions for specific directories, so you can run both without a subscription. Red Hat sells a supported distribution of Keycloak, and ZITADEL publishes its own pricing page for commercial options. For a support decision, compare the response commitments in each written offer against your uptime requirements, and confirm whether the license terms affect any modifications you plan to make.

When does a fixed-scope implementation make sense instead of doing the work internally?

A fixed-scope implementation makes sense when the scope, deliverables and timeline can be written down before work starts and when your team lacks capacity or experience for the first build. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope with written deliverables. Ongoing support and upgrades can follow as a retainer. Ask for a written scope that covers the migration of users and password hashes, the high availability design, backup testing, and handover documentation, and compare that quote with the internal effort estimate.

How DeployOpen scopes a fixed-price Keycloak or ZITADEL implementation

DeployOpen plans, implements, hardens, backs up and documents self-hosted identity platforms inside your own cloud accounts, data centers or air-gapped networks. For a move off Auth0, we start from a written scope that compares your current monthly active user volume, plan features and integrations against the chosen self-hosted platform.

How we scope

We inventory Auth0 tenant features in use, including Organizations, enterprise connections, Actions and custom domains.
We size the self-hosted target for your user growth, with PostgreSQL, high availability and backup requirements written into scope.
Engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing before work starts.

How we build

We deploy ZITADEL or Keycloak on your infrastructure, using Docker Compose, Kubernetes or the Keycloak Operator as agreed.
We rebuild identity providers, organizations or realms, and recreate login flows and application client configurations.
We test login, token claims, provisioning and failover against your own applications before any cutover.

How we hand over

We document the architecture, runbooks, upgrade procedure and the database backup and restore process for your team.
We provide the cost component breakdown and the operating model so you can compare recurring running costs with your Auth0 invoices.
We prepare control evidence for your compliance assessors, while independent auditors and certification bodies issue any attestation.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
We can plan upgrades around the Keycloak release cadence or ZITADEL release notes, and confirm each change in a test environment.
Ask us to confirm which support scope, response commitments and environments your quote covers before you sign.