Zitadel cost of ownership: is self-hosting cheaper than Zitadel Cloud?
The answer depends on user volume, compliance needs and the staff time your team can spare, not on license fees alone. Self-hosted Zitadel has no per-user license charge for the core, so the comparison turns on what it costs to run the service well and what the Cloud subscription replaces. Teams usually start this comparison when one of four things happens: their daily active users approach the limit of the Zitadel Cloud Free plan (100 daily active users, listed at US$0 per month), their projected user base would move them onto the Pro plan (US$100 per month including 25,000 daily active users, as listed), a regulator or customer requires data residency or specific hosting controls, or a migration from Auth0, Keycloak or Firebase forces a platform decision. Run the first pass in-house, then bring in a partner if the model needs independent checking against your compliance scope.
The license question is narrower than it looks. Since Zitadel v3.0 on 31 March 2025, the core, Console and hosted login are licensed under the GNU Affero General Public License 3.0. APIs, SDKs, proto definitions, documentation, Helm charts and Terraform configurations remain under Apache 2.0. For cost planning, this means that running an unmodified core carries no license fee, but the AGPL obligations apply if you modify the core and make it available to users over a network. Ask your legal counsel to confirm how those obligations apply to your planned customizations before you assume the self-hosted model is cost-free from a licensing perspective. Your integrations and deployment tooling stay on Apache 2.0 either way.
Self-hosting moves cost into components you pay for or staff for. Expect recurring costs for the Kubernetes or Docker hosts, a supported PostgreSQL service (versions 14 through 18 are supported), backups, monitoring, log storage, and time for on-call, security patching and upgrades on the v4 line. Expect one-time costs for the initial design of instances and organizations, deployment, integration of applications and identity providers, and migration. Cloud costs are mostly the subscription, plus any Enterprise support terms. When you ask a partner or Zitadel for a quote, request each line separately: infrastructure, database, backup and recovery testing, upgrade cycles, support hours, and what the Enterprise agreement includes for technical account management.
Build a simple model before you choose. Project daily active users for the next two to three years, list the compliance evidence you must produce and who produces it, and estimate the monthly staff hours for operations at your target availability. Then compare the recurring self-hosted cost with the Cloud plan that matches your user count. Confirm two points with Zitadel before deciding. First, the Enterprise plan is custom priced for both self-hosted and cloud deployments, so ask for a written quote. Second, Zitadel lists ISO 27001, SOC 2 Type II and OpenID certification on its pricing page, so ask which of these cover the deployment model you choose. Certifications describe the vendor's controls, and your own assessment still depends on your environment.
What a Zitadel cost of ownership study covers
A cost of ownership study turns the choice between running Zitadel yourself and buying Zitadel Cloud into a written comparison that finance and security leaders can review. Each deliverable feeds the same model, so every figure can be traced back to the inventory and the rates behind it. Figures come from your own vendor quotes, cloud rates and staff costs.
Sized inventory of users and applications
The study starts with a count of users, organizations and applications, because both the self-hosted sizing and the Cloud plan tiers depend on it. Users are counted as daily active users where the Cloud pricing applies, so the inventory records login activity by day, not only accounts on file. It also lists each application and its OIDC or SAML client, plus the customer organizations that need their own identity provider. Confirm these counts with the teams who own each application.
Self-hosted infrastructure model
This component prices the compute, load balancing, storage and networking that Zitadel needs in your environment. Zitadel documents self-hosting on Linux and macOS binaries, Docker Compose and Kubernetes, and recommends Kubernetes with the official Helm chart for high availability, so the model should state which target you choose and why. Ask for each cost line as a quote from your cloud account or data center, split into one-time setup and monthly run rate. Include test and staging environments, since they recur as well.
PostgreSQL and backup costs
Zitadel stores its data in PostgreSQL, and Zitadel's database documentation lists versions 14 through 18 as supported. The model covers whether you run a managed PostgreSQL service or a self-managed cluster, including replicas, storage growth, the backup target and the retention period you need. Backups and restore testing recur, and restore time often receives less attention than storage size. Confirm the supported version with your chosen service before you request a quote.
Staff time for operations
Staff is usually the largest recurring cost and the one most often left out of comparisons. The model estimates the people who will operate, patch and upgrade Zitadel, respond to incidents and cover on-call duty, using your loaded internal rates or the rates in a partner quote. Upgrades, Helm rollouts and database migrations recur with each release, so their effort belongs in the run cost. Ask for hours per month by role, and keep one-time build effort separate from ongoing operations.
Zitadel Cloud plan mapping
The Cloud side maps your inventory to a Zitadel Cloud plan. Zitadel's pricing page lists a Free plan at US$0 per month with 100 daily active users, a Pro plan at US$100 per month including 25,000 daily active users, and an Enterprise plan with custom pricing for self-hosted or cloud deployments. Confirm these figures on the pricing page on the day of the study, since plan terms change. Compare what each plan includes for support, technical account management and certifications against what your own team would otherwise provide.
Written recommendation and open questions
The study ends with a written recommendation that states which option costs less over the period you set, along with the assumptions behind it. Any assumption without a quote, such as an uncertain user growth rate or an unconfirmed support term, moves to a list of open questions with an owner and a deadline to resolve it. The document separates one-time costs from recurring costs so finance can review each line on its own. Decision makers can then approve the option and the open items together.
What drives Zitadel self-hosting cost up or down
This table compares the drivers that change what it costs to run Zitadel yourself against the limits and scope of Zitadel Cloud plans. Read each row as a question to answer before requesting a quote, since user volume, tenant layout and availability targets shape both infrastructure spend and staff time. The main takeaway is that self-hosting cost grows with operational scope, so decisions made early about tenancy, environments and evidence affect the total more than the hosting platform alone.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Daily active users | Cloud plans cap daily active users at 100 (Free) and 25,000 (Pro). Self-hosting has no plan cap, so load grows with users. | Measure peak daily active users early. Confirm current plan limits and overage terms on the Zitadel pricing page. |
| Instances and organizations | Each instance is a fully isolated tenant with its own data, so more instances mean more databases, configuration and upgrade work. | Group customers into organizations inside fewer instances where isolation allows. Agree the tenancy model before build. |
| Identity provider federation count | Each federated provider adds connection setup, claim mapping and troubleshooting, and each customer organization can use a different provider. | Standardize on a small set of providers and name one owner per connection. List every connection in the written scope. |
| SCIM provisioning | Automated provisioning adds sync jobs, attribute mapping and monitoring for each source system, and sync failures generate support work. | Limit SCIM to sources that need lifecycle automation. Use manual or just-in-time onboarding for the rest. |
| Passkey and MFA policy scope | Policies applied to every organization need more testing across login paths, recovery flows and password fallback. | Start with one workforce policy, then add customer policies per organization. Test recovery paths before enforcement. |
| High availability requirements | Highly available Zitadel needs multiple replicas, a resilient PostgreSQL setup, load balancing and tested backups, all with recurring operating cost. | Set availability targets per environment with stakeholders. Use single-node setups only where outage is acceptable and documented. |
| Environment count | Each environment needs its own instance, database, certificates and configuration, and changes must be promoted through each one. | Keep development and test small and rebuild them from scripts. Promote changes with the same Helm or Compose definitions. |
| Compliance evidence needs | Assessors expect access reviews, change records, audit logs and backup restore tests, which take recurring effort to produce. | Name evidence owners and collection frequency up front. Zitadel's own certifications do not cover your deployment, so confirm scope with your auditor. |
| Kubernetes or Docker Compose | Zitadel recommends Kubernetes with the official Helm chart for high availability. Compose suits smaller single-node setups. | Choose Kubernetes when you already run it and need high availability. Confirm cluster skills and monitoring before choosing Compose for production. |
How Cloud Free, Pro and Enterprise compare with self-hosting
Zitadel Cloud's Free plan is listed at US$0 per month with 100 daily active users, and the Pro plan is listed at US$100 per month including 25,000 daily active users. Those allowances set the first comparison point. A self-hosted Zitadel has no per-user subscription, but it carries recurring costs for the PostgreSQL database, the Kubernetes or Docker hosts, backups, monitoring and the staff who run them. Before you compare, confirm with Zitadel how daily active users are counted, including whether sign-ins, token refreshes, machine users and service accounts count toward the limit. That definition can decide which tier you actually need.
The break point is the level of daily active users at which a subscription costs more than the self-hosted running cost it replaces, or the reverse. Start by projecting daily active users for the first two years, then identify the month in which you exceed the Free allowance and the month in which you approach the Pro allowance. For each tier, add the subscription fee and any overage terms, then compare that total with an annual estimate of your own infrastructure, database storage, backup, upgrade testing and on-call time. Ask Zitadel for overage terms in writing, because they determine how steeply cost rises above the included volume.
Enterprise is priced on request and is offered for self-hosted or cloud deployments, so the decision is not only cloud versus self-hosted. The plan includes custom support agreements and technical account management. Ask what the support agreement covers, which response expectations are written into it, whether the technical account manager is named, and how pricing is set for the number of instances and environments you run. Zitadel also lists ISO 27001, SOC 2 Type II and OpenID certification on its pricing page. Confirm whether each certification covers the Cloud service, the software or both, and what scope the certificate reports. DeployOpen does not issue audit reports or certifications.
Each plan also excludes certain things, and those exclusions can change the comparison more than the headline price. Confirm in writing the features, environments, data residency options, support hours, availability commitments and instance limits that are not included in Free, Pro or Enterprise. Then build one model with the same rows for every option: subscription fees, hosting, database operations, staff hours, upgrade and migration testing, and incident response. Assign an owner to each row. An estimate that leaves out staff time on a self-hosted option will usually understate its cost.
Which recurring costs continue after a self-hosted go-live
This table lists the costs that keep arriving after a self-hosted Zitadel goes live, who typically pays each one, and what to ask for in a quote. Read it as a checklist: every row is a line item you either staff internally or buy from a provider, vendor or partner. The main takeaway is that the software license is rarely the largest recurring item, and the operational rows are where self-hosted and Zitadel Cloud costs diverge.
| Recurring cost | Who typically pays | What to ask for in a quote |
|---|---|---|
| Compute for Zitadel replicas | Cloud provider or data center owner, billed by infrastructure team | Replica count, node sizes, autoscaling assumptions and which environments (staging, production, DR) are included |
| PostgreSQL hosting and storage | Cloud provider (managed service) or client staff (self-run database) | Supported PostgreSQL versions (14 to 18), managed or self-run split, storage growth assumptions and replica or failover setup |
| Backups and restore testing | Client staff, with storage billed by the cloud provider | Backup frequency, retention period, who runs scheduled restore tests and how often, and what evidence each test produces |
| Kubernetes cluster operation | Cloud provider for control plane, client platform team for upgrades and node pools | Whether the official Helm chart is in scope, who owns cluster upgrades, and which add-ons (ingress, certificates, secrets) are maintained |
| Monitoring and alerting | Client staff, or the observability vendor if one is used | Metrics and log retention, alert rules for login failures and database health, and who receives pages |
| Security patching and CVE response | Client staff, with partner retainer if contracted | Patch cadence for Zitadel, PostgreSQL and the operating system, and the time agreed to assess a vendor security advisory |
| Upgrade testing for each v4 release | Client staff or partner retainer, per release cycle | Test environment parity with production, database migration rehearsal, rollback plan and the release line to be followed (for example, v4.19.5 onward) |
| Staff time for on-call and identity administration | Client staff (internal payroll), or partner retainer for shared coverage | Hours of on-call coverage, escalation path, who creates organizations, projects and identity provider connections, and who approves policy changes |
| Support contracts | Zitadel for Enterprise plan support, or partner retainer, or none | Whether vendor support is included, response targets written in the agreement, and what the Zitadel Enterprise custom support agreement covers |
How a cost comparison runs from scoping to decision
This sequence turns a broad question about identity hosting into a costed decision. Each phase has a defined output, and later phases depend on the earlier ones, so the cost model stays reliable only when scope and licensing are settled first. The final memo lets leadership compare self-hosted Zitadel and Zitadel Cloud on the same assumptions.
Scope users, organizations and integrations
Your team lists the populations that will sign in, including workforce, customer and partner users, with estimated daily active user counts by month for the first year. It also lists the customer organizations that need separate identity providers, the applications and APIs that will integrate, and any SCIM provisioning or device login needs. The output is a written scope sheet with user counts, the organization model and an integration inventory. Both the self-hosted and Cloud models draw from this sheet, and a platform owner signs off that every assumption traces back to it.
Confirm license and compliance questions
Counsel reviews how the AGPL 3.0 license applies to your planned use, including whether you modify the core, Console or hosted login and whether you offer it to others over a network. Zitadel moved its core, Console and hosted login to AGPL 3.0 with v3.0 on 31 March 2025, while APIs, SDKs, Helm charts and Terraform configurations remain Apache 2.0. Auditors confirm which controls and evidence your environment must meet, and you ask Zitadel which certifications listed on its pricing page cover the Cloud service you would use. The output is a written license position and compliance requirements list, with each open question assigned an owner.
Model self-hosted and Cloud costs side by side
Build one model with two columns. The self-hosted column covers compute and storage for the Zitadel services and PostgreSQL, high availability, backups, upgrades, support, and staff time for administration and application integration. The Cloud column uses the plan that matches your scope. Zitadel's 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, while Enterprise pricing is a custom quote. Separate one-time costs from recurring ones, and label every input with its source and owner.
Test assumptions in a proof of concept
Deploy Zitadel in a non-production environment that matches the target method, whether Docker Compose, Kubernetes with the official Helm chart, or Linux binaries, and connect it to the PostgreSQL version you plan to operate. Zitadel documents support for PostgreSQL 14 through 18, so confirm which version your database platform offers and how it is patched. Measure what the model assumed: load at your expected daily active users, time spent on configuration and integration, and the steps for backup, restore and upgrade. The output is a proof of concept report that confirms, corrects or replaces each assumption from the model.
Deliver a decision memo
The memo states the recommendation, the cost model with its assumptions and sensitivities, the license and compliance position from counsel and auditors, and the proof of concept findings that changed the model. It separates one-time from recurring costs and lists the open questions for vendor quotes, including Enterprise terms such as custom support agreements and technical account management. Each figure cites its source, whether a vendor quote, a test measurement or an internal rate. The output is a memo the CISO, CIO or platform owner can approve, with named conditions for revisiting the choice if user counts or licensing terms change.
Where Zitadel cost comparisons go wrong
Cost comparisons between self-hosted Zitadel and Zitadel Cloud often fail on the same few assumptions. The cards below cover what teams most often leave out, from license obligations and database operations to upgrades, high availability, staff time and plan limits. Each card ends with the check to make before you rely on the comparison.
Reading the license as a cost line
Teams often treat the license as a number to compare against a subscription fee. Zitadel's core, Console and hosted login moved to AGPL 3.0 with v3.0 on 31 March 2025, while APIs, SDKs, Helm charts and Terraform configurations remain Apache 2.0. Prevention: have counsel confirm which AGPL obligations apply if you modify the software or offer it to users over a network, and budget that review before you compare against the Cloud plans.
PostgreSQL operations and restore testing
Self-hosted Zitadel stores its data in PostgreSQL, with versions 14 through 18 supported. Your costs include provisioning, patching, monitoring, storage growth, connection capacity and failover behavior, plus the time to test restores from backup. Prevention: ask Zitadel what the Cloud plan covers for the database, then price the same operational work for your own team, including a scheduled restore test.
Upgrades and database migrations
Each Zitadel release can include database migrations that must run in the correct order before the new version serves traffic. The v4 line is maintained with regular releases, and the latest release in our review is v4.19.5, dated 15 October 2026. Prevention: budget a recurring upgrade cycle that includes staging tests, a rollback plan and a Helm-based rollout window for every release you adopt.
Single instances and high availability
A single Zitadel instance is the cheapest option to start with, but a node, database or upgrade failure then stops sign-in for every application that depends on it. Zitadel recommends Kubernetes with the official Helm chart for high availability, which adds cluster, load balancer, replica and resilient PostgreSQL costs. Prevention: list which of these components your platform team already runs, then price the gaps into the self-hosted estimate.
Identity administration staff time
Someone must create instances, organizations and projects, manage federation with providers such as Entra ID or Okta, handle SCIM provisioning and investigate login incidents. These tasks recur every month and often fall to engineers who already carry other duties. Prevention: estimate administrator hours per month from your own team's history, then compare that figure with the support and technical account management terms offered in the Enterprise plan.
Daily active users against plan limits
Zitadel Cloud plans are sized by daily active users. The 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. Prevention: count every user who signs in on a given day across all customer organizations, partners and workforce users, then confirm with Zitadel how it defines an active user and whether Enterprise terms change the calculation.
How the comparison changes by starting point
When the current platform is a commercial product, the comparison turns on licensing and on operational work the vendor carries today. Self-hosting removes the platform subscription, but your team takes on infrastructure, database operations and upgrades. Zitadel Cloud plans are described by daily active user limits, so the comparison depends on how many people sign in each day.
- Subscription lines: the current vendor fees you stop paying, set against any Zitadel Cloud Pro or Enterprise fees you would pay instead.
- Infrastructure lines: compute, PostgreSQL, backups and load balancing in your own accounts. These recur every month.
- Staff lines: who runs upgrades, patching and on-call response, and whether that work moves from the vendor to your team.
- Exit lines: notice periods and remaining contract terms. These are usually one-time costs.
Before comparing totals, confirm the notice terms in your current contract, your peak daily active user count, and whether your team already runs PostgreSQL in production.
Teams moving off an older Keycloak or Auth0 setup often already run infrastructure, so some lines carry over while others change shape. Zitadel documents migration guides for both platforms. The cost question is less about the platform itself and more about how long two systems run side by side and how much client re-registration your applications need.
- Overlap lines: the cost of running the old and new systems together during cutover, including the old hosting and licenses.
- Migration lines: the work of moving users, applications and OIDC and SAML clients. Scope this as a one-time cost and ask a partner to price it from a written inventory.
- Infrastructure lines: existing hosts that may be reused for Zitadel, and the PostgreSQL setup you would need to add or extend.
- Skills lines: training for staff who know the old platform's administration model, which differs from Zitadel's instance and organization structure.
Before you plan, list every application, protocol and identity provider connection in use, and confirm which of them the migration guides cover for your source platform and version.
If your organization already runs Kubernetes, the largest cost lines usually shrink because the cluster, ingress and monitoring already exist. Zitadel recommends Kubernetes with the official Helm chart for high availability, so this starting point fits the documented deployment path. The remaining costs sit in capacity, database operations and the platform team's time.
- Capacity lines: extra nodes or resource requests for Zitadel replicas, measured against headroom you already pay for.
- Database lines: whether PostgreSQL runs on a managed service, an operator in the cluster, or separate virtual machines. Each option carries a different recurring cost.
- Operations lines: backup tooling, certificate handling and the platform team's time for Helm-based upgrades.
- Pipeline lines: the work to add the Helm chart to your existing GitOps or deployment pipeline.
Before comparing, confirm available cluster capacity, your standard for database operations, and whether your change process allows Helm-based rollouts into production namespaces.
For a small internal workforce, Zitadel can run on Docker Compose, which keeps infrastructure costs low. The trade-off is that a single host has no built-in redundancy, so the cost of downtime and recovery becomes the main variable. Compare your daily active user count with the Free plan limit of 100 and the Pro plan limit of 25,000 before deciding where to run it.
- Host lines: one virtual machine or server, plus storage and network, which recur monthly.
- Backup lines: scheduled PostgreSQL backups and periodic restore tests, both recurring.
- Patching lines: host operating system and container updates, which someone must own.
- Upgrade lines: the time to test and apply Zitadel upgrades on a single node, which is a recurring staff cost.
Before you commit, confirm the acceptable downtime for sign-in, who patches the host, and whether a restore has been tested. Also confirm, with counsel, what the AGPL license requires if you modify the software.
In air-gapped or sovereign environments, Zitadel Cloud is not an option, so the subscription line disappears and every infrastructure and operations cost falls to your organization. Zitadel Enterprise covers self-hosted deployments under custom pricing and includes support agreements, so the support decision is separate from the hosting decision. Offline delivery of software and updates adds work that connected environments do not need.
- Support lines: whether an Enterprise support agreement can be delivered inside the enclave, and what it costs as a custom quote.
- Delivery lines: mirroring container images, Helm charts and binaries into the environment, and the process for each update.
- Infrastructure lines: on-premises compute, storage and PostgreSQL, with no shared cloud services to lean on.
- Evidence lines: the effort to produce configuration records and access logs for your own assessors. Independent auditors, not the vendor, issue any attestation.
Before planning, confirm your sovereignty requirements, your offline patch cadence, and whether any support or delivery channel is allowed inside the enclave.
What the client needs to provide for an accurate comparison
The comparison is only as accurate as the volumes behind it. Start by counting current users by type: workforce employees, customers and partners, each with its own sign-in pattern. For Zitadel Cloud, the Free plan is priced around 100 daily active users and the Pro plan includes 25,000 daily active users, so the cloud side depends on daily active users (DAU), not total accounts. Estimate DAU for each user type across a typical month, and ask Zitadel to confirm exactly how it counts a daily active user before you compare figures. A count of registered accounts will overstate the cloud tier you need and understate the self-hosted load you must size.
Next, describe the shape of the deployment. List the planned instances and organizations, because each customer or partner organization may have its own identity provider and its own project grants. Count the upstream identity providers you expect to federate, such as Entra ID, Okta, Google, LDAP or OpenLDAP, and note which ones need SAML rather than OIDC. Confirm how many environments you need (development, test, staging, production and disaster recovery), since self-hosted environments each carry their own compute, database and backup cost. Record the target platform: Kubernetes with the official Helm chart, or Docker Compose, plus your PostgreSQL standard. Zitadel documents support for PostgreSQL versions 14 through 18, so state which version your database team will run and whether a managed service is acceptable.
Compliance obligations change the cost of both options. List the frameworks that apply to the identity service and the controls your auditor expects to test, such as access reviews, administrator privilege management, audit log retention and encryption of data at rest and in transit. Ask the auditor what evidence they will request and how long they expect it to be kept. Zitadel publicly lists ISO 27001 and SOC 2 Type II for its own service. Those attestations cover Zitadel's operation of its cloud service and do not transfer to your environment if you self-host. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the reports, so the evidence list belongs in your quote from the start.
Staff cost is the input most often left out. Provide the internal loaded hourly rates for the platform, database, security and identity engineers who would operate a self-hosted Zitadel, along with an estimate of their time already committed to on-call, upgrades and patching. List any existing support contracts with your database, Kubernetes or identity vendors that could be extended to cover Zitadel, and whether those contracts are priced per node, per core or per seat. Also name the decision owner: the single person who accepts the comparison, approves the budget and carries the outcome. Without a named owner, the model tends to be revised after each review, and the final figures never settle.
Licensing is the input that needs formal sign-off, and it belongs to legal counsel, not engineering. Since Zitadel v3.0 on 31 March 2025, the core, Console and hosted login are licensed under the GNU Affero General Public License 3.0, while APIs, SDKs, proto definitions, documentation, Helm charts and Terraform configurations remain under Apache 2.0. Ask counsel to review how AGPL 3.0 applies to your planned use, including whether you will modify the core and whether users will interact with it over a network. Security and architecture leads should confirm that the deployment model is acceptable, and procurement should record the decision. The decision owner should receive that written interpretation before the self-hosted figures are treated as final.
Questions buyers ask before pricing self-hosted Zitadel
What drives the cost of self-hosting Zitadel compared with Zitadel Cloud plans?
Self-hosting moves cost from a subscription to your own infrastructure and staff. Zitadel's pricing page lists a Free plan at US$0 per month for up to 100 daily active users, a Pro plan at US$100 per month including 25,000 daily active users, and an Enterprise plan with custom pricing for self-hosted or cloud deployments. On the self-hosted side, the recurring components are compute for Zitadel, a PostgreSQL database (versions 14 through 18 are supported), load balancing, backups, monitoring, log storage, and the people who patch, upgrade and respond to incidents. Costs rise with user volume, the number of environments and your availability target. Ask for a quote that separates one-time setup from monthly run costs, then compare it with the Cloud plan that matches your daily active user count and support needs.
Does the AGPL license change the decision for internal self-hosting?
For many internal deployments the AGPL is not a barrier by itself, but it carries obligations you should confirm with counsel. Zitadel moved its core, Console and hosted login from Apache 2.0 to AGPL 3.0 with v3.0 on 31 March 2025. APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache 2.0. The AGPL's network clause matters most when you modify the AGPL components and let users interact with the modified version over a network, including customers who sign in through your login pages. Running unmodified Zitadel as an internal workforce identity provider is a different position from changing the login interface and offering it to external customers. Ask counsel to review your specific use, modifications and distribution model before you commit budget.
How long does a self-hosted Zitadel cost comparison take?
The time depends on how much input you already have, so no fixed duration applies. Teams with current user counts, cloud spend records and an agreed list of applications and identity providers can finish faster than teams that must first measure usage or settle requirements. The main drivers are the number of Zitadel instances and organizations you plan, the identity providers to federate, the number of applications to reconnect, the availability target you need, and how many stakeholders must approve the trade-offs, including security, legal and finance. Before accepting a timeline from any provider, ask for the work plan, the inputs they need from you, and the assumptions the timeline depends on.
Can our own team build the Zitadel cost comparison without a partner?
Yes, a capable internal team can build the comparison, and Zitadel's documentation covers the deployment options and PostgreSQL requirements you need. The model has three parts: a Cloud plan calculation based on daily active users, a self-hosted run cost model, and a staffing estimate. Your team must model compute, storage, backups and environments, and it must account for the people who operate PostgreSQL, Kubernetes or Docker, identity configuration and upgrades. Check that operations time and upgrade testing appear in the model, since they are easy to leave out. If your staff lack recent experience with these systems, or you want an independent review of the numbers, a partner can scope that work in writing. Either way, base the model on your measured usage.
What skills and staff time does a self-hosted Zitadel deployment need?
You need people who can run the platform after go-live, not only people who can install it. The core skills are Kubernetes or Docker operations, PostgreSQL administration, TLS and secrets handling, and identity configuration for OpenID Connect, OAuth 2.0 and SAML 2.0 clients. Someone must own upgrades, which means reading release notes, testing database migrations in a non-production environment and scheduling rollouts. Backups and restore tests need an owner, and so does on-call response for login failures, because every application that depends on Zitadel is affected by them. Staff time recurs every month, even when the platform is stable. Ask for hours per role in your estimate, and confirm who covers absences.
Does DeployOpen issue ISO 27001 or SOC 2 certifications for Zitadel?
No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. DeployOpen can prepare your systems, configuration, controls and evidence for a compliance assessment, such as documenting access control, backup and change records for the Zitadel deployment. Zitadel's pricing page lists ISO 27001, SOC 2 Type II and OpenID certification for Zitadel itself. Those listings describe the vendor's own organization and products, and they do not certify your deployment, hosting environment or processes. Ask your auditor which evidence they need, and confirm the current status of any vendor certification directly with Zitadel before you rely on it.
What does a fixed-scope DeployOpen engagement for Zitadel cover?
A fixed-scope engagement covers the work set out in a written scope, with deliverables and timelines agreed before work starts. For a self-hosted Zitadel, the scope is typically built from the parts you name, such as instance and organization design, deployment with Docker, Kubernetes or the official Helm chart, PostgreSQL configuration, application integration and operating documentation. Work outside the written scope, such as additional identity providers or a migration from another platform, needs its own scope and quote. DeployOpen does not publish a price list. The quote follows from the written scope. Ongoing support, upgrades and continuous testing are available as separate retainers. Ask for the exclusions in writing alongside the deliverables.
How DeployOpen scopes, delivers and supports a Zitadel cost review
DeployOpen approaches Zitadel cost of ownership as a written comparison of your self-hosted footprint against the Zitadel Cloud Free, Pro and Enterprise plans. We start from your license position under AGPL 3.0, your PostgreSQL and Kubernetes or Docker estate, and your user volumes, then document the costs each option carries. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- The written scope names your deployment model, plan options and user volumes to compare.
- It covers licensing review of AGPL 3.0 obligations for your own changes and hosting model, confirmed with your counsel.
- Fixed-scope terms set deliverables and timelines in writing before any review work starts.
How we build
- We inventory self-hosted cost lines: compute, PostgreSQL, storage, backups, networking, monitoring and on-call effort.
- We map each Zitadel Cloud plan's limits, including daily active user thresholds, against your expected usage.
- Where the Enterprise plan is a candidate, we list what its custom support and technical account management would cover.
How we hand over
- A cost model workbook with assumptions, formulas and sensitivity inputs your finance and platform teams can change.
- A written comparison of self-hosted and Cloud options, with recurring and one-time costs separated.
- A quote checklist for Zitadel Cloud plans and for any outside partner or vendor support.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the review leads to a decision.
- Cost assumptions can be revisited under a retainer when v4 line upgrades change the footprint or database needs.
- Licensing questions outside the written scope are handled as a separate item agreed in writing before work begins.
