Zitadel implementation plan and cost

What a Zitadel implementation involves

A self-hosted Zitadel implementation covers four workstreams: planning the instance and organization model, deploying Zitadel with PostgreSQL, connecting applications over OpenID Connect and SAML, and handing operations to the team that will run the platform. The planning step sets the structure everything else depends on. Decide how many Zitadel instances you need, since an instance is a virtual tenant with full data isolation, and then decide how organizations and projects sit inside each instance. Those choices are hard to reverse later, so they belong in the first phase, before any application is connected.

Deployment is the most visible part of the work. Zitadel can run from Linux binaries, Docker Compose or Kubernetes, and its documentation recommends Kubernetes with the official Helm chart for high availability. Each option needs a PostgreSQL database, with versions 14 through 18 supported, plus TLS, a secrets approach for the master key and database credentials, and a backup routine. Confirm the PostgreSQL version your database platform team will support, and confirm which deployment method matches your existing operations skills.

Typical triggers for the project are replacing a hosted identity provider, consolidating several separate logins into one, or serving customer and partner identities from infrastructure the organization controls. Each trigger changes scope. Migrating existing users and re-registering clients is a separate piece of work, as is federating login with Entra ID, Okta or LDAP. Ask your team to list every application that signs in users and every identity source that holds them, because that inventory drives most of the effort.

Most organizations with a platform team that already runs PostgreSQL and Kubernetes or Docker can scope and build the core deployment in-house, then bring in a partner for the identity design, migration waves or the first integrations. Teams without those skills, or with a deadline tied to a hosted provider contract, usually scope the full implementation with a partner and keep an internal owner for operations. Request a written scope that names each workstream, the deployment method, the applications in the first wave and the handover tasks.

What the work includes

Each workstream ends in a document or configuration your team keeps, so the platform can be run after go-live without the partner on call.

Discovery and architecture

We map the users, applications, identity providers and hosting constraints that shape the design, then record the key choices in a written architecture decision record. Typical decisions include the deployment method (Kubernetes with the official Helm chart, Docker Compose or Linux binaries) and how the AGPL terms apply to your use. Check that the record names an owner for each open decision.

Instance and organization design

Instances give full data isolation, so how many you run is a tenancy, administration and blast-radius decision. Inside an instance, organizations hold projects and users, and each customer organization can carry its own identity provider. The deliverable is a tenancy diagram and a configuration specification listing instances, organizations, projects and grants.

Deployment and PostgreSQL setup

This covers the deployment target you select, TLS, database credentials, PostgreSQL topology and sizing for your expected load. Confirm the PostgreSQL version against the Zitadel supported list (versions 14 through 18) before the build starts. The deliverable is a deployable configuration, with secrets handling documented and agreed with your operations team.

Application integration and federation

Each application is registered over OpenID Connect, OAuth 2.0 or SAML 2.0, and login can be federated to Entra ID, Okta, Google, LDAP or another OIDC-compliant provider. Confirm redirect URIs, claim mappings and token lifetimes with each application owner. Deliverables are a tested integration runbook per application and a federation configuration per identity provider.

Provisioning and login policy

Where an HR or directory system is the source of truth, SCIM v2 provisioning keeps account creation and removal in step with it. Passkey sign-in with password fallback and MFA rules are set per organization. Test deprovisioning explicitly, because accounts that outlive their source record are a direct access risk. The deliverables are a provisioning mapping and a written login policy.

Observability, backup and handover

Metrics, logs and alerts are configured for Zitadel and PostgreSQL, and backups are restored in a test environment before go-live. Ask for a restore test record as part of the handover. The handover includes an operations runbook, an upgrade procedure and named escalation paths, so your team can take over day-to-day operation.

What drives cost and duration

This table lists the factors that most change the effort of a self-hosted Zitadel rollout, why each one moves the work, and what the client can do to keep it contained.

