Should you run Zitadel yourself or use Zitadel Cloud?
Zitadel Cloud suits teams that can accept its published plan limits and one of four cloud regions, while self-hosting suits teams that need data sovereignty, air-gapped operation, a specific deployment region or a commercial license. The AGPL-3.0 question is decisive for some organizations: Zitadel moved its core, Console and hosted login to AGPL-3.0 with Zitadel v3.0 on 31 March 2025, and a team whose legal or procurement rules cannot accept that license has to look at the commercial terms, which come through an Enterprise contract. Teams that can accept AGPL-3.0 and have no sovereignty constraint can self-host without buying anything, but then they carry the operating work themselves. Cloud is the simpler path when the workload fits the Free plan at 100 daily active users or the Pro plan at 25,000 daily active users with a custom domain and a 99.5% uptime guarantee, and when one of the four regions (United States, European Union, Switzerland or Australia) meets your data residency rules. Check the pricing page for the exact limits before you commit, and confirm with Zitadel how data in transit is handled when users access the service from outside the region, because the help center notes that traffic can leave the region. Self-hosting suits the opposite case: you need a PostgreSQL database under your control (versions 14 through 18 are supported), you can staff the upgrades and backups, and you need the data to stay in a location Zitadel's regions do not cover. The Enterprise tiers change the trade-off rather than remove it. Enterprise Cloud is managed by Zitadel on a shared environment with automated upgrades, while Enterprise Self-Hosted gives you dedicated CPU and memory and upgrades under your own control, and it includes a commercial license that replaces the AGPL. Ask Zitadel in writing which contract covers your deployment, what support SLA and uptime commitment apply, who performs upgrades and restores, and whether the commercial license terms satisfy your legal review before you choose a hosting model.
How Zitadel Cloud and self-hosted Zitadel differ on the factors that matter
This table compares Zitadel Cloud and self-hosted Zitadel across licensing, plans, user limits, uptime, data location, upgrades, database and deployment. Read the published figures as starting points, and use the confirm column to list what must appear in a written quote before you decide.
| Factor | Zitadel Cloud | Self-hosted Zitadel |
|---|---|---|
| Licensing | Hosted service under Zitadel's terms. Confirm which license terms apply to the hosted service and any contract-specific rights. | Core, Console and hosted login are AGPL-3.0 from Zitadel v3. APIs, SDKs and Helm charts stay Apache 2.0. Commercial license only through an Enterprise Self-Hosted contract. |
| Plans and editions | Free at US$0 per month, Pro at US$100 per month, and Enterprise with custom pricing (Zitadel pricing page). | No plan fee for the software under AGPL-3.0. Enterprise Self-Hosted is a custom contract that includes a commercial license. Confirm what support and scope it covers. |
| User limits | Free includes 100 daily active users and Pro includes 25,000 (Zitadel pricing page). Enterprise lists unlimited daily active users. | No user cap set by the license. Capacity depends on your database, sizing and operations. Confirm sizing assumptions in writing. |
| Uptime guarantee | Pro lists a 99.5% uptime guarantee and Enterprise lists 99.99% (Zitadel pricing page). Confirm the measurement window and credits. | No vendor uptime guarantee. Availability is set by your own architecture, failover and on-call model. |
| Data location | Four regions: United States, European Union, Switzerland and Australia. Data in transit may leave the region for international access (Zitadel help center). | Wherever you deploy it, including air-gapped or a specific region. Zitadel recommends self-hosting for absolute data sovereignty. |
| Upgrades | Enterprise Cloud has automated upgrades in a shared environment. Standard Cloud upgrade timing: confirm with Zitadel. | Upgrades are under your control and need your change process, testing and rollback plan. |
| Scaling | Enterprise Cloud has automatic scaling in a shared environment. Confirm how Pro scales under peak load. | Scales as you size it. Zitadel recommends Kubernetes with the official Helm chart for high availability. |
| Database | Managed by Zitadel. Confirm backup, restore and retention terms. | PostgreSQL 14 to 18 is required. You own backup, replication and recovery of the database. |
| Deployment methods | Not applicable. Zitadel operates the service. | Linux binaries, Docker Compose and Kubernetes with the official Helm chart are documented. |
| Certifications | Zitadel lists ISO 27001, SOC 2 Type II, GDPR and OpenID certification on its pricing page. Confirm scope covers the service you buy. | Certifications cover Zitadel as a company, not your deployment. Your own controls and evidence must be prepared and assessed separately. |
What control, data location and compliance mean for each model
Zitadel Cloud and self-hosted Zitadel differ mainly in who runs the service, where the data sits and who answers for upgrades and evidence. The cards below cover the decisions that follow from those differences, and what to confirm before you commit.
Cloud data regions and transit
Zitadel Cloud offers four data regions: the United States, the European Union, Switzerland and Australia. Choosing a region fixes where your stored identity data lives, but it does not fix where traffic travels. Zitadel's help center notes that data in transit may leave the region when users access the service from other countries. For a workforce that signs in from abroad, ask Zitadel to confirm exactly which data moves in transit and whether that matters under your data residency rules.
Sovereignty and air-gapped guidance
Zitadel's help center recommends self-hosting where you need absolute data sovereignty, air-gapped operation or a specific region with no shared infrastructure. It also cites avoiding noisy-neighbor risk. If your policy requires identity data to stay inside your own network or a named facility, self-hosting is the documented route. Confirm that your chosen deployment method, whether the Linux binary, Docker Compose or Kubernetes, can pull images and dependencies inside your isolated network.
Who holds the operator role
In Enterprise Cloud, Zitadel runs the service as a fully managed offering with automated upgrades and automatic scaling in a shared environment. In Enterprise Self-Hosted, your own operations team runs Zitadel on dedicated CPU and memory and controls upgrade timing. The operator role moves from the vendor to you, along with backup, restore, PostgreSQL operations and incident response. Ask who gets paged at 2 a.m. and who approves a version change before you pick a model.
AGPL-3.0 obligations and commercial license
Since Zitadel v3.0, the core, Console and hosted login are licensed under AGPL-3.0. Its network-use terms can require you to offer source code to users who interact with a modified version over a network, so legal review is needed for any change you make. APIs, SDKs, proto definitions, Helm charts and Terraform configurations stay Apache 2.0. An Enterprise Self-Hosted contract includes a commercial license that replaces the AGPL, which is the usual route for teams that cannot accept those terms.
Certifications Zitadel lists
Zitadel's pricing page lists ISO 27001, SOC 2 Type II, GDPR and OpenID certification. These are the vendor's listed credentials for its own service. They do not transfer to your self-hosted deployment, and they do not replace your own assessment. Request current certificates and reports from Zitadel, check the audit scope and period, and confirm whether they cover the Cloud region and service you intend to use.
Evidence for your own compliance scope
Whichever model you choose, your auditors will ask for evidence about your own controls: access reviews, change records, backup tests and logging of administrative actions. Zitadel's event-sourced storage keeps a record of changes, but you still need to show who operates the system and how evidence is retained. For Cloud, request the vendor's evidence and map it to your responsibilities. For self-hosting, build the evidence pack yourself and confirm the scope with your assessor before work starts.
Why the commercial license matters for teams that cannot accept AGPL-3.0
If your organization cannot accept the AGPL-3.0, the license question decides the deployment model before features or price do. Zitadel moved its core, Console and hosted login from Apache 2.0 to the GNU Affero General Public License 3.0 with Zitadel v3.0 on 31 March 2025. The APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache 2.0, so your integration code and deployment manifests are not affected by the core license. What changes is the license governing the server you would run yourself. Check the current scope in the Zitadel blog post on the move from Apache to AGPL before you assume a directory is covered or excluded.
An Enterprise Self-Hosted contract includes a commercial license that replaces the AGPL for the software you run. That is the contractual route for teams whose policy rules out AGPL-3.0 on self-hosted code. Ask Zitadel to state in writing which components the commercial license covers, which version range it applies to, and whether it extends to Console and hosted login. Have legal counsel confirm how AGPL obligations apply to any modifications you make and to any network use of a modified server, since those obligations are triggered by the way the software is used and not only by distribution. Your counsel should also review how the commercial terms interact with your internal policy on copyleft software.
Enterprise Cloud does not itself change the license of the software you run. Zitadel fully manages that deployment, so you are consuming a hosted service rather than operating a copy of the server. If your concern is that you would be obligated to publish changes to a server you operate, Enterprise Cloud removes that operational question, but it does not replace the license terms for any self-hosted component you still run, such as tooling you build against the Apache 2.0 APIs. Confirm with Zitadel which contract terms govern the hosted service and whether any customer-side code is covered by the AGPL in your setup.
Which hosting model fits which team
A team with a modest number of daily active users usually gets the most value from the published cloud plans, because the Free and Pro tiers cover small user bases without any infrastructure to run. The Zitadel pricing page lists a Free plan at US$0 per month with 100 daily active users and a Pro plan at US$100 per month including 25,000 daily active users, a custom domain and a 99.5% uptime guarantee. Self-hosting becomes attractive later, when growth, a contract requirement or a data rule changes the calculation.
- Cloud fits early stage traffic: The Free plan is a low-commitment way to validate login flows, organizations and SAML or SCIM needs before any infrastructure decision.
- Pro adds the custom domain: If customers see your login domain, the Pro plan's custom domain and 99.5% uptime guarantee are the features to compare against your own availability needs.
- Self-hosting adds operating work: You would own PostgreSQL, upgrades, backups and the AGPL-3.0 obligations, which is a recurring cost even when the software itself is free.
- Licensing matters if you distribute code: Teams that modify and network-expose Zitadel should review what AGPL-3.0 requires before choosing self-hosting.
Before choosing, confirm the current daily active user count against the plan limits, the data region you need from the four cloud regions, and whether your customers' contracts require a specific uptime or support commitment.
A regulated B2B product often has to decide where identity data lives and who operates the platform. Zitadel Cloud offers four data regions: the United States, the European Union, Switzerland and Australia. The help center notes that data in transit may travel outside the region when users access the service internationally. Where the rule is stricter than a region choice, Zitadel recommends self-hosting for absolute data sovereignty, air-gapped networks or specific-region deployments, and that path typically means an Enterprise Self-Hosted contract.
- Region fit is the first test: If one of the four cloud regions meets your residency rule and users do not need to be routed elsewhere, the cloud option may satisfy the requirement without new infrastructure.
- Air-gapped or sovereign needs point to self-hosting: Deployment inside your own networks keeps identity data under your control, which the help center presents as the reason to self-host.
- Licensing changes the contract: An Enterprise Self-Hosted contract includes a commercial license that replaces the AGPL, which matters if your legal team cannot accept AGPL-3.0 obligations.
- Certifications belong to Zitadel: Zitadel's pricing page lists ISO 27001, SOC 2 Type II, GDPR and OpenID certification. Ask for the current reports rather than assuming they cover your self-hosted deployment.
Confirm with your legal and compliance leads which data categories must stay in a named region, whether cross-border access is acceptable, and whether the commercial license terms in the Enterprise contract satisfy your procurement rules.
A team that already runs Kubernetes, PostgreSQL and backup tooling can absorb a self-hosted Zitadel deployment into existing practice. Zitadel documents self-hosting on Linux and macOS binaries, Docker Compose and Kubernetes, and recommends a Kubernetes cluster with the official Helm chart for high availability. In that setting, the self-hosted option gives control over upgrade timing, dedicated resources and placement, which the help center associates with Enterprise Self-Hosted.
- Existing tooling reduces new work: Teams with a PostgreSQL service in the supported 14 to 18 range and a Helm workflow can reuse those patterns for Zitadel.
- Upgrade control is yours: Enterprise Self-Hosted places upgrades under the customer's control, which suits teams that test releases in staging before production.
- Dedicated capacity avoids shared-environment effects: The help center cites avoiding noisy-neighbor risk as a reason to self-host, which matters if identity is on your critical path.
- Event sourcing shapes backups: Zitadel stores every change as an event, so your backup and restore plans should be tested against the event store, not only against tables you expect to read.
Confirm that your operations team has an owner for Zitadel upgrades, that your PostgreSQL service meets the supported versions, and whether you need a commercial license or can operate under the AGPL-3.0 terms.
A team without spare operations capacity usually reduces risk by choosing Zitadel Cloud, unless a residency or licensing rule forces self-hosting. The cloud plans move upgrades, scaling and availability into the vendor's operations, while the Enterprise Cloud description adds automated upgrades and automatic scaling in a shared environment. The trade-off is that you accept a shared environment and the vendor's uptime commitments instead of your own runbooks.
- Cloud moves recurring operations to the vendor: Upgrades, scaling and availability become the provider's responsibility under the plan you choose.
- Self-hosting carries recurring duties: Database maintenance, certificate handling, upgrade testing and incident response continue for as long as you run the service.
- Uptime terms differ by plan: Pro lists a 99.5% uptime guarantee and Enterprise lists 99.99%, so compare the commitment against the business impact of a login outage.
- Support terms are contractual: Enterprise lists a custom support SLA and a technical account manager, which you should request in writing if you need them.
Before choosing, ask for the exact support hours, incident response terms and uptime measurement method in writing, and confirm whether a managed partner could cover self-hosted operations if the team cannot staff them.
What your team runs in each model
This table compares who performs upgrades, scaling, backups, PostgreSQL operation, high availability, monitoring and incident response across Zitadel Cloud, Enterprise Cloud, Enterprise Self-Hosted and self-hosted Zitadel. Read each row against the vendor's split of responsibility in its help center, then confirm the effort in writing because it depends on your own environment.
| Responsibility | Zitadel Cloud and Enterprise Cloud | Enterprise Self-Hosted and self-hosted Zitadel |
|---|---|---|
| Upgrades | Zitadel operates the service, with automated upgrades on Enterprise Cloud. Confirm upgrade timing for your plan in writing. | Your operations team plans and applies upgrades under your change control. Track releases such as v4.19.5 and test before rollout. |
| Scaling | Enterprise Cloud scales automatically in a shared environment. Pro and Free plans have published user limits. | Your team sizes CPU, memory and replicas. Enterprise Self-Hosted includes dedicated CPU and memory under your control. |
| Backups and recovery | Zitadel operates the hosted data stores. Ask the vendor what backup and restore commitments your contract includes. | Your team owns backup schedules, restore tests and retention for the PostgreSQL database and configuration. |
| PostgreSQL operation | Handled by the vendor, so you do not manage database versions in the cloud service. | You run PostgreSQL 14 through 18, with patching, tuning and storage capacity on your side. |
| High availability | Delivered by the vendor's managed platform. Ask for the availability terms in your contract. | Zitadel recommends Kubernetes with the official Helm chart for high availability. Your team designs and tests failover. |
| Monitoring and incident response | Vendor-led operations, with support levels set by your plan. Confirm escalation paths and support SLAs in writing. | Your team builds monitoring, alerting and on-call response. Scope who responds to identity outages before go-live. |
| Data location and sovereignty | Data resides in one of four published cloud regions. Data in transit may travel outside the region for international access. | Data stays in infrastructure you choose, which suits absolute data sovereignty or air-gapped deployments. |
| Effort driver | Mainly contract scope and integration work, since day-to-day operations sit with the vendor. | Mainly operations headcount, database administration and upgrade testing. Ask DeployOpen or your vendor to scope these in writing. |
How the cost of each model is built
The main cost difference is who carries the operating work. On Zitadel Cloud, the published plans are the starting point: the Free plan is listed at US$0 per month with 100 daily active users, and the Pro plan at US$100 per month includes 25,000 daily active users, a custom domain and a 99.5% uptime guarantee, according to the Zitadel pricing page. Those are subscription fees. Your own costs on top are integration work, the migration of existing users and applications, and the internal time spent on configuration. Self-hosting removes the subscription line but adds the infrastructure, a PostgreSQL database in versions 14 through 18, upgrades, backups and the staff who run them. Confirm whether the Pro plan's 99.5% uptime guarantee meets your availability target, because a higher target pushes you toward an Enterprise contract or a self-hosted high availability design that you pay to build and run.
The Enterprise plan has no published price. The pricing page lists unlimited daily active users, a custom support SLA, a technical account manager, a commercial license and a 99.99% uptime guarantee, with custom pricing for cloud or your own infrastructure. Ask the vendor to state, line by line, whether the quote includes the commercial license that replaces the AGPL, the exact support SLA response terms, the technical account manager's time commitment, the uptime guarantee, and the data region. Ask whether Enterprise Cloud (fully managed, shared environment) or Enterprise Self-Hosted (your operations team, dedicated CPU and memory) is priced, since each carries different staffing assumptions. Daily active user counts, region choice and team size are the main levers. Ask for a per-year figure and the renewal terms, and compare the quote with your own run cost for a self-hosted instance.
For self-hosting, the recurring items to model are compute and storage for Zitadel and PostgreSQL, the staff time for upgrades and patching, backup and restore testing, and monitoring. The Linux binary, Docker Compose and Kubernetes options differ mainly in how much platform work they assume, so the deployment choice changes the staffing estimate. Your internal estimate should be set against a quote that a DeployOpen engagement would prepare from a written scope, since fixed-scope planning, hardening and documentation are one-time costs, and ongoing support, upgrades and testing are available as retainers. DeployOpen does not publish prices, so request a written scope and quote before comparing totals.
How to move between Zitadel Cloud and self-hosted Zitadel
This sequence moves an identity deployment from one Zitadel model to the other without losing users, organization structure or application registrations. Each step ends with a check you can record before moving on.
Confirm the contract and license need
Start by deciding which direction the move goes and why. Legal and procurement should confirm whether the AGPL-3.0 terms of the open source core are acceptable for your distribution and hosting model, or whether an Enterprise Self-Hosted contract with a commercial license is needed. Compare the published Free and Pro limits against your daily active user count, and ask Zitadel which Enterprise plan includes your required data region and support terms. The step is done when you have a signed decision record naming the target model, the license basis and the data region.
Map instances, organizations and projects
Document how your current tenancy is arranged. Zitadel organizes tenants as instances, with organizations inside them holding projects, users and grants. List each organization, its users, its projects and roles, and every identity provider federated to it, since each customer organization can use a different one. Include external identity providers such as Entra ID, Okta, LDAP or Keycloak. The step is done when you have an inventory that your team has reviewed against the live console or API output.
Build the target environment
Provision the destination. For Zitadel Cloud, choose one of the four published data regions and confirm with Zitadel how data in transit is handled when users access the service from outside that region. For self-hosted Zitadel, pick a documented deployment path (Linux binary, Docker Compose or Kubernetes with the official Helm chart) and provision a PostgreSQL instance within the supported versions 14 to 18. Recreate the instance settings, domains and any custom login branding. The step is done when a test instance starts, accepts an administrator login and passes your own health checks.
Migrate users, applications and federation
Zitadel documents migration guides for Auth0, Keycloak, Firebase and another Zitadel instance, including approaches such as just-in-time migration, where a user's record moves on first login. Test the approach that fits your source against a copy of your own user store, and do not assume a documented path covers your attribute mapping, password hashing or federated identity providers. Recreate each OIDC or SAML application with its redirect URIs and roles, and verify federation to each external identity provider end to end. The step is done when a sample of users from every organization signs in on the target and their roles and grants match the inventory.
Test sign-in and provisioning paths
Exercise the paths users and systems actually use before any traffic moves. Cover password plus passkey login with fallback, device authorization for devices that need it, SCIM v2 provisioning and deprovisioning from your directory or HR source, and token validation in each relying application. Confirm that audit records needed for your investigations are being produced in the target environment, since Zitadel is event sourced and records every change. The step is done when each test case has a recorded pass result and any failure has an owner and a fix.
Cut over DNS and application configuration
Schedule the change window with the application owners and freeze changes to users and applications on the source. Lower DNS time-to-live ahead of time if your environment allows it, switch the custom domain or issuer URL to the target, and update each relying party's issuer and client settings. Keep the source running in read-only mode for a defined rollback period that your change board sets. The step is done when every application authenticates against the target issuer and the rollback procedure has been tested once.
Retire the old environment
After the rollback window closes and sign-in logs show no traffic to the source, export a final copy of its data for your records and retention policy. Remove federation trusts, client registrations and DNS records that pointed to the old issuer, then decommission the source instance and its database under your data disposal process. If you are moving away from Zitadel Cloud, confirm with Zitadel how your data is removed from the cloud region. The step is done when the old issuer no longer resolves, the retention export is verified, and the decommission is recorded in your change system.
Questions buyers ask before choosing a Zitadel hosting model
What does Zitadel Cloud cost at the published tiers, and what does Enterprise add?
The published Free plan is US$0 per month with 100 daily active users. The Pro plan is US$100 per month and includes 25,000 daily active users, a custom domain and a 99.5% uptime guarantee, according to the Zitadel pricing page. Enterprise has custom pricing and lists unlimited daily active users, a custom support SLA, a technical account manager, a commercial license and a 99.99% uptime guarantee. The subscription fee is the recurring cost. Your costs also include the internal staff time to configure and govern the tenant, and any integration work. Ask Zitadel for a written quote that states the daily active user count you expect, the region, the support terms and whether it covers cloud or your own infrastructure.
How long does a self-hosted Zitadel deployment take?
Zitadel does not publish a duration for a self-hosted rollout, so treat any number you see elsewhere with caution. The time depends on the deployment method you choose (Linux binary, Docker Compose or Kubernetes with the official Helm chart), whether you run PostgreSQL 14 to 18 yourself or through a managed service, how many applications and identity providers you connect, whether you migrate users from Keycloak, Auth0 or another source, and how many approval gates your change process requires. Ask DeployOpen for a written scope that lists each of these items as a deliverable with an agreed timeline. Fixed-scope engagements are agreed in writing before work starts, so the timeline is stated before you commit.
Can our team run self-hosted Zitadel without outside help?
Yes, many teams do, but they need clear skills in three areas. The first is PostgreSQL, because Zitadel stores its state there and supports versions 14 through 18. The second is the container or Kubernetes layer, since Zitadel documents Linux binaries, Docker Compose and Kubernetes, and recommends Kubernetes with the official Helm chart for high availability. The third is upgrades: you own the release cycle, and the current Zitadel release is v4.19.5. Check whether your staff can test upgrades, restore backups, rotate signing keys and monitor the service. If any of these areas is thin, plan for ongoing support. DeployOpen offers ongoing support, upgrades and continuous testing as retainers.
Does AGPL-3.0 force us to publish our source code for internal use?
Zitadel's core, Console and hosted login moved from Apache 2.0 to AGPL-3.0 with Zitadel v3.0 on March 31, 2025, according to the Zitadel blog. The AGPL network clause is the part that matters here: it applies when you modify the software and make it available to users over a network. Using an unmodified instance for internal staff logins is a different situation from offering a modified Zitadel service to customers. Your legal team should review your exact use, including any changes to the core, Console or login pages. Teams that cannot accept AGPL-3.0 terms for their product can ask Zitadel about the commercial license included in Enterprise Self-Hosted contracts. APIs, SDKs, proto definitions, Helm charts and Terraform configurations stay under Apache 2.0.
How do we move users into or out of Zitadel later?
Zitadel documents migration guides from Auth0, Keycloak, Firebase and another Zitadel instance, using approaches such as just-in-time migration, according to its migration guides. Just-in-time migration moves a user's record when that user first signs in, which lowers the risk of a single large cutover but leaves a period when two systems hold users. Before you commit, confirm with Zitadel how password hashes, passkeys, MFA enrollments and external identity links are carried over, and which fields your applications depend on. Plan a rollback path for each application. Moving away from Zitadel is also a migration, so ask what export formats and APIs are available, especially if you later need to exit a cloud tenant.
Which Zitadel Cloud region fits EU or Swiss data residency needs?
Zitadel Cloud offers four data regions: the United States (us-central1-a), European Union (europe-west3-c), Switzerland (europe-west6-c) and Australia (australia-southeast1-c), according to the Zitadel help center. For EU residency, the European Union region is the obvious starting point, and Switzerland is listed separately if your obligations point there. The help center also warns that data in transit may travel outside the region when users access the service internationally. A region choice does not by itself settle your residency position. Ask Zitadel to confirm in writing where backups, logs and support access are processed, and have your privacy counsel review those answers. If strict residency or air-gapped operation is required, the help center recommends self-hosting for absolute data sovereignty and specific-region deployments.
What is the difference between Enterprise Cloud and Enterprise Self-Hosted?
Enterprise Cloud is fully managed by Zitadel, with automated upgrades and automatic scaling in a shared environment. Enterprise Self-Hosted runs in your environment, is operated by your own team, gets dedicated CPU and memory, and keeps upgrade timing under your control, according to the Zitadel Enterprise comparison. The Self-Hosted contract includes a commercial license that replaces the AGPL. Choose Enterprise Cloud if you want Zitadel to run upgrades and scaling and can accept a shared environment. Choose Enterprise Self-Hosted if data sovereignty, dedicated resources or a commercial license matter more than managed operations. Either way, ask for the support terms and the upgrade commitments in writing.
Do Zitadel's compliance listings mean our deployment is certified?
No. Zitadel's pricing page lists ISO 27001, SOC 2 Type II, GDPR and OpenID certification for the vendor. Those listings describe Zitadel as a company or product, and they do not transfer to your deployment. Your own compliance posture depends on how you configure, operate, monitor and document your instance, and on the scope of your assessment. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask Zitadel for the scope and dates of each certificate, and ask your auditor which of your controls depend on the vendor's evidence.
What to confirm with Zitadel and your own environment before signing
Before you choose between Zitadel Cloud and self-hosted Zitadel, fix your user numbers and uptime requirement in writing. Count daily active users now and project them two years out, because the published Free plan covers 100 daily active users and the Pro plan covers 25,000, and the Enterprise plan is priced on the contract. Then decide which uptime figure applies to you. The Pro plan carries a 99.5% uptime guarantee and the Enterprise plan carries 99.99%. Ask the vendor whether the Enterprise guarantee covers Enterprise Cloud, Enterprise Self-Hosted, or both, and whether it is measured for your instance or the platform as a whole.
Next, map data residency and access patterns. Zitadel Cloud offers four data regions, and the help center notes that data in transit may travel outside the region when users access the service internationally. Confirm with your privacy and legal teams whether that is acceptable for your user population, and ask the vendor to confirm the region in writing. If you self-host, you own the region, backups and network path, so plan for those tasks in your own environment. Also confirm whether your AGPL-3.0 position needs counsel review. The commercial license included in Enterprise Self-Hosted replaces the AGPL, so counsel should compare your planned use, any modifications and any distribution against the license text before you rely on either path.
Finally, check operations staffing and integration needs. Self-hosting means your team runs PostgreSQL 14 to 18, upgrades, the Kubernetes or Docker Compose deployment and high availability, so name the people who will carry those duties after go-live. Confirm that you need SAML, SCIM and external identity providers such as Entra ID, Okta or another Zitadel or Keycloak instance, and test each one in a pilot. Ask for the current certification list in writing, since the pricing page names ISO 27001, SOC 2 Type II and GDPR, and certification status and contract terms can change. Get the uptime, support SLA and data location terms in the signed order form, not only in marketing pages.
How DeployOpen scopes, delivers and supports self-hosted Zitadel
This sequence takes a team from a Zitadel Cloud or self-hosting question to a written scope, a deployed and documented instance inside the client's own infrastructure, and an agreed plan for ongoing support and upgrades.
Confirm the deployment model and constraints
DeployOpen, a Chainscore Labs company, starts with a discovery conversation covering data residency requirements, whether the team needs an air-gapped or specific-region deployment, the expected user and tenant model, and the license position on AGPL-3.0. The client's own staff confirm which cloud accounts, data centers or networks will host the service and who will own day-to-day operations. The step closes with a short written summary of the options that remain open, including whether Zitadel Cloud, Enterprise Cloud or Enterprise Self-Hosted fits, so the client can decide which path to scope.
Agree the written scope and deliverables
DeployOpen drafts a fixed-scope proposal that states the components in scope, such as the chosen install method, PostgreSQL database, identity provider federation, SCIM provisioning and migration work. The document lists deliverables, the timeline agreed before work starts, and the client responsibilities that affect both. Pricing follows from this written scope: DeployOpen does not publish a price list, so the client should ask for a quote that itemizes each component. The step is complete when both parties have signed the scope.
Design the architecture and install method
Working from the signed scope, DeployOpen selects among the documented self-hosting routes for Zitadel: Linux binary, Docker Compose or Kubernetes with the official Helm chart. The design records the PostgreSQL topology (supported versions are 14 through 18), backup and recovery approach, high availability layout and network placement inside the client's environment. The output is an architecture document the client's security and platform teams can review before anything is built.
Deploy, configure and integrate identity sources
DeployOpen builds the instance in the client's infrastructure, configures instances, organizations and projects to match the tenant model, and connects the identity providers the client uses, such as OIDC, SAML, LDAP or an upstream provider. SCIM provisioning and application registrations are set up and tested against representative accounts. If the client is moving from another identity platform, the migration approach is agreed here. The step closes when test logins succeed for each federated source and provisioning runs as documented.
Harden, test and prepare evidence
DeployOpen applies hardening to the database, network paths, secrets handling, administrative access and passkey or multi-factor policies, then runs security testing against the deployed instance where the scope includes it. Audit trail configuration is verified, since Zitadel's event-sourced storage keeps a record of changes. The team documents controls and collects configuration evidence for the client's compliance assessment. DeployOpen does not issue audit reports or certifications, so the client confirms with its auditor which evidence is required.
Hand over runbooks and train operators
DeployOpen delivers operating documentation covering install and upgrade steps, backup and restore procedures, monitoring, incident contacts and the process for changing identity providers or applications. Client operators work through the runbooks with DeployOpen staff during handover. The step is complete when the client's team has performed a documented backup and restore test and signed off on the handover package.
Agree support, upgrades and continuous testing
Ongoing support, upgrades and continuous testing are available as retainers, and the client chooses the level that matches its internal operations capacity. The retainer scope is written down, covering which releases DeployOpen will plan upgrades for, how upgrades are tested in a non-production environment first, and how incidents are escalated. The client should ask for the retainer terms in writing before the handover closes, so the operating model is clear from the first day after go-live.
