Zitadel high availability guide

Why Zitadel high availability starts with the database and the cluster

High availability for Zitadel on Kubernetes means running several Zitadel instances so that sign-in keeps working when one pod, node or availability zone fails, and making sure the database and backups can survive the same failures. Zitadel documents Kubernetes with its official Helm chart as the recommended path for high availability, so that is the starting point for most teams. If you run or plan self-hosted Zitadel for customer or workforce login, you probably cannot accept a single point of failure, because every application that depends on Zitadel stops signing users in when login stops. Before design begins, agree the availability target with the owners of those applications. Write down how long a login outage is tolerable, which functions must keep working during an incident, and who decides when a failover is declared.

The hard part is usually not adding pods. Zitadel uses PostgreSQL as its database, and its self-hosting documentation supports PostgreSQL versions 14 through 18. Confirm which version your platform team has standardized on and which versions your managed or self-managed database service offers before you choose a topology. The database decisions carry most of the weight: whether to use a managed service or run the cluster yourself, how many replicas to keep, whether replication is synchronous or asynchronous, how failover is triggered and how connections are pooled. Zitadel's application pods can be scaled out, but every replica depends on the same database, so a database that cannot fail over cleanly limits the whole design no matter how many pods you add.

Backups need the same scrutiny as the cluster. A backup is only proven by a restore, so schedule restores into a separate environment and time them against the recovery target you agreed. Test point-in-time recovery if your database service offers it, and rehearse promoting a replica during a planned window so the runbook is not written for the first time during an incident. Back up the Kubernetes secrets, Helm values and any keys or certificates the deployment depends on, along with the database itself. A restored database without the configuration Zitadel needs to start is not a recovered login service. Record who can run the restore, where the credentials are kept and how the result is verified, including a sign-in test against the restored instance.

Cluster design determines whether a single node or zone failure becomes a login outage. Spread Zitadel replicas across nodes and zones with pod anti-affinity or topology spread constraints, set pod disruption budgets so that node drains during maintenance keep enough replicas running, and configure readiness and liveness probes that match the health endpoints in the chart version you deploy. Put the ingress or load balancer in front of Zitadel under the same failure model, and confirm how TLS is terminated and whether that component is highly available itself. Verify these settings against the values in your chart version and do not assume defaults. Then test them by draining a node and watching sign-in during the drain.

Turn these points into decisions before the build starts. Agree the availability target, choose the database topology and its owner, set the restore test cadence and the recovery time you expect to meet, and write a failover runbook that names who acts. Plan upgrades with the same care, because a Helm rollout or a database migration is a common source of outage in an otherwise redundant design. Ask your implementation partner how each of these items appears in the scope, the test plan and the operating handover. Ask which checks they will run in your own environment and which ones they expect your team to repeat.

Which components must be redundant for Zitadel high availability

A highly available Zitadel depends on more than running several identity pods. Each component below holds part of the login path, from the DNS name clients use to the database that stores tenant and user state. Check each one in the version you deploy, because a single weak link can take sign-in down even when the pods are healthy.

Zitadel API and login pods

These pods serve the API, Console and hosted login, and they are deployed from the official Helm chart. Redundancy here only helps if the pods are stateless with respect to sessions and configuration, so confirm where each kind of state lives in your version. When a pod fails, the risk is dropped logins or failed token requests during rollout, so test rolling restarts under load. Confirm how the chart handles pod disruption budgets and readiness probes.

PostgreSQL cluster

PostgreSQL is Zitadel's database, and most durable state, including instances, organizations, users and grants, lives there. Its high availability design, failover method and replication mode determine how long sign-in can be impaired after a primary fails. Confirm that your PostgreSQL major version falls within the range Zitadel supports for your release, and test failover with the connection settings the pods actually use.

Ingress, load balancer and TLS termination