Driver	Why it moves effort	How to keep it down
Organizations and identity providers	Each customer or business unit organization may bring its own identity provider, which means its own federation setup, claim mapping and testing. Zitadel allows a different identity provider per organization, so every extra one is a separate integration track.	Standardize on one federation pattern, such as one OIDC or SAML broker, and add per-organization providers only where a customer contract requires them.
Applications and client registrations	Each OIDC or SAML client needs redirect URIs, scopes, roles, grants and token checks, and each one is a separate test case. Count both web, mobile and API clients, since each registration is configured and verified.	Limit the first release to a named list of applications and migrate the rest in later waves. Reuse one project and role model across similar applications.
User volume and daily active user profile	Sizing depends on how many users sign in each day, peak login bursts and whether users are workforce or external customers. Higher peaks raise database, replica and load testing work. Confirm the expected profile in writing before sizing.	Ask for an agreed daily active user estimate and peak pattern up front, and plan load tests against that number rather than total registered users.
PostgreSQL topology and backup requirements	Zitadel stores its data in PostgreSQL, supported in versions 14 through 18. A single instance needs less setup than a replicated, highly available cluster with point-in-time recovery, and each restore test adds verification time.	Confirm whether your organization already runs a managed or standard PostgreSQL platform that meets the required version range, and agree on backup and restore test scope before build.
Deployment target	Docker Compose, binaries and Kubernetes with the official Helm chart differ in setup, networking, secrets handling and high availability work. Zitadel recommends Kubernetes with the Helm chart for high availability, so a non-Kubernetes target usually adds design work.	Choose the target your platform team already operates. Avoid mixing targets across environments.
Number of environments	Each environment, such as development, test, staging and production, needs its own instance configuration, secrets, database and deployment pipeline. Environment parity is where many rollout delays start.	Keep the number of environments to what testing needs, and automate deployments so each additional environment is a configuration change, not a new build.
Login and Actions customization	Custom login branding, per-organization settings and Actions for custom logic each add design, development and regression testing. Customization that changes login flows is the most time-consuming item to revisit at each upgrade.	Limit custom login pages and Actions to what the business requires, and keep logic in documented, versioned code so upgrades stay predictable.
Data migration from another identity system	Moving users from Auth0, Keycloak, Firebase or another Zitadel instance involves mapping user attributes, passwords or migration approach, and re-registering OIDC and SAML clients. Just-in-time migration and up-front import carry different validation and rollback work.	Inventory user stores and clients early, pick one migration approach, and run a pilot cohort before the full move.
Compliance evidence required	Assessors may ask for evidence of access control, change records, backup restores, audit logs and configuration baselines. Collecting this evidence is extra work on top of the build. DeployOpen prepares evidence for assessments, while independent auditors issue any report.	Agree the control list and evidence format before the build starts, and confirm with your assessor which artifacts they expect.

Project phases and outputs

The rollout moves from requirements and design through tested non-production environments and pilot integrations to a controlled go-live and handover, with a named output at each phase.

Confirm requirements and threat model
Your security, identity and application owners agree which user populations, customer organizations, protocols and identity providers Zitadel must serve, and DeployOpen maps the threats to those identities. The step closes with a signed requirements register and a threat model that lists the trust boundaries and admin access paths the design must cover.
Design architecture and instance layout
The team decides how instances, organizations and projects map to your tenants and applications, where Zitadel runs (Kubernetes with the official Helm chart, Docker Compose or binaries), and how traffic, TLS and secrets are handled. The output is a signed design decision record that the security and platform owners approve before any build starts.
Build non-production environments with PostgreSQL
DeployOpen builds development and staging environments in your infrastructure, with a PostgreSQL database on a version that Zitadel supports and the chosen deployment method. The step is complete when a tested Helm values set or deployment definition installs cleanly from your pipeline and the instance can be rebuilt from code.
Integrate pilot applications
A small set of applications is connected over OIDC or SAML, with any agreed upstream identity providers and SCIM provisioning configured. The output is a working pilot set and a documented client configuration for each application, including redirect URIs, roles and grants.
Plan testing and cutover
The team writes an integration test matrix covering login flows, MFA and passkey policies, role claims, failure cases and admin actions, then runs it against staging. The step closes with a rollback plan that names the trigger conditions, data handling and the owner who can invoke each reversal.
Go live in production
The approved change is executed in your production environment, with backups verified before the cutover window, applications switched in the agreed order and the integration test matrix repeated against production. The step closes when the production checks pass and the rollback plan has been confirmed as unnecessary for the agreed period.
Hand over to operations
Your operations team receives the runbooks, upgrade and backup procedures, monitoring and alert definitions, and the access model for administrators. The handover is complete when your team has performed a supervised restore test and a configuration change from the documentation, and the written scope defines the timing of each step and any support that follows.

What teams keep in-house and what they outsource

This table compares the Zitadel work an internal team usually keeps with the work teams often outsource, names the skills each row needs, and shows when a partner adds the most value.

