Keycloak vs Zitadel licensing: which license terms decide the choice
Keycloak is licensed under Apache-2.0. Zitadel moved its core, Console and hosted login from Apache 2.0 to AGPL-3.0 with Zitadel v3 on March 31, 2025, while its APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stay under Apache 2.0. For a platform team or CISO running a license review, the license decides the outcome mainly in three cases: you modify the server, you embed it in a product, or you offer it to outside customers. If you only run unmodified upstream releases for your own workforce, both licenses usually impose little beyond keeping notices intact. The current releases are Keycloak 26.8.1 (October 13, 2026) and Zitadel v4.19.5 (October 15, 2026), so confirm the version you intend to deploy against the Zitadel LICENSING.md text before the review closes.
The main difference is the network clause in AGPL-3.0. If you modify the Zitadel core and let users interact with that modified server over a network, you generally must make the corresponding source of your changes available to those users. Keycloak's Apache-2.0 terms do not impose that source-sharing duty, so internal patches or custom providers can stay private. Your review should inventory every change to the server, separate changes to the core from changes in the Apache-2.0 parts such as Terraform or Helm, and record who receives access to the running service. A reader should expect counsel to confirm how these duties apply to a specific deployment, since the answer depends on the exact modifications and the network exposure. The Keycloak LICENSE file is the reference for the Apache-2.0 side of that comparison.
A commercial Zitadel license is offered, but its scope, term and price are not stated in the sources used here, so confirm them in writing with Zitadel before you rely on that route. Ask whether the license removes the AGPL source-sharing duty for your use, whether it covers embedding in a product or offering the service to your customers, which Zitadel versions and support terms it includes, and how it renews. Pricing information is on the Zitadel pricing page, but the quote should follow your written scope of use. Keycloak carries no equivalent vendor license decision for the upstream project, though Red Hat's supported distribution is a separate commercial product to evaluate on its own terms. Document the decision, because switching identity platforms later is costly.
How the two licenses split across each part of the product
This table maps each part of Keycloak and Zitadel to its license so you can see which code you can modify, embed or redistribute under each project's terms. Read the Zitadel rows as the starting point for a license review, not a legal opinion, and confirm the commercial terms directly with Zitadel.
| Product part | Keycloak | Zitadel |
|---|---|---|
| Server core | Apache-2.0 for the whole project, per the LICENSE file | AGPL-3.0-only since Zitadel v3 (March 31, 2025) |
| Admin console and hosted login | Apache-2.0 with the rest of the project | AGPL-3.0-only, same as the core |
| Client SDKs and APIs | Apache-2.0 with the rest of the project | Apache-2.0, per the Zitadel blog |
| Proto definitions, examples and documentation | Apache-2.0 with the rest of the project | Apache-2.0 for proto files, examples and documentation |
| Helm charts and Terraform configurations | Helm chart and operator packaging follow the project's Apache-2.0 terms | Apache-2.0, per the Zitadel blog |
| Governance and maintainer | Open source project under the Cloud Native Computing Foundation (incubating), with Red Hat offering a supported distribution | Single company maintainer, Zitadel, which also offers the commercial license |
| Commercial option | No commercial license for upstream Keycloak. Red Hat build of Keycloak is a separate supported subscription product | Commercial license offered by Zitadel; confirm scope, price and restrictions in writing |
What AGPL-3.0 asks of you when you modify or embed Zitadel
The core question is whether you change Zitadel's server code. Since Zitadel v3.0 (31 March 2025), its core, Console and hosted login are under the GNU Affero General Public License 3.0. If your team modifies those components and makes the modified version available to users, the AGPL asks you to offer those users the corresponding source of your changes. The affero clause is what matters here: it extends that source offer to people who reach a modified server over a network, even if they never receive a copy of the software. Keycloak is licensed under Apache-2.0, which is permissive and does not attach a comparable source-offer condition to modified network services. A team that patches Keycloak for internal use can generally keep those patches private, but that is a question for counsel to confirm against the exact license text and the team's own distribution model.
Whether an obligation actually triggers depends on how the software is distributed and accessed, not on the label alone. Running an unmodified Zitadel instance for your own workforce, with no changes to the AGPL-covered components, raises different questions from running a patched build that your customers log into through a hosted login page. Embedding Zitadel code into your own product, or shipping a combined binary, also changes the analysis. Ask counsel to map three things for each deployment: which Zitadel directories you touch, whether your changes reach users over a network, and whether any code is linked into your own distributed software. Zitadel's LICENSING.md explains which directories carry other licenses and is the natural starting point for that map.
Calling Zitadel from a separate application is a different question from modifying the server. Zitadel's APIs, SDKs, proto definitions, examples, Helm charts and Terraform configurations stay under Apache 2.0, so an application that uses a Zitadel client library or calls its APIs over HTTP does not, on that basis alone, inherit the server's AGPL conditions. Confirm that your integration code uses only those Apache-2.0 directories and that you have not copied AGPL-covered server code into your application. If the answer is unclear, a commercial license from Zitadel is one option to discuss with its vendor, and the Zitadel blog post on the move from Apache to AGPL sets out the company's stated reasoning.
What changes the licensing result in practice
Neither license blocks a self-hosted deployment on its own. The result depends on what your team does with the server code, who touches the running service, and what your procurement and policy rules allow. Each card below names one factor and the function that should settle it.
Whether you change server code
Keycloak under Apache-2.0 lets you modify the server and keep changes private, with no duty to publish them. Zitadel's core, Console and hosted login moved to AGPL-3.0 with v3, so modified versions of those parts carry source-offer obligations if you distribute them or make them available over a network. Platform engineering should list every planned patch, theme or custom login page, then ask legal which of them touch AGPL-covered components. Ask legal to confirm the obligation for each change, since the AGPL terms apply to the exact code you run.
Whether you embed or distribute the server
Shipping the identity server inside a product, appliance or image sold to customers is distribution. Under AGPL-3.0, that triggers source obligations for the Zitadel core you ship, while Apache-2.0 Keycloak only asks you to keep notices and license terms. Product and legal teams should decide whether the identity service is delivered as a component of a product or only run as internal infrastructure, since that boundary often changes the answer more than the code changes do.
Whether customers reach the running service
The AGPL-3.0 network clause matters when users interact with a modified Zitadel over a network, even without receiving a copy of the software. For a B2B product where customers sign in through a hosted login you operate, legal should review whether that exposure applies to the modified components. Internal workforce SSO used only by employees usually presents a smaller question. Confirm with counsel how your deployment model maps to the network interaction terms in the license.
Whether client artifacts stay Apache-2.0
Zitadel states that APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache-2.0. Teams that only consume these artifacts, such as a client SDK in an application or Terraform to manage configuration, may not be bound by the server license at all. Platform engineering should map each repository and package in use to its license and record the mapping, because a single bundled server component can bring the AGPL terms back into scope.
Whether internal policy forbids copyleft
Many enterprises set rules that prohibit or restrict copyleft components in production, regardless of how the code is used. Under such a policy, Apache-2.0 Keycloak fits without an exception, while AGPL-3.0 Zitadel needs a documented approval. Security and legal should check the open source policy before any technical evaluation, because a policy exception can take longer to obtain than the deployment itself. Ask the license owner whether the rule covers only distributed code or any code run internally.
Whether procurement requires a commercial license
Zitadel offers a commercial license alongside AGPL-3.0, so a procurement rule that requires a signed vendor agreement for every production dependency can point toward it. Keycloak's Apache-2.0 terms do not require a contract to use, but enterprises that want a vendor support agreement can buy one from Red Hat's distribution of Keycloak. Procurement should request the written commercial license terms from Zitadel and compare the support scope, not only the license text. Ask both vendors what their terms cover in writing before comparing prices.
When each license fits a team's situation
This is the simplest case. Your team deploys the server for employees, connects it to internal applications, and runs the released build without changes. (Illustrative: a bank's staff sign in to a handful of internal tools through one identity server.) Under the AGPL-3.0-only terms Zitadel adopted with v3, the heaviest obligations attach mainly when you modify the server, so an unmodified internal deployment usually raises less licensing work. Keycloak is Apache-2.0 for the whole project, so the same deployment raises no copyleft question at all.
- Unmodified binaries and containers: Running the published server without patches keeps the modification question closed. Record the exact version and image digest in your change log so the position stays verifiable.
- Configuration is not code changes: Realm, client and identity provider settings are usually configuration. Confirm with counsel that your policy treats them the same way, because the answer depends on how your organization defines a modification.
- Future patching: A security fix may require a local patch before upstream ships one. Decide in advance who approves a fork and whether patches go back upstream.
- Internal-only exposure: Obligations tied to network users depend on whether anyone outside your organization interacts with a modified server. Confirm the user population with counsel.
Check the current licensing text in LICENSING.md for every directory you plan to use, and write your position down before rollout.
A product team may bundle an identity server inside its own software, ship it to customers, or link custom code into it. The question here is what you distribute and what you modify. (Illustrative: a vendor packages a login service inside its appliance.) Zitadel's licensing terms separate the server from APIs, SDKs, proto definitions and examples, which stay Apache-2.0, so the license of the component you embed decides your duties.
- Distributing a modified server: Shipping a changed Zitadel core typically brings AGPL source obligations to the people who receive it. Ask Zitadel how it reads distribution inside a larger product.
- Client-side embedding: Calling Zitadel APIs or using its SDKs from your application falls under the Apache-2.0 directories. Confirm the file list, because the directory boundary decides which terms apply.
- Bundled extensions: Plugins, custom identity providers or scripts linked into the server add their own license questions. Map every component before the build is frozen.
- Keycloak comparison: Keycloak's server and project code are Apache-2.0, so distributing a modified build adds no copyleft source obligation. You still need to honor notice requirements and review third-party dependencies.
Build a bill of materials that lists each component with its license, and have counsel review it before the first customer shipment.
A SaaS provider running Zitadel for customer organizations sits where the AGPL is written to apply most directly: users reach the software over a network. (Illustrative: a SaaS company hosts login for its enterprise customers on one shared Zitadel instance.) Zitadel offers a commercial license alongside AGPL-3.0, so this scenario often becomes a commercial conversation as much as a legal one, and the answer depends on how far you change the hosted components.
- Network use: If you change the hosted login, console or core, the AGPL's network clause may require offering the source of your modified version to users who interact with it. Confirm the exact trigger with counsel.
- Commercial license terms: Ask Zitadel which versions the commercial license covers, what it changes about support and upgrades, and how it handles future releases. The public licensing text does not answer those questions.
- Customer-facing extensions: Custom actions, branding and integrations may or may not count as modifications. Document where your code sits relative to the server.
- Keycloak comparison: Keycloak's Apache-2.0 license carries no network-triggered source obligation, so this question does not arise for the server. Your hosted service still needs its own review of third-party components.
Put the licensing decision on the same agenda as data residency and tenancy design, and request the commercial terms in writing before you settle the architecture.
Some teams need only client code: an SDK, a generated API client, or a Helm chart to deploy a server they run elsewhere. Zitadel's blog states that APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stay under Apache 2.0, which covers much of what these teams touch. The server they connect to still carries its own license, so the two questions need separate answers.
- Client code is separate from the server: An Apache-2.0 SDK does not change the license of the AGPL server it talks to. Keep the two questions apart in your review.
- Helm and Terraform: Deployment artifacts under Apache-2.0 make infrastructure-as-code easier to adopt without changing the server license. Confirm the exact repository and version you pin.
- Generated code: Code generated from proto definitions carries the terms of the definitions as published. Check the header and repository notice on each generated file.
- Keycloak comparison: Keycloak's Apache-2.0 license covers the server and its project code, so the team tracks one license instead of two. Confirm the license of any third-party adapter you add.
Check the license of each directory you import against the current LICENSING.md, because the boundary between Apache-2.0 and AGPL-3.0 is drawn directory by directory.
How to confirm the license position in your own environment
This sequence produces a dated, written record of every Keycloak and Zitadel component you run, how your code and users touch them, and whether the AGPL-3.0 path or a commercial license applies. Legal and platform owners sign off on the record before any decision is made.
Inventory every Keycloak and Zitadel artifact
The platform owner lists each Keycloak and Zitadel component in use: the server binary or container image, the Zitadel Console, the hosted login pages, any SDKs, Helm charts and Terraform modules. For each item, record the source it came from, the exact version and whether it is in production, staging or a proof of concept. Keycloak is Apache-2.0 under the LICENSE file in its repository, while Zitadel's core, Console and hosted login are AGPL-3.0 and its APIs, SDKs, Helm charts and Terraform configurations stay Apache 2.0 according to Zitadel's LICENSING.md. The step is complete when every artifact has a row in the inventory and each row is tagged with its license from the vendor's own files.
Record local patches, forks and build changes
The engineering lead checks whether your team has changed any Zitadel or Keycloak code, including source patches, custom themes, rebuilt container images, or a fork of either repository. Each change is logged with the file, the reason and the person who approved it, and the base version it applies to. Modifications to the AGPL-3.0 components carry obligations that differ from Apache-2.0 use, so the record shows exactly which parts you have altered. The step is complete when the change log is empty or every entry is traced to a versioned, reviewable change.
Document how users and services reach the server
The platform owner maps the network path for each audience: employees, customers, partner systems, administrators and internal services that call the Zitadel or Keycloak APIs. Note whether users interact with the server directly, through a hosted login page you operate, or through an application that embeds login. This matters because the AGPL-3.0 network interaction terms apply to software offered to users over a network, so the access map is the evidence legal will ask for. The step is complete when each audience has a diagram or table entry showing the path and which component serves it.
Check whether code is linked into your products
Developers review the applications and services that use Zitadel or Keycloak and confirm whether any Zitadel code is compiled, bundled, imported or copied into your own products, as opposed to calling the server over its published protocols and APIs. Apache-2.0 client packages and SDKs sit under different terms from the AGPL-3.0 core, so each dependency is recorded with its declared license from the package metadata. Ask the vendor to confirm which packages you consume are covered by which license if the metadata is unclear. The step is complete when every dependency has a license entry and any AGPL-3.0 code found in a product build is flagged for legal review.
Refer AGPL-3.0 modification and hosting questions to legal
If the review shows that you modify the Zitadel server, offer it to third parties as a hosted service, or distribute it inside a product, the legal team reviews the AGPL-3.0 obligations against the change log and the access map from earlier steps. Counsel decides whether source must be offered, how notices are handled and whether the current setup is acceptable. Keycloak changes are reviewed under Apache-2.0 notice and attribution terms, which legal should confirm for the same artifacts. The step is complete when counsel returns a written opinion that names each component and the conclusion reached for it.
Request commercial license terms in writing
If legal finds that the AGPL-3.0 path does not fit your use, the procurement lead asks Zitadel in writing for its commercial license terms, using the offering described in LICENSING.md and the terms on its pricing page. The request states the exact artifacts, versions, deployment model and user base so that the quote follows from a defined scope. Ask what the commercial license covers, what it excludes, whether it applies to modified code and how it is renewed or ended. The step is complete when the written terms are on file and reviewed alongside the legal opinion.
Keep a dated record of reviewed versions
The compliance lead stores the inventory, change log, access map, dependency review, legal opinion and any commercial terms in one dated record, with the version of each component as it was when reviewed. For example, record Keycloak 26.8.1 and Zitadel v4.19.5, the versions current at the research date, together with the date of the review. Repeat the review whenever a version changes, a new artifact is added or a patch is made, and mark the earlier record as superseded. The step is complete when the record is signed off by the accountable owner and linked from your architecture documentation.
Questions buyers ask about Keycloak and Zitadel licensing
Does running unmodified Zitadel trigger AGPL-3.0 obligations?
Not automatically. Running Zitadel without changes is a different case from modifying it or offering a modified version to users over a network, and the AGPL-3.0 duties attach most directly to the modified case. Zitadel moved its core, Console and hosted login from Apache 2.0 to AGPL-3.0 with Zitadel v3.0 on 31 March 2025. APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stay under Apache 2.0, so your integration code and infrastructure-as-code can keep those terms. Have counsel confirm how the network interaction clause applies to your setup, and check the project's LICENSING.md before you decide.
What does a commercial Zitadel license cover, and should we request one?
Zitadel's licensing documentation says a commercial license is offered alongside AGPL-3.0, but the material available to this review does not set out its scope, price, term or support terms, so do not assume any of them. Request one when your plan involves changing the Zitadel core, embedding it in a product you distribute, or offering a modified service to customers, and your counsel is not comfortable with AGPL-3.0 obligations for that use. Ask Zitadel in writing which software it covers, which uses are permitted, which modifications it covers, what it says about indemnity, support and renewal, and what it costs. Compare the answers with the pricing page and confirm all terms directly with Zitadel.
Does Keycloak's Apache-2.0 license remove the need for a license review?
No. The Apache-2.0 license reduces the copyleft question, but it does not end the review. Keycloak's LICENSE file states Apache-2.0, and that license has no network copyleft clause requiring you to publish the source of a modified server you run. It still carries conditions, such as keeping copyright and license notices and passing them on when you distribute the software. Your review should also cover the extensions, themes and providers you build, third-party libraries, and any vendor distribution you choose, such as the Red Hat build of Keycloak, which carries its own terms. Confirm each item in writing with counsel.
How much does a license review cost, and who pays for it?
No public figure applies to this work, and the cost depends on who does each part. Internal counsel's time is often the lowest out-of-pocket cost if your legal team already reviews open-source licenses. Outside counsel bills for interpretation and any written opinion. An implementation partner such as DeployOpen can produce the technical evidence, meaning the versions in use, the modifications, the deployment model and the distribution model, under a fixed scope agreed in writing. Interpreting the license terms remains a legal task. Most of the spend is one-time for the first review, then recurs when you upgrade across releases or change how you distribute the software. Ask each party for its scope, deliverables and rate basis before you compare quotes.
What must we give a partner to get a scoped quote for this review?
A quote follows from a written scope, so gather these items before you ask:
- The Keycloak and Zitadel versions you run now and plan to run, including any patches you apply.
- A list of modifications, forks and custom code, with the repository or location of each.
- Whether you operate the server internally or embed it in a product you ship or host for customers.
- The deployment model, such as binaries, Docker Compose or Kubernetes with the official Helm chart.
- Which Zitadel APIs, SDKs and configuration files your integrations use.
- The decision you need to make, the date it is needed, and who signs off.
DeployOpen agrees scope, deliverables and timelines in writing before work starts, so a complete list reduces later scope changes and keeps the quote specific.
Can our platform team run this license review without outside help?
Yes for the technical inventory, and often no for the legal decision. Platform engineers can record exact versions, compare deployed builds with upstream source, and sort code into the Apache-2.0 parts and the AGPL-3.0 core. Counsel should own the interpretation, especially if you plan to embed Zitadel in a commercial product, offer it as a hosted service, or negotiate a commercial license. Outside help makes the most sense when the inventory turns up changes nobody can explain, when the product roadmap shifts toward distribution, or when no one on the team has reviewed open-source licenses before. Record each decision with its date and the version it covers, so the next upgrade starts from a documented baseline.
How do we tell which Zitadel code we run and whether we changed it?
Pin the exact release you deploy, then compare your build with the upstream source for that tag. Take the version from the Zitadel releases page, record the image or binary checksum, and generate a diff against the tagged source. Each difference becomes a line item for counsel to classify. Keep configuration separate from code, and ask counsel whether settings applied through environment variables or Helm values count as modifications. Repeat the comparison on every upgrade, because each release changes the baseline. Store your Apache-2.0 integration code in separate repositories so reviewers can see where the boundary sits.
How DeployOpen works on this
DeployOpen helps platform, security and compliance teams work out what the Keycloak and Zitadel licenses mean for their own use, then plans and implements the chosen identity platform inside their own infrastructure. Our work covers scoping, build, handover and ongoing support, and each step is agreed in writing before it starts.
How we scope
- We confirm how you plan to modify, embed or redistribute the identity server before comparing license obligations.
- The written scope lists which Keycloak or Zitadel components, APIs, client packages and Helm charts are in use.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We deploy the chosen platform in your cloud account, data center or air-gapped network, against your database choice.
- We configure identity brokering, federation, and multi-tenant organization or realm models to match your product or workforce needs.
- We test authentication flows, upgrade paths and backup and restore procedures before anything goes live.
How we hand over
- We document the license position, the components you rely on and any obligations you must review with counsel.
- We deliver configuration, runbooks and evidence for your compliance assessors, who issue any audit reports themselves.
- Your operators are trained on upgrades, backups and administration so the platform remains usable after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the platform is in production.
- We track release changes for the platform you run and plan upgrades against your written scope.
- If your license position changes, we revisit the scope and documentation with you before any further work.