The ingress or load balancer spreads traffic across Zitadel pods and terminates TLS for every client and identity provider. Two load balancers or ingress controllers are only redundant if both route to healthy pods and share the same certificate handling. Confirm where TLS terminates, how certificates renew without downtime, and whether gRPC and HTTP/2 traffic used by Zitadel's APIs pass through the path you test.

Master key and Kubernetes secrets

The master key and the other secrets Zitadel reads from Kubernetes protect data that every replica needs to decrypt. Every pod must receive identical values, and a missing or rotated key can stop the service from starting or make stored data unreadable. Confirm which values your version encrypts with the master key, where the secrets are sourced, how they are backed up and restored, and who can read them.

External domain and DNS

Zitadel issues tokens whose issuer and redirect values depend on its external domain, so clients and identity providers must reach the same name the service was configured with. Changing that domain later can break existing OIDC and SAML registrations. Confirm how your version sets the external domain, which DNS records point to the ingress, how a failover DNS entry is handled, and whether a standby site can serve the same name.

Which PostgreSQL and cluster options fit Zitadel high availability

This table compares four database and cluster options for a highly available self-hosted Zitadel, covering who patches, who handles failover, data residency and the skills your team must keep. Read each row against your own operating model, and confirm vendor-specific behavior with the provider or operator documentation before you commit.

Option	When it fits	What it costs operationally
Managed PostgreSQL from a cloud provider	Teams that want the provider to run backups, minor patching and failover tooling, and that can keep Zitadel's database in the cloud region their data rules allow. Zitadel supports PostgreSQL 14 through 18, so confirm the managed service offers a supported major version.	The provider patches the engine and handles much of the failover, but you still own schema migrations during Zitadel upgrades, connection limits, credentials and restore testing. Confirm the failover model, backup retention and region options in the provider documentation.
PostgreSQL operator inside the Kubernetes cluster	Teams already running Kubernetes that want PostgreSQL managed as code alongside the Zitadel Helm release, with the database kept inside your cluster boundary.	Your platform team owns operator upgrades, storage classes, backup target configuration and failover testing. Operator capabilities for replicas, point-in-time recovery and failover vary, so confirm them in the operator documentation.
Self-managed PostgreSQL with streaming replication on virtual machines	Organizations with strict control over hosts, network paths and data location, or with existing database operations staff who already run replicated PostgreSQL.	Your DBA and systems team owns OS and PostgreSQL patching, replica monitoring, failover decisions and the tooling that promotes a standby. This carries the highest skills requirement and the most manual runbook work.
Single-zone Kubernetes cluster	Non-production environments, or production teams that accept that a zone outage stops Zitadel and need a simpler cluster to run at lower complexity.	Lower networking and storage complexity, but a single zone failure takes down every Zitadel replica and any in-cluster database pods. Recovery depends on your restore process and its tested recovery time.
Multi-zone Kubernetes cluster	Production deployments where Zitadel replicas should survive the loss of one availability zone, typically paired with a database that also spans zones.	Requires spreading replicas and storage across zones, which raises cloud networking and storage costs and adds scheduling rules to maintain. Confirm the zone topology and storage replication behavior with your cloud provider.
Mixed model: managed database with multi-zone cluster	Teams that want zone-level resilience for the application tier and delegate database operations to a provider, while keeping control of the Kubernetes deployment.	Splits responsibility across two providers and two sets of documentation. You must verify that failover in the database layer and pod rescheduling in the cluster work together during a zone event, and test that path.

How to build Zitadel high availability in the right order

This sequence takes a self-hosted Zitadel instance from agreed availability targets to a tested failover on Kubernetes. Each step closes with a check you can observe, so the team confirms each layer works before the next one depends on it.