Work area	Usually kept in-house	Often outsourced	Skills needed and when a partner helps most
Identity ownership and policy	Deciding who owns each customer or workforce identity, which login methods are allowed, and how MFA and passkey policies are set	Facilitating the policy workshops and documenting the decisions as configuration	Security engineering and identity federation. A partner helps most when stakeholders disagree on policy and need a documented baseline quickly.
Application owners and clients	Owning each application, its redirect URIs, scopes and role grants after handover	Integrating many OIDC and SAML clients with consistent settings and test cases	OIDC and SAML protocol knowledge. A partner adds the most value when dozens of clients must be onboarded in a common pattern.
Customer administration	Running day-to-day customer organizations, user requests and delegated admin decisions	Designing the organization and project model and the delegated administration pattern	Identity federation and Zitadel concepts for instances, organizations and projects. An in-house team can run this once the model is set.
Architecture review	Approving the target design against internal security and network standards	Reviewing instance layout, organization design, database topology and the Kubernetes or Docker choice	Kubernetes operations and security engineering. A partner helps when the team has not run an identity platform in production before.
Cluster and database build	Providing accounts, network access and change approval	Building the Kubernetes cluster or Docker hosts and the PostgreSQL setup with backups and failover	Kubernetes operations and PostgreSQL administration. An in-house team with these skills can usually build this directly from the vendor documentation.
Helm deployment and configuration	Holding the values files, secrets and release approvals	Writing Helm values, the master key handling, TLS setup and the first rollout	Kubernetes operations and security engineering. The official Helm chart is the recommended route for high availability, so teams without Kubernetes experience gain the most from help here.
Test automation and documentation	Owning the test suite, runbooks and operational procedures after go-live	Building login, token and federation tests and writing the runbooks and architecture records	Security engineering and OIDC and SAML protocol knowledge. An in-house team can maintain tests once the first set is delivered and reviewed.

What goes wrong and how to prevent it

Most Zitadel rollouts that stall or need rework trace back to a small set of decisions made late or left to chance. Each card names one pattern and the scoping step that prevents it.

Instance and organization model deferred

Teams sometimes build projects and grants first and decide on instances and organizations later, which forces a restructure of users, roles and application grants. Before build starts, record the instance boundary, the customer or partner organizations, and the projects each one needs. Check this against the delegated administration you plan to hand out.

PostgreSQL operations left unowned

Zitadel stores its data in PostgreSQL, with versions 14 through 18 supported, so the database version, upgrade schedule and backup owner must be named in scope. Teams often assume backups work without ever restoring them. Ask for a documented restore test on the chosen PostgreSQL version and a clear owner for major upgrades.

Deployment target chosen too early

Zitadel runs from Linux or macOS binaries, Docker Compose or Kubernetes, and its documentation recommends Kubernetes with the official Helm chart for high availability. A target the team cannot patch, monitor and recover adds risk after go-live. Assess existing skills for each option and let that assessment set the target.

Integrations without a shared test matrix

Each application connected over OIDC or SAML can differ in redirect URIs, grant types, token claims and logout behavior. Without one shared matrix, a change for one application can break another, and nobody notices until users report it. Make the matrix a scoping deliverable that lists every client, flow and claim that must pass before release.

Federation without a fallback path

Federating login with Entra ID, Okta, Google, LDAP or another provider moves part of the sign-in dependency outside your control. When that provider fails or a customer's directory changes, users can be locked out with no route back in. For each provider, document a fallback sign-in method and an administrator recovery path, then test both before launch.

Passkey and password policy after launch

Zitadel supports passkeys based on FIDO2 and WebAuthn, with password login available as a fallback. Deciding enrollment, fallback and MFA rules after launch changes sign-in behavior for users who are already active. Set the policy per organization during scoping, covering who may register passkeys, when passwords remain allowed and how account recovery works.

How the work changes by starting point

With no existing identity system, the plan centers on design decisions, and no user data moves in. Most of the early effort goes into agreeing the model before any build starts.

Instance and organization design: decide how many instances, organizations and projects you need, and who administers each one.
Identity sources: list the workforce directories, social logins and partner identity providers that must federate on day one.
Application inventory: count the OIDC and SAML clients, their redirect URIs and the roles each one needs.
Client input: named owners for the admin model, login policy and the hosting account or cluster.

What you need to provide

Scoping cannot finish until you name an accountable business owner for identities and a security owner who can approve the design, the access model and the evidence set. Without these two people, decisions about organizations, admin delegation and login policy stall, and the quote carries open assumptions that tend to become change requests later. Confirm both names before the first scoping call.

Provide an inventory of every application that will sign in through Zitadel, with its protocol (OIDC, OAuth 2.0 or SAML 2.0), redirect and logout requirements, approximate user counts, and whether it is customer-facing or workforce-facing. Each application becomes a project, grant and integration task, so the count and protocol mix drive most of the integration effort. List identity providers too: each federated source (Entra ID, Okta, Google, LDAP or another OIDC or SAML provider) needs its own configuration, attribute mapping and test accounts, and each customer organization that brings its own provider adds more of the same.

Supply your network and DNS plan, the target Kubernetes cluster or virtual machine capacity, and the access you can grant to build and operate it. Confirm whether PostgreSQL already exists as a managed or supported platform, or whether you want one built as part of the work. Zitadel supports PostgreSQL 14 through 18, and a database you must build, harden and back up adds a distinct workstream. Also state your backup, restore and retention requirements, along with the compliance obligations and evidence you must produce, since those set the depth of logging, testing and documentation.

