Zitadel customization: when a self-hosted team brings in outside help
Customization is usually a bounded engagement inside an existing or planned Zitadel deployment, not a rebuild of the identity platform. Many teams that run self-hosted Zitadel keep day-to-day configuration in-house, such as creating organizations, projects and applications, and rely on a partner for the design, build and upgrade safety of the parts that change how users see and move through login. The usual trigger is a change in what the login experience has to do. A new customer-facing product may need login pages that match its brand instead of the default hosted login. A partner portal may need each partner organization to see its own look, its own sign-in options and its own rules. A change of brand touches every login screen at once. Each of these moves the work from configuration toward custom front-end code, branding assets and logic that runs during authentication, which is where an outside team with recent Zitadel experience can shorten the path.
Another trigger is organization-specific behavior. Zitadel separates instances, organizations and projects, and a single instance can host many customer organizations, each with its own identity provider, policies and administrators. When one organization needs a different login flow, an extra claim in its tokens, or a check against an external system before a session starts, the requirement usually lands in Zitadel Actions. Teams should decide early which Actions belong to the platform team and which belong to a product owner, because that decision shapes how the work is scoped and handed over. Before you ask for a quote, inventory the customizations you expect. For each one, record the users affected, the organization or instance it applies to, the systems it calls, and who will own it after go-live. Confirm with your own security team which login and token changes need review, and check whether the target environment is self-hosted in your cloud account, a data center or an air-gapped network, because that affects how assets are deployed and tested. A written list like this gives an implementation partner the input it needs to propose a fixed scope.
Outside help is most useful when the customization has to survive upgrades. Zitadel's self-hosted releases change over time, and a branded login or an Action that depends on internal behavior can break during a version change if nobody tested it against the new release. Ask any partner how they will version custom assets, keep Actions and API calls in source control, and run a regression pass on login flows before each upgrade. Confirm with Zitadel's release notes and documentation which interfaces you depend on, because a custom component is only as stable as the surfaces it touches.
What a Zitadel customization engagement includes
Each work stream below is agreed in writing before work starts, and the exact boundaries depend on the Zitadel version in use. Together the cards cover what changes, how changes are scripted and tested, and how your team operates them after handover.
Login UI branding within supported options
Login pages, logos, colors and text are adjusted only through the branding options the installed Zitadel version exposes. We confirm which elements can be changed for your version before design starts, then record the agreed settings in a configuration repository so they can be reapplied after an upgrade. Check that the branding covers every sign-in path your users take, including password, passkey and federated login, and that all custom text is reviewed for translation and accessibility. The deliverable is the versioned branding configuration and screenshots of each login screen for sign-off.
Per-organization settings and documentation
Zitadel places customers into organizations inside an instance, and each organization can carry its own login and policy settings. We map which settings vary by organization, such as identity provider choice, password and MFA policy, and branding where supported, then document each value and its owner. Check that the matrix matches how customer onboarding actually works, because every organization created later follows the same process. The deliverable is a settings matrix and a documentation page for each organization type.
Actions for login and tokens
Actions run custom code in login and token flows, for example to add claims or enforce a rule during sign-in. Each Action is written against the triggers and inputs documented for your Zitadel version, so we confirm those before design starts. Check the failure behavior closely, since a faulty Action can block sign-in for every user in its scope, which makes timeouts, error handling and staged rollout points that need explicit agreement. The deliverable is the Action source in the configuration repository, with its tests.
API-driven configuration automation
Repeatable setup such as organizations, projects, roles and grants runs through the Zitadel APIs in scripts, so the same change can be applied to each environment in the same way. We agree which objects are scripted and which remain manual, and we confirm the API surface for your version. Check that scripts can be run more than once with the same result, that the service account credentials are scoped and held in a secrets manager, and that a dry run is possible before production. The deliverable is the script set and its README in the configuration repository.
Test coverage for every change
Each branding setting, per-organization value, Action and script gets a test that checks the behavior it is meant to produce. Tests run against a non-production instance built from the same configuration, so failures appear before a change reaches customers. Check that the suite also runs after a Zitadel version upgrade, since flow behavior can change between releases. The deliverable is the automated test suite, its run instructions and a record of results for the agreed scope.
Runbook and handover session
The runbook explains how each customization is applied, verified, rolled back and reapplied after an upgrade, and it is written for the engineers who will operate it. A handover session walks your team through the repository, the test suite and the change procedure, and records open questions. Check that the runbook names an owner for each Action and each per-organization setting, because unowned customizations are the ones most likely to break during upgrades. The deliverable is the runbook and a documented handover session with the attendees you agree on.
What drives Zitadel customization effort and how to keep it down
This table lists the main drivers of Zitadel customization effort, why each one moves cost or duration, and what keeps it manageable. Read each row against your own organization count, login flow count and change process before estimating scope. The main takeaway is that most effort grows with repetition, so templated settings, versioned logic and scripted changes usually matter more than any single feature.
| Driver | Why it moves effort or duration | How to keep it down |
|---|---|---|
| Customer organizations with their own branding or settings | Each organization with distinct branding or settings is another configuration to build, test and keep in step with the others. | Template shared settings once and drive per-organization values from a reviewed configuration file. |
| Login flows and languages | Each flow, branch and translation adds test cases and review work, and the total grows with every organization that uses them. | Keep flows few, share one flow across organizations where policy allows, and translate only the languages users need. |
| Custom Action logic and external dependencies | Custom code runs in the login path, so every call to an outside system adds latency, failure modes and security review. | Keep logic small, store it in version control, and cache or move external lookups out of the login path. |
| Automated API changes or manual console changes | Changes made by hand are slow to repeat across environments and harder to show to an assessor. | Script configuration through the Zitadel APIs and limit production changes to tested, reviewed scripts. |
| Number of environments | Development, staging and production each need the same changes applied and verified, so effort rises with every environment. | Promote the same versioned configuration through each environment and keep environment-specific values in separate variables. |
| Compliance evidence needed per change | Each change may need a ticket, test record, approval and retained export, which adds time before every release. | Agree the evidence list with your assessor early, generate exports from pipelines, and group low-risk changes into set release windows. |
| Zitadel Cloud or self-hosted | Self-hosting adds upgrade testing, database operations and deployment pipelines to the work your team does alongside customization. | Confirm which operations your team owns before design starts, and plan customization around your upgrade cycle. |
Keeping Zitadel customizations upgrade-safe under AGPL
Zitadel's core, Console and hosted login moved from the Apache 2.0 license 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 under Apache 2.0. The practical consequence for customization is that the AGPL-covered components are the ones where a change to the code creates the most licensing and upgrade exposure. Before any work starts, classify every planned change by the component it touches, because that classification decides both the legal review and the engineering approach.
The upgrade risk is driven by how far a customization reaches into code that Zitadel ships and changes. A fork or patch of the core, Console or hosted login means your team owns a diff against every release. Each new version then requires rebasing that diff, re-running your tests against changed internals, and re-validating login flows that your users depend on. The cost of that work grows with each release you skip. By contrast, customizations built through supported configuration, the APIs and Actions depend on documented interfaces, so a release is more likely to need a version bump and a regression run than a code merge.
Licensing questions need a specific answer from your legal counsel, not an assumption. Ask counsel how the AGPL source-sharing duties apply to each modified component you distribute to third parties, and how they apply when you modify a component and offer it to users over a network, such as a customer-facing login page you host for your own customers. Also ask whether your use of Apache 2.0 components, such as an API client or a Terraform module, creates different obligations from the AGPL-covered components in the same deployment. Record the answers in writing against each customization, because the answer may change with the way you deploy.
To keep customizations upgrade-safe, prefer the following order: first, express the behavior through instance and organization settings and branding configuration; second, automate it through API clients built on the Apache 2.0 APIs, SDKs and Terraform configurations; third, add custom logic through Actions. Reserve changes to core, Console or hosted login for cases where no supported route exists, and treat each of those as a maintained fork with a named owner and an upgrade budget. Keep a register of every customization, its component, its owner and the test cases that cover it.
Test each release candidate before it reaches production. Run your configuration checks, API client test suite, Action tests and end-to-end login journeys against a staging instance built from the candidate version and a copy of your production configuration. Check any release notes for changed API behavior, deprecated fields and database changes, and confirm the supported PostgreSQL versions for the release with the vendor documentation. Keep the previous version available so you can roll back if a regression appears, and schedule upgrades so that the dependent teams can sign off on login behavior before the change goes live.
How a Zitadel customization project moves from brief to handover
This sequence takes a Zitadel customization from a written brief to a supported change in production. Each phase produces a named output that the next phase depends on, and the order keeps configuration in version control and tested before it reaches customer logins. Ask for a schedule in the written scope.
Discover branding, organizations and custom logic
The project starts with a discovery session where your team and DeployOpen identify the login branding to apply, the instances, organizations and projects the changes touch, and any custom logic that must run during sign-in or user changes. Your team supplies brand assets, the list of customer organizations and their identity providers, and the business rules behind each Action. The output is a written discovery summary that lists each requirement, its owner and the open questions to resolve before design. Ask for the discovery schedule in the written scope.
Design configuration and Action logic
DeployOpen turns the discovery summary into a design covering branding settings, per-organization policies, the Actions that run custom logic, and any API calls used for automation. Each Action is specified with its trigger, inputs, outputs, failure behavior and the data it reads or writes, so reviewers can check it against your security and privacy requirements. Your identity and security owners review and approve the design before build starts. The output is an approved design document and a list of Actions with acceptance criteria.
Build in a non-production instance
Build happens in a non-production Zitadel instance that mirrors the production deployment as closely as the scope allows. Configuration and Action code are kept in version control, and changes are applied through repeatable scripts or infrastructure-as-code, with no manual edits in the console. Each change is reviewed before it is merged. The output is a non-production environment that matches the approved design, plus a repository with a history of every change traced back to a requirement.
Test login flows, including password fallback
Testing covers every login path the customization touches: sign-in and registration for each organization, branding on every screen, Action behavior on success and failure, and identity provider federation where it applies. Where passkeys are enabled, testers confirm that users can fall back to password login when a passkey is unavailable, lost or unsupported on a device. Results are recorded per test case with the account type, browser and device used. The output is a test report listing passed, failed and deferred cases, with each defect tracked to closure.
Test against the next Zitadel release
Before production, the customization is tested against the next Zitadel release so that changes affecting the login UI, Actions or APIs surface while there is still time to adjust. DeployOpen deploys the release candidate to a separate non-production instance, reruns the full test suite and checks the database upgrade path. Your team confirms whether any Action or API call needs changes. The output is a compatibility report stating which items pass unchanged, which need code changes, and which depend on vendor behavior that you should confirm with Zitadel.
Roll out to production
The approved change is deployed to production in an agreed window using the same scripts used in non-production, so the production result matches what was tested. Before rollout, the team takes a database backup and confirms the rollback path. Smoke tests run immediately after deployment across sign-in paths for representative organizations. The output is a production change record that lists the deployed configuration version, the test results and the prepared rollback steps.
Hand over with a runbook
Handover includes a runbook that explains how to operate the customization: how branding and organization settings change, how Actions are deployed and disabled, what to check after an upgrade, and how to diagnose common login failures. Your operations team attends a walkthrough and performs one supervised change. The output is the runbook, repository access, a list of open items with named owners, and a record that your team completed the supervised change. Confirm in the written scope what support follows handover.
Which Zitadel customization work your team can keep and which to outsource
This table maps each part of Zitadel customization to the team that usually owns it, along with the skills that work requires. Read it to decide which parts your own staff can run after go-live and which parts are worth scoping to a partner for the first build. Most teams keep brand, configuration and upgrade routines in-house and outsource only the initial Actions build and the security review of custom code.
| Work part | Who usually does it | Skills required |
|---|---|---|
| Brand and copy decisions for the hosted login | In-house, owned by product or marketing with the identity team | UX writing, brand guidelines, and enough theming knowledge to confirm which login styling options your Zitadel version exposes |
| Choosing which settings apply per organization | Shared: security sets policy, platform team applies it | Understanding of instances, organizations and projects, plus OIDC and SAML concepts for each customer's identity provider |
| Writing and testing Actions and API automation | Partner for the first build, then in-house | Scripting in the language the Actions documentation specifies for your version, API authentication with service accounts, and CI pipelines for automated tests. Confirm the runtime before hiring. |
| Security review of custom code and secrets handling | Partner or the internal security team | Secure code review, secrets management for API credentials, and least-privilege design for API access |
| Upgrade testing against each Zitadel release | Shared: platform team runs tests, partner supports complex changes | Staging environment operation, PostgreSQL migration testing, Helm-based rollouts, and reading release notes in detail |
| Ongoing configuration changes | In-house, under change control | Identity administration, API scripting for repeatable changes, and review of audit logs after each change |
What usually goes wrong in Zitadel customization projects
Most Zitadel customization problems come from changes that live outside version control, from custom code that is not tested against every organization, and from settings that are copied rather than managed. The cards below cover the failure points we see most often, each paired with a prevention step tied to how Zitadel stores and applies configuration.
Changes made directly in the running instance
Teams often adjust login branding, organization settings or Action definitions through the Console on a live instance and never record them. The next deployment, restore or rebuild from scratch then loses those changes, and the login experience changes without a clear cause. Before go-live, confirm which settings are declared in code or Terraform and which are still manual, and keep a documented export of each.
Forks of Console or hosted login
Forking the Console or the hosted login UI to change layout or behavior creates a copy that must be merged with every upgrade. Since Zitadel v3.0, the core, Console and hosted login are licensed under AGPL 3.0, so a fork that is distributed or offered to users over a network raises license obligations that legal review should settle first. Prefer configuration-based branding and Actions, and confirm the license position with counsel before any fork.
Action logic without tests
Actions run custom code during sign-in and token flows, so a faulty condition can block authentication for one customer organization while others work normally. Teams often test against a single demo organization and miss organization-specific claims or roles. Build a test matrix that covers each organization type, run it in a non-production instance, and define a rollback step before each Action change.
Per-organization settings copied by hand
Login policies, password and MFA rules, and branding for customer organizations are frequently duplicated by hand when a new customer is onboarded. Over time the copies drift apart, and a policy change applied to one organization does not reach the others. Keep a single reference definition for shared settings, apply it through automation, and review each organization against that reference on a schedule.
Branding that misses some login flows
Branding is often set for the main sign-in page only, leaving registration, password reset, MFA prompts, device authorization pages and emails in default styling or the wrong language. Customer users then see mixed experiences that undermine trust. Walk through every flow and every language you support with a test account, and include email templates and notifications in the review.
Secrets for external calls stored in code
Actions that call external APIs, or identity providers that need client secrets, sometimes have credentials embedded in scripts or committed to a repository. Anyone with repository access can then read them, and rotating them requires a code change. Store these values in a secrets manager or the platform's secret handling, reference them by name in code, and confirm rotation steps with your security team.
How Zitadel customization differs by edition and deployment
Kubernetes with the official Helm chart is the deployment model Zitadel recommends for high availability, so most customization work for larger organizations lands here. Changes are usually expressed as chart values, mounted configuration and container images, which means they can be versioned, reviewed and promoted like any other infrastructure change.
- Build pipelines: Branding assets, login configuration and any custom code are packaged into images or values files that the pipeline builds and pins by version.
- Testing environments: Teams commonly run a separate cluster or namespace with the same chart version and a restored copy of the PostgreSQL database before any change reaches production.
- Vendor documentation and artifacts: Helm chart releases, container images and the self-hosting documentation are the primary sources, so the team should record the chart and image versions it tests against.
- Who applies changes: The platform team usually applies chart and values changes, while security or identity owners approve login and policy changes before the rollout.
Confirm with your internal team which settings are exposed through chart values and which require changes in the running instance, because that split decides what goes into version control. Ask your implementation partner to document each customization against the chart version it was tested on.
Docker Compose and binary installs suit single-node evaluations, smaller internal deployments and teams that have not yet adopted Kubernetes. The customization surface is largely the same as on Kubernetes, but the pipeline is simpler and the operational responsibility for the host and its services sits closer to the team making the change.
- Build pipelines: Changes are often applied by editing environment variables, configuration files and image tags on the host, so the pipeline may be a script or a small set of Compose files under version control.
- Testing environments: A second Compose stack or virtual machine with a copy of the database is the usual test target, and it should use the same image tag as production.
- Vendor documentation and artifacts: The team works from the self-hosting guides for Compose and binaries, and it should check the release notes for each image tag it plans to adopt.
- Who applies changes: Administrators with host access apply most changes, so access control on the hosts and the Compose files is part of the customization decision.
Confirm with Zitadel which deployment model it expects for your expected user volume and availability target, since its recommendation for high availability points to Kubernetes. Ask your partner to state which steps are manual, because manual steps are where drift between environments usually starts.
On Zitadel Cloud, Zitadel operates the platform, so the customer does not build or host the server. Customization is limited to what the hosted service exposes through its Console, APIs and Actions, and the upgrade path is managed by the vendor. The edition you buy determines the support and account management you receive, which affects how much of the work you can hand over.
- Build pipelines: Pipelines focus on configuration as code through the APIs and Terraform configurations, plus any application code that calls Zitadel.
- Testing environments: Teams usually create a separate Zitadel Cloud instance or project for testing, since the platform itself is not available for a local copy.
- Vendor documentation and artifacts: The team relies on the APIs documentation, SDKs and Terraform examples, which are Apache 2.0 licensed, and on vendor release communications for platform changes.
- Who applies changes: Customer administrators apply configuration changes, and Zitadel handles platform upgrades and infrastructure operations.
The Pro plan lists 25,000 daily active users at US$100 per month, and the Enterprise plan is priced on request for self-hosted or cloud deployments. Confirm with Zitadel what each plan includes for support and technical account management, and check the Zitadel pricing page for current terms before you plan your customization scope.
In an air-gapped or restricted network, the customization pipeline depends on what you can bring inside the boundary. Container images, Helm charts, documentation and dependency packages must be transferred, verified and stored internally before any build can run. Login features that call external identity providers or external services also need a plan for what remains reachable.
- Build pipelines: Pipelines pull from an internal registry and chart repository that you mirror, so each artifact needs a recorded source, version and checksum.
- Testing environments: Test environments must sit inside the same restricted boundary, which usually means duplicating the PostgreSQL and identity provider dependencies you need for testing.
- Vendor documentation and artifacts: Offline copies of the documentation and release notes must be kept with the version they describe, because online references may be unavailable during an incident.
- Who applies changes: Changes move through an approved transfer process, so the security team and the operations team usually both sign off before a change reaches production.
The core, Console and hosted login are licensed under AGPL 3.0 from v3.0, and that license has source-availability obligations for modified versions that users interact with over a network. Confirm with your legal or compliance team how those obligations apply to your customizations before you build them, and confirm with Zitadel which external services a restricted deployment still needs.
What you need to provide before Zitadel customization starts
The fastest way to lose time on a Zitadel customization project is to start building before the inputs are in place. Before any login branding, per-organization setting or Action is written, the client should have a non-production Zitadel instance running on a version the team has chosen and tested against. Production should not be the first place a branding change or Action runs, and the non-production instance should be close enough to production in configuration that results carry over. Confirm which Zitadel v4 release the team will standardize on, since the upgrade path in the sibling upgrades section depends on that choice.
Second, the implementation team needs read and write access to configuration, ideally through the Zitadel API or a deployment pipeline rather than manual edits in the Console. Customization changes such as branding settings, organization-level policies and Action definitions are easier to review, repeat and roll back when they live in version-controlled scripts or Terraform configurations. Ask who holds the administrative credentials, how they are issued and whether service accounts can be created for the work. Also provide a source repository where the code, configuration and documentation will live, with an agreed branching and review process.
Third, the client should supply a list of customer organizations inside the Zitadel instance, along with each one's branding and settings requirements. For every organization, record the logo, colors, display name, the sign-in and registration options it needs, and any policy differences such as password rules or multi-factor requirements. Provide brand assets in the formats the login pages will use and approved copy for every message the user sees, including error and reset screens. Decide which logins and which languages are in scope now. Translation work and copy review grow with each language and each login variant, so an unfinished list at this stage tends to resurface as rework later.
Fourth, name the owners. Customization needs a business approver who can sign off on branding and copy, and an identity team lead who can approve changes to authentication behavior, Actions and security-relevant settings. Name a technical contact for the platform team who can grant access and answer questions about the environment. Missing owners and approvals are a common cause of delay: work stalls while a draft waits for someone who was never assigned to review it, and feedback arrives late and contradicts earlier decisions. Agree in writing who approves what, how long a review is expected to take, and who breaks ties.
Finally, list any external systems that Actions must call, such as a customer data service, a CRM, a fraud or risk service or an entitlement store, and supply test credentials and sandbox endpoints for each one. Confirm which Zitadel Action triggers each system depends on and whether the calls must succeed for sign-in to continue. Ask the external system owners for their own approvals, since a change to an Action can alter what those systems receive. Gather these items before the statement of work is finalized, because they determine how much of the effort depends on parties outside the implementation team.
Zitadel customization questions buyers ask before hiring help
How much does Zitadel customization cost and what drives the price?
Cost follows the written scope, and DeployOpen does not publish a price list, so the quote is built from the deliverables you agree before work starts. The main components are analysis of the login flows and branding you need, build work on the hosted login and Console, Actions and API automation, testing in your environment, and documentation with handover. Costs rise with the number of customer organizations that need distinct settings, the number of Actions and external systems they call, and how much of the login UI you change. Build work is one-time, while support or upgrade retainers recur. Ask for a quote that lists each component, the environments covered, and what is excluded.
How long does a Zitadel customization project take to finish?
The timeline is set by scope and by how quickly your team approves designs, supplies test identities and opens change windows. Branding changes generally move faster than custom Actions that call internal systems, because those need API contracts, error handling and a security review. Per-organization settings add testing time for each tenant you configure. Most engagements are fixed-scope, so the timeline is written into the agreement alongside the deliverables. Ask for a schedule that shows the dependencies on your side, such as approvals, access to a non-production instance and production change windows, so you can see where delays would come from.
Can our own engineers customize Zitadel without outside help?
Yes, many teams can customize Zitadel with their own engineers, particularly for branding and simple API automation, if they are comfortable with OpenID Connect, the Zitadel APIs and their deployment pipeline. Work that tends to need experienced help includes custom login flows that change security-relevant behavior, Actions that handle identity data, and changes to the hosted login that must survive upgrades. Check whether your team has capacity to test each new release and whether they can maintain the code after the project ends. A short scoping session can show which parts fit your team's skills and which parts justify outside help.
What does our team need to provide for Zitadel customization work?
You provide access, decisions and people, not only systems. Expect to supply a non-production Zitadel instance and the environment it runs in, brand assets and approved wording, a list of customer organizations and the settings each one needs, and the external systems Actions will call along with test credentials. You also need named approvers for security-relevant behavior, a test group of users, and a production change window. Someone on your side should own the outcome and make decisions within agreed time frames. Ask the scope to list each dependency on your side and the date it is needed.
Do Zitadel customizations survive upgrades to new releases?
Customizations survive upgrades more reliably when they use supported extension points, live in version control and are tested against each new release. Changes to the hosted login and Console code need more attention because they sit closer to internal components. Read the release notes for each version before you upgrade, including any changes to the v4 line you run. Plan a staging upgrade that applies database migrations, then test login flows, Actions and per-organization settings before you roll out to production. Confirm with Zitadel which customization points it treats as stable for your version.
Does forking the Zitadel login UI trigger AGPL obligations?
Forking the login UI can bring AGPL obligations into play, but whether it does depends on your license analysis, how you distribute the software and how users interact with the modified version. Take this question to your counsel. Zitadel moved its core, Console and hosted login to the GNU Affero General Public License 3.0 with v3.0 on 31 March 2025, while its APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache 2.0. The AGPL includes obligations for users who interact with a modified version over a network, so your counsel should review your deployment model. Keep a record of every change and where it runs.
What do we receive at handover from a Zitadel customization project?
A handover should give you the customization code in your own repository, configuration for the instance and organizations, and the source for Actions with each external call documented. You should also receive deployment and rollback steps, a test plan with the cases run and their results, an upgrade runbook and administrator documentation for your team. Ask for a written list of artifacts so you can check each item at acceptance. Confirm whether knowledge transfer sessions are included. Ongoing support, upgrades and continuous testing are available as retainers, so ask separately what happens after go-live.
Which Zitadel customization risks should we check before work starts?
The most common risks sit in login flows, secrets handling, Actions failure behavior and drift between customer organizations. Check how a customized login behaves when an external system is slow or unavailable, and where Actions store or log credentials and personal data. Confirm that per-organization settings are defined in code so they do not diverge silently over time. Also check that your identity administrators can still reach the Console when a customization fails. Put these checks into the scope and the test plan so they are verified before production, not discovered afterward.
How DeployOpen scopes, delivers and hands over Zitadel customization
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, so Zitadel customization is scoped in writing before any work starts. We keep login branding, per-organization settings and Actions close to Zitadel's documented extension points so that later upgrades remain manageable.
How we scope
- Inventory the instances, organizations and projects that the customization must cover before any design work begins.
- List each login branding element, per-organization setting and Action, with the trigger and expected result for each.
- Record which API-driven automation runs against Zitadel, the credentials it uses and where those credentials are stored.
- Agree the scope, deliverables and timeline in writing, since most engagements are fixed-scope.
How we build
- Apply login branding through the hosted login configuration, keeping any custom assets in version-controlled files.
- Write Actions for custom logic in small, reviewed units, with each one tested against the event it responds to.
- Build API automation against the documented Zitadel APIs rather than against internal database tables.
- Test each customization in a non-production instance that matches your production PostgreSQL and deployment method.
How we hand over
- Document every customization, including its configuration location, owner, dependencies and the upgrade checks it needs.
- Provide a runbook for changing branding, organization settings and Actions without redeploying the whole platform.
- Walk your engineers through the code, configuration and test suite so that your team can maintain the work after handover.
- Confirm which artifacts live in your repositories and which credentials and access rights your team controls.
How we support
- Retest customizations when you move to a new Zitadel release, including the v4 line, before the upgrade reaches production.
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial engagement.
- Review Action logs and API automation failures with your team when a customization behaves unexpectedly after go-live.
- Ask for the support and retainer terms in writing, including response expectations, before you commit to either model.