Agree availability and recovery targets with the business
Begin with the business targets. Agree in writing the availability level, the acceptable data loss and the acceptable time to recover for sign-in, and list which applications and teams stop working if Zitadel is down. Confirm whether the targets cover the console and hosted login as well as the APIs. Your architecture owner signs off these targets, with the business owner and a DeployOpen architect if you use a partner. Done when the agreed targets are recorded in the design document and every later step can be checked against them.
Provision a clustered PostgreSQL on a supported version
Zitadel uses PostgreSQL as its database, and versions 14 through 18 are supported, so choose a version in that range and confirm it against the current Zitadel database documentation before you build. Set up a clustered deployment with replication and automatic failover, using a managed service or an operator your team already runs. Then promote a replica on purpose and confirm the failover behaviour. Done when the database fails over and Zitadel reconnects without manual changes to its configuration.
Create Kubernetes secrets for credentials and master key
Store the database password and the Zitadel master key as Kubernetes secrets in the namespace where Zitadel will run. Keep these values out of Helm values files and anything committed to source control. Restrict read access with role-based access control, and record where a secure copy of the master key is held, because the master key protects encrypted data. Confirm that the chart references the secret names you created. Done when the pods start and read their credentials from the secrets, and no secret value appears in the rendered chart values.
Deploy the official Helm chart with spread replicas
Install the official Zitadel Helm chart, pinned to a release your team has tested in a non-production cluster. Set the replica count and pod anti-affinity rules so replicas schedule on different nodes, and across zones where your cluster provides them. Confirm the cluster has enough capacity for the chosen count, and set pod disruption budgets so routine node maintenance cannot remove every replica at once. Done when the pods run on separate nodes and the rollout completes without errors in the pod logs.
Configure the external domain, ingress and TLS
Set the external domain that users and applications will see, and make the Zitadel configuration use the same domain, because issuer URLs and redirects depend on it. Route traffic through your ingress controller and attach a certificate from your certificate authority or certificate manager. Check that the OpenID Connect discovery document loads over HTTPS under the expected hostname, and that the certificate chain is complete. Done when the discovery endpoint responds through the load balancer with the correct issuer value.
Wire health checks and confirm login during a restart
Configure liveness and readiness probes so a pod receives traffic only after it can reach the database. Connect a test application or a test identity provider to the instance, and sign in as a test user. While the sign-in is in progress, restart one pod, then repeat the test after draining one node if your environment allows it. Done when the sign-in succeeds during the restart, and the probe settings and the observed behaviour are written into the runbook.
Schedule backups and prove a first restore
Schedule regular database backups and document how the master key is backed up alongside them. Restore the latest backup into a separate environment, start Zitadel against it, and confirm that a known test user exists and can sign in. Ask your database operator or backup vendor to confirm that point-in-time recovery is available and how it is tested. Done when the restored environment serves logins and the restore steps are documented for the next drill.
Run a failover drill against the agreed targets
Schedule a drill that combines the failures you planned for: losing a pod, failing over the database and draining a node. Watch whether sign-ins continue and whether tokens and sessions behave as the targets from step one require. Note every step that needed manual action, fix those gaps and assign owners in the runbook. Done when the drill meets the agreed targets, and the team repeats it after each Helm upgrade or database change.

What drives the effort and cost of a highly available Zitadel setup

This table lists the factors that change how much work a highly available Zitadel setup takes and how each one adds effort. Read each row as a question to answer in your own environment before you request a quote. Most of the effort sits in the database layer and in testing failover, so those rows deserve the most scoping time, and any partner should price from the written scope.