Name who decides login branding, password and passkey policy, MFA requirements and self-service behavior. Those choices shape customization and policy configuration, and late reversals are common when a marketing or legal reviewer sees the login pages for the first time. Ask your partner to put each open decision in the written scope with an owner and a date, so the quote reflects what is settled and what is still assumed.

Common questions about Zitadel implementation

How is the cost of a Zitadel implementation built up?

The cost comes from the scope you agree in writing, priced as the labor to deliver it plus any infrastructure you buy. One-time work includes discovery and architecture, instance and organization design, deployment on Kubernetes or Docker, PostgreSQL setup, application and identity provider integration, testing and handover. Recurring costs include the infrastructure that runs Zitadel and PostgreSQL, backups and monitoring, staff time for upgrades and incident response, and any support retainer. The number of applications, identity providers and customer organizations, plus the state of your existing platform, drives the effort most. DeployOpen does not publish a price list, so ask for a quote that separates one-time and recurring items.

How long does a Zitadel rollout take to implement?

No fixed duration is given without a written scope, because the timeline depends on the work inside it. The main drivers are the number of instances and organizations to design, how many applications need OpenID Connect or SAML integration, and whether identity providers such as Entra ID, Okta or LDAP must be federated. A migration from Auth0, Keycloak or Firebase adds user and client re-registration work. The maturity of your Kubernetes and PostgreSQL platforms also matters. A scope that lists these items lets a partner propose milestones, client dependencies and a plan for slippage.

Can a small team implement Zitadel without outside help?

Yes, a small team can deploy Zitadel alone if it already runs Kubernetes or Docker, operates PostgreSQL, and has someone who understands OpenID Connect and SAML. Zitadel documents Linux and macOS binaries, Docker Compose and Kubernetes deployments, so installation is rarely the hardest step. The harder work is usually design: instance and organization structure, identity provider federation and application integration. Master key handling, backups and upgrade testing are also easy to get wrong when done only once. Outside help is most useful when those skills are missing or the go-live date is fixed.

What do we need to provide for a Zitadel implementation?

The engagement needs named decision makers, an inventory of applications with their login protocols, and the identity sources to federate. You also need to provide access to the cloud accounts, clusters or data centers where Zitadel will run. Expect to supply DNS records, TLS certificates, a PostgreSQL platform or permission to build one, and a secrets store for the master key and database credentials. Someone must own the organization model, meaning which customers, partners and workforce groups get their own organization. Confirm these inputs in the written scope, because each missing input moves the schedule.

Which PostgreSQL versions and deployment methods does Zitadel support?

Self-hosted Zitadel uses PostgreSQL as its database, with versions 14 through 18 supported, so confirm your target version falls in that range before design starts. Zitadel documents self-hosting on Linux and macOS binaries, Docker Compose and Kubernetes. For high availability, its documentation recommends a Kubernetes cluster with the official Helm chart, and that choice shapes your database layout, load balancing and upgrade procedure. Docker Compose is a simpler option, but confirm with the vendor documentation whether it meets your availability target. Check support against the Zitadel release you plan to run.

Does DeployOpen issue compliance certifications for Zitadel deployments?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue audit reports and certification bodies issue certifications. For Zitadel, preparation means documenting configuration such as master key handling, TLS, admin access, MFA and audit trail review in a form an assessor can test. Zitadel publishes its own certification claims on its pricing page, and those describe Zitadel as a vendor, so they do not transfer automatically to your deployment. Ask your assessor which evidence they need before the build starts.

How DeployOpen scopes and delivers Zitadel work

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted Zitadel inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Written scope lists the Zitadel instances, organizations and projects to be designed and the applications to be connected.
Scope records the deployment target, Kubernetes or Docker Compose, and the PostgreSQL version and hosting model to be used.
Scope names the identity providers to federate and the user populations, including customer and workforce users, each one covers.

How we build

Build covers the Zitadel deployment, PostgreSQL configuration and the application integrations listed in the written scope.
Testing checks OIDC and SAML sign-in flows, role and grant behavior, and federated login against each agreed identity provider.
Build output includes configuration held as code so environments can be rebuilt and reviewed in your own change process.

How we hand over

Handover includes architecture and configuration documentation for the instance, organization and project design delivered.
Your team receives runbooks for backup, restore, certificate handling and the upgrade steps agreed in the written scope.
Handover confirms which tasks your team owns after go-live and which ones the written scope assigns to DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the implementation.
Ask whether a retainer covers Zitadel version upgrades, database migrations and Helm chart updates in your environment.
Confirm response expectations, service levels and escalation paths in the written agreement before the retainer starts.