Zitadel upgrades and support

The upgrade cannot be planned safely until the client supplies the items below, and each one needs a named owner on the client side. Start with the running deployment. DeployOpen needs read access to the live Zitadel deployment and its configuration, plus the Helm values file or Docker Compose files that produced it. The platform or infrastructure team that operates the cluster or hosts usually owns these. Without them, the upgrade plan rests on documentation that may not match production. Check for drift now: settings changed directly in the cluster, but not in the Helm values, will be overwritten or missed during a chart upgrade, so the team should reconcile them before the change window.

Next, the database. Provide the PostgreSQL version and the date and result of the most recent full backup. The database platform or DBA team owns this. Confirm that the running version falls within the range Zitadel documents for self-hosting (versions 14 through 18 at the time of writing), because a version change during the upgrade adds work and risk. Ask whether a restore has been tested, not just whether backups run. A backup that has never been restored gives the rollback plan no solid basis. Also confirm who can take a snapshot at the moment of cutover and how long that takes to complete.

The client also needs a staging environment that can hold a copy of production data, including the user and event tables that database migrations touch. The platform team owns the environment, and the data protection owner must approve any copy of personal data, along with masking rules and retention limits. If staging holds only synthetic data, the migration is rehearsed against different data volumes and shapes than production. If no staging environment exists, the migration risk moves into the production change window, which is the wrong place to discover a problem. Agree the staging refresh date before the rehearsal is scheduled.

Provide a list of every OIDC and SAML client and every identity provider connected to the instance, with an owner for each. Application owners own their clients, and identity administrators own each federated provider, including Entra ID, Okta, Google or LDAP where they are in use. For each client, record redirect URIs, grant types and the organizations that depend on it. Also grant access to the identity provider admin consoles so testers can run test logins, with test accounts that carry the same MFA and policy settings as production. Without this list, nobody can confirm which logins to test, and a broken client is often first reported by a user.

Name one decision maker for change windows. This person approves the window, accepts the risk of cutover and calls a rollback during the event, so the role should sit with someone who can act without waiting for a committee. Then agree a rollback window in writing. The document should state how long after cutover a rollback remains possible, who authorizes it, and how data written to the upgraded instance during that period will be preserved or reconciled if the team returns to the earlier version. Settle these points before the change window is booked. Deciding them during an incident leaves the team without authority or a shared understanding of what a rollback costs.

Go-live is the start of recurring work, not the end of the project. A self-hosted Zitadel instance needs someone to watch it, respond when it misbehaves, restore it when it has to be restored, and move it forward on the v4 line. Whether your team or a partner carries that load, the work itself is the same. Before you compare options, list the recurring tasks and assign each one an owner in writing. The core tasks are monitoring and incident response, backup and restore tests, applying upgrades and patches, certificate and secret rotation, identity provider and client changes, access reviews, and evidence collection for assessments. Monitoring should cover login errors, token issuance, the PostgreSQL database and the Kubernetes or Docker runtime. Backup tests matter more than backup jobs: a restore into a separate environment is the only proof that a backup works. Secret rotation covers TLS certificates, database credentials and the credentials used by applications and identity provider connections.

The volume of this work depends on your design choices. Each customer organization, each federated identity provider and each registered application adds changes to track, and each one needs a review when its owner leaves or its configuration shifts. Upgrades carry two parts: the Zitadel release itself and any database migrations it runs. Zitadel documents PostgreSQL versions 14 through 18, so your database upgrade plan has to be checked against the Zitadel release you are moving to. Check the current v4 release notes and the GitHub releases page before each planned change, and rehearse every upgrade on a copy of production data first. Keep an upgrade calendar that names the test environment, the rollback point and the person who signs off. Record the result of each restore test and each access review in the same place, so that the evidence is produced as a side effect of operations rather than rebuilt during an audit.

There are two main sources of support. The first is a DeployOpen retainer, which covers ongoing support, upgrades and continuous testing inside your own infrastructure. Retainers are scoped in writing, so the decision is which of the recurring tasks above the retainer covers, which stay with your team, and how requests and incidents are routed between the two. The second source is Zitadel's own Enterprise plan, which the Zitadel pricing page describes as offering custom support agreements and technical account management. Enterprise pricing is custom and is listed for both self-hosted and cloud deployments, so ask Zitadel for a written statement of what it covers, how it treats your self-hosted version, and who is accountable for upgrade questions. The two options can overlap or complement each other. Clarify which party handles vendor escalations and which handles configuration work in your environment before signing either agreement.

The Zitadel pricing page lists ISO 27001, SOC 2 Type II and OpenID certification. Treat these as claims to verify, not facts to rely on. Confirm the current status directly with Zitadel, ask for the scope of each certification or report, and check whether it covers the software you will run or only Zitadel's own cloud operations. A vendor certification does not transfer to your self-hosted deployment, which your organization still has to assess against its own controls. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask your assessor early which evidence they expect from the identity platform, such as access review records, change records and restore test results.

Recurring cost has several components, and they are paid to different parties. Your internal staff time covers monitoring, approvals, access reviews and coordination. Infrastructure costs cover the Kubernetes or Docker hosts, PostgreSQL, backup storage, monitoring and log retention, and they recur every month. Retainer fees, if you buy them, are set from the written scope and recur on the agreed cycle. Enterprise subscription fees from Zitadel are custom and also recur. Upgrade and restore testing has a one-time setup cost for the test environment and a smaller recurring cost each time you run the tests. When you ask for a quote, request a list of included tasks, the response process for incidents, how upgrades and database migrations are tested, what is excluded, and how changes to scope are priced. Ask which costs are fixed and which change with the number of organizations, identity providers and applications you run.