Driver	How it increases effort	How to keep it down
Number of environments (development, staging, production, disaster recovery)	Each environment needs its own Kubernetes cluster, PostgreSQL database, secrets and Helm values, and failover drills must run in more than one place.	Keep one parameterized Helm values set and infrastructure as code for all environments, and limit full failover tests to production-equivalent environments.
Number of Zitadel instances and organizations to protect	Instances hold fully isolated data, so backup, restore and failover checks multiply for each instance and its organizations.	Define a standard instance template, document the per-instance checklist, and restore a representative sample on a fixed schedule.
Database size and growth	PostgreSQL holds the identity data, so larger and faster-growing databases lengthen backups, restores and replication checks. Confirm that your PostgreSQL version is within the supported range (14 through 18) before design starts.	Size storage from measured growth, track restore time against your recovery objective, and schedule replication health checks alongside capacity reviews.
Connected applications and identity providers	Redirect URIs, token issuers and federation callbacks depend on the public endpoint, so every application and identity provider flow must be re-tested after failover.	Maintain a test matrix of critical login, token and federation flows per application, and automate the login checks where the platform allows.
Network and TLS complexity	Load balancers, ingress, certificates, database connections and cross-zone traffic each add a failure point that must be verified during failover.	Standardize ingress and certificate automation, and document the network path for each user and service flow in one diagram.
Regulatory evidence expected	Assessors typically ask for backup schedules, restore test records, failover results and change history, and gathering these after the fact takes time. DeployOpen prepares evidence but does not issue audit reports.	Generate evidence as part of each backup, restore and failover run, store the records in one controlled location, and confirm the required format with your auditor early.
In-house skills	Gaps in Kubernetes, PostgreSQL replication or OpenID Connect and SAML knowledge increase the time needed for design reviews, troubleshooting and handover.	Name an owner for each layer, complete vendor and internal training before go-live, and agree in the written scope which tasks the partner will carry out.

How Zitadel high availability differs by deployment model

A single-node binary or Docker Compose deployment runs Zitadel and PostgreSQL on one host. Zitadel documents this model, and it suits evaluation and development. It offers no redundancy, so if the host, its disk or the container runtime fails, sign-in stops until the service is restored.

Availability provided: none beyond restarting the containers or service on the same host.
Availability not provided: failover for the Zitadel process or the database, and protection from host or disk loss.
Extra work: modest at build time, but you still need scheduled PostgreSQL backups and a documented approach to handling the Zitadel master key before any real user data is stored.
Confirm: whether this environment will ever hold production users, since evaluation instances often become production systems without a planned change.
Confirm: that the Compose file and images are pinned to versions your security team has approved.

Check that no evaluation instance has been quietly placed into production use before choosing this model for any live identity workload.

How to protect secrets and access in a highly available Zitadel cluster

A highly available Zitadel cluster is only as protected as the secrets every replica depends on. The master key, database credentials, TLS material and deployment access each need a defined owner, storage location and rotation path before the first replica starts. The cards below cover each control and what to verify in your own environment.

Master key storage and restore

Zitadel uses a master key to protect sensitive values it stores, so every replica must read the same key from the same source. Keep it in a managed secret store or an encrypted Kubernetes secret, outside plain Helm values files, and restrict who can read it. A replica that cannot read the key will not serve requests correctly, and losing the key without a tested copy turns an incident into a data recovery problem. Test a restore into a non-production cluster and confirm the restored key decrypts existing data.

PostgreSQL credentials and rotation

Each Zitadel replica connects to PostgreSQL with credentials read from a Kubernetes secret. A replica that cannot authenticate will fail to start or serve requests, which quietly removes capacity until the remaining replicas are overloaded. Use a dedicated database role with only the privileges Zitadel needs, and rotate in stages: create the new credential, update the secret, restart pods in sequence, then revoke the old one. Confirm supported PostgreSQL versions and migration privileges against the Zitadel database documentation before you set this up.

TLS on external and internal connections

Terminate TLS for the external domain at the ingress or load balancer with a certificate that renews automatically, and track its issuer, chain and expiry alerts. Traffic between the ingress and Zitadel pods, and between Zitadel and PostgreSQL, should also be encrypted where your policy requires it, using certificates from an internal authority if needed. Check how the Helm chart handles each hop and document which certificate expires when. An expired internal certificate causes the same outage as an expired public one, and it is easier to miss.

Least-privilege Kubernetes RBAC

People and CI pipelines that deploy the chart need permissions limited to the Zitadel namespace. Separate the role that installs or upgrades the release from the role that reads secrets at runtime, and avoid cluster-admin for routine deployments. Limit who can read secrets in that namespace, because the master key and database credentials are stored there. Review bindings whenever team members or pipelines change, and record which service account performed each upgrade so a failed rollout can be traced.

Network policies for database access

Network policies should allow connections to PostgreSQL only from Zitadel pods and approved migration jobs, and deny other traffic into the database namespace. Confirm that your cluster network plugin enforces policies before relying on them, because an unenforced policy provides no protection. Add monitoring scrapers and backup jobs to the allow list explicitly. Test the policy by attempting a connection from an unrelated pod and confirming that it fails.

Backups as sensitive data

A database backup contains user records, client configuration and the encrypted values the master key protects, so it needs the same access controls as the live database. Store backups encrypted, limit who can restore them, and keep the master key in a separate location from the backup store. A backup cannot recover data without its matching master key, so track the two together. Test restores on a schedule and log each restore, since a restore is also a route to the data.

How to test that Zitadel stays up and recovers from failure

The test plan should answer one question for each failure: do users keep signing in, and when they cannot, do they fail with a clear error? Start with a baseline. Before any fault is injected, run a scripted login load against the public issuer URL using the same OIDC flows your applications use. Record the success rate, latency and error codes. Keep the script in version control so the identical run can be repeated after an upgrade or a Helm values change. Agree the pass criteria in writing with the owners of every application that depends on Zitadel before the test window opens.

For the rolling restart, run the login test continuously and trigger a restart of the Zitadel deployment with a rollout restart in Kubernetes. Watch that readiness probes gate traffic, that the pod disruption budget keeps enough replicas serving, and that new pods become ready before old ones terminate. Confirm the replica count in your Helm values matches what you intended. Some logins in progress will fail when a pod stops. That is expected, provided the client can retry and the user sees an error page instead of a half-completed session. Record how many flows failed and whether retries succeeded.

For database failover, stop one PostgreSQL node while the login test runs, first the primary and then a replica in a separate test. Confirm the cluster promotes a replica, that Zitadel reconnects through the endpoint you configured, and that logins resume. A hard-coded node address will fail even when the cluster itself is healthy, so check the connection settings first. Confirm with your database operator which PostgreSQL version in the supported range (14 through 18) your topology uses and how it behaves during promotion. Repeat the exercise with loss of a Kubernetes node or an availability zone, and check that replicas were scheduled across zones beforehand.

For certificate and ingress tests, rotate the TLS certificate on the ingress controller during a login run, then test a renewal that fails on purpose and confirm your alerts fire well before expiry. For the restore test, restore the most recent backup into a separate environment, point a Zitadel instance at it, and sign in with an account that existed at backup time. Check that data created after the backup is absent and reported as such, not silently recreated. Set recovery time and recovery point targets with your business owners first, then compare the measured results against them. Treat every passing run as evidence only for the version and configuration tested. Repeat the full set after each Zitadel upgrade, each database major version change and each change to the chart values.

What to monitor, back up, document and hand over after go-live

A highly available Zitadel setup depends on what your team watches, restores and changes after launch. The cards cover the health signals to alert on, database checks, the backup routine, change control for chart and database updates, failover and restore runbooks, and the handover pack. Upgrade procedures and post-go-live support are covered in separate topics, so confirm which support options apply to your chosen delivery model.

Pod health and login signals

Watch pod readiness and restart counts for every Zitadel replica, and track login success and error rates as the user-facing measure of health. Sustained growth in errors can point to a failing replica, a database problem or a failing upstream identity provider, so alerts should help separate those causes. Track certificate expiry dates for the public endpoint and any internal TLS certificates, with alerts set well before expiry. Confirm which metrics your chart version exposes before designing dashboards.

Database replication and connections

Measure replication lag between the primary PostgreSQL server and its standbys, since a lagging standby can serve stale data after failover. Track connection use against the configured limits, because Zitadel replicas share a connection budget and pool exhaustion appears as slow or failed logins. Watch disk growth and long-running queries as well. Confirm with your database platform which replication and connection metrics are available, and agree alert thresholds with the team that owns the database.

Scheduled backups with off-cluster copies

Run scheduled backups of the PostgreSQL database, which holds Zitadel's configuration and user data, and store copies outside the Kubernetes cluster so a cluster failure does not remove them. Retention periods are a decision for your organization, shaped by regulatory and contractual obligations, so record them in writing before go-live. Keep the key material Zitadel needs to decrypt data in a separate, controlled location. Confirm encryption, access control and immutability options with your storage provider.

Change control for chart and database updates

Route Helm chart upgrades and PostgreSQL minor updates through a documented change process with a staging run, a rollback plan and a named approver. Pin chart values and image tags in version control so each change is reviewable. Read the release notes for the target version before each change, and check the supported PostgreSQL range in the Zitadel database documentation, which lists versions 14 through 18. Major upgrades and migration testing are covered in a separate topic.

Failover and restore runbooks

Write step-by-step runbooks for database failover, replacing a failed Zitadel workload, restoring from backup and confirming logins after recovery. Each runbook should name the trigger, the decision owner, the commands or console steps and the verification checks. Restore drills on a schedule show that backups can be restored and that the runbook still matches the environment. Record how long each drill took and the gaps it found, then update the runbook after every drill.

Handover pack and named owners

Hand over an architecture diagram showing replicas, database topology, load balancing, ingress and backup paths. Keep configuration in version control, and document where secrets are stored without recording their values. Include test records from failover and restore tests, and name an owner for each area, such as platform, database, identity configuration and security. Confirm with your provider which handover items fall within the agreed scope and which your team keeps.

How long, costly and hard is Zitadel high availability to set up

What drives the cost of setting up Zitadel high availability?

Scope drives cost more than anything else, and DeployOpen does not publish a price list. A quote follows from the written scope. The main cost components are the database design and failover work, the Kubernetes deployment on the Helm chart, the number of environments (for example, separate staging and production), identity provider integrations, backup and restore testing, and documentation handover. One-time build work is quoted separately from anything that recurs. Ask for the quote to list each component as its own line, state what is excluded, and name who operates each part after go-live. Ongoing support, upgrades and continuous testing are handled under a retainer, so ask for those as a separate, recurring estimate.

Why does the database layer usually dominate Zitadel high availability effort?

The database layer usually takes the most effort because Zitadel stores its state in PostgreSQL, and the application tier can only be as available as the database behind it. Zitadel documents support for PostgreSQL versions 14 through 18, so the first decision is which version and which high availability approach your platform team already runs. The work then covers replication, automatic or controlled failover, connection handling from the Zitadel pods, credentials management, backups with point-in-time recovery where the platform supports it, and restore testing. Each of these needs to be proven in your own environment, not assumed from a diagram. Ask the quote to show the database work separately so you can see where the effort sits.

Can our own team set up Zitadel high availability with the official Helm chart?

Yes, many platform teams can do this in-house if they already run Kubernetes and PostgreSQL in production. Zitadel documents a Kubernetes cluster with the official Helm chart as its recommended route to high availability, so the chart and the self-hosting documentation are the right starting point. The harder parts are rarely the chart itself. They are the database platform, TLS and ingress, secret handling, network policy, backup restores, and rehearsing failover without disrupting logins. Check the chart and Zitadel version you intend to pin against the current documentation, and confirm the release you plan to use before you start. If your team lacks the time or recent experience with these areas, a fixed-scope engagement can cover the parts you choose.

What does DeployOpen need from our team before work starts?

DeployOpen needs a short list of access and decisions before the build starts. The main items are:

Cluster access: a Kubernetes cluster in your cloud account, data center or air-gapped network, with an agreed way to deploy and manage releases.
A database platform decision: which PostgreSQL service or self-managed setup you run, the version within the supported range, and who owns it.
Identity provider details: the providers you plan to federate with, their metadata, and the claims you expect.
Test accounts: users in each relevant organization so login, token and failover checks can run end to end.
A change window: a period agreed with your operations team for failover tests that may briefly interrupt sign-in.

Missing any of these usually moves work and timelines, so raise them during scoping.

How is a fixed-scope Zitadel high availability engagement agreed?

A fixed-scope engagement is agreed in writing before any work starts. The written scope sets out the objectives, deliverables, environments in scope, assumptions, exclusions, dependencies on your team, acceptance criteria and the timeline that depends on those inputs. Most engagements are fixed-scope, and the quote follows directly from that document. Ask for a clear change process, so that any new requirement, such as an extra identity provider or a second region, is priced and scheduled through a written change request instead of being absorbed silently. Also ask how acceptance is tested, for example which failover scenarios and backup restores must pass before handover is signed off.

What is included in a Zitadel high availability quote versus a retainer?

A quote covers the defined build work in the written scope: design, deployment on the Helm chart, database high availability setup, integration with agreed identity providers, verification and documentation. It is a one-time engagement with a clear end point. A retainer covers work that continues after go-live, such as ongoing support, planned upgrades, testing of upgrades and database migrations, and continuous testing. Retainers recur on a schedule you agree. Ask the quote to state which items are one-time and which would move to a retainer, and ask for the retainer scope in writing, including response expectations and what happens when a Zitadel release changes behavior.

What usually goes wrong in a highly available Zitadel deployment?

The most common problems are operational gaps, not missing features. Typical issues include a database failover that was never rehearsed, so connection handling breaks during the switch, and backups that were taken but never restored in a test environment. Teams also run into TLS and external domain mismatches at the ingress, secrets kept in the wrong place or rotated without a plan, and pods scheduled onto the same node so one failure removes all replicas. Upgrades without a tested database migration path cause outages more often than the platform itself. Before go-live, confirm these areas against the current self-hosting documentation and your own runbooks, and make sure someone owns each one after handover.

How do we verify Zitadel failover and backup restores actually work?

Verify by testing the failure modes you care about, in a controlled window, and recording the results. A practical set includes removing one Zitadel pod, draining a Kubernetes node, forcing a database primary failover, and restoring a recent backup into a separate environment. After each test, confirm that new logins, token issuance, refresh, and any federated sign-ins still work, and that users are not left with broken sessions. Keep a dated record of who ran each test, what was observed, and how long recovery took against your own recovery objectives. Ask the quote to include these tests as acceptance criteria and to deliver the runbook that operations will reuse.

How DeployOpen scopes, builds and hands over Zitadel high availability

DeployOpen plans, builds and documents highly available Zitadel inside your own infrastructure, following the Kubernetes and Helm approach Zitadel recommends for high availability. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Confirm the Zitadel version line, target Kubernetes platform and where the cluster runs in your environment.
Define the PostgreSQL topology, supported database versions and the replication and failover behavior you require.
Agree in writing which replicas, ingress, TLS, backup and restore tests and documentation the engagement covers.

How we build

Deploy Zitadel with the official Helm chart across multiple replicas, with configuration kept in version-controlled values files.
Configure the PostgreSQL setup for resilience and verify connection handling, failover and recovery under controlled failure tests.
Run backup jobs and restore drills, recording recovery steps and checking that restored data supports a working login.

How we hand over

Deliver runbooks covering rolling restarts, scaling, certificate rotation, database failover and restore procedures.
Document the architecture, configuration decisions and the test evidence gathered during build and failover testing.
Walk your platform and security teams through operations and confirm they can perform routine tasks independently.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
Ask whether a retainer covers Helm-based upgrades, database migration testing and periodic backup restore tests.
Confirm response expectations, escalation paths and who holds administrative access before the handover is signed off.