mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-29 10:32:15 +00:00
docs: update roadmap and remove release cycle page (#12373)
Removes the release cycle page and sidebar entry. Replaces the roadmap page with updated strategic roadmap content and renames its sidebar label to Roadmap. --------- Co-authored-by: Elina Sokolovska <[email protected]> Co-authored-by: Claude Sonnet 4.6 <[email protected]> Co-authored-by: Fabienne Bühler <[email protected]>
This commit is contained in:
elinashoko
co-authored by
Elina Sokolovska
Claude Sonnet 4.6
Fabienne Bühler
Elina Sokolovska
Claude Sonnet 4.6
Fabienne Bühler
parent
5dcce9abdb
commit
6b629c2290
@@ -1,62 +0,0 @@
|
||||
---
|
||||
title: Release Cycle
|
||||
description: "Overview of ZITADEL's release cycle, featuring predictable major versions every quarter and frequent stable updates."
|
||||
sidebar_label: Release Cycle
|
||||
---
|
||||
|
||||
We release a new major version of our software every three months. This predictable schedule allows us to introduce significant features and enhancements in a structured way.
|
||||
|
||||
This cadence provides enough time for thorough development and rigorous testing. Before each stable release, we engage with our community and customers to test and stabilize the new version. This ensures high quality and reliability. For our customers, this approach creates a clear and manageable upgrade path.
|
||||
|
||||
While major changes are reserved for these three-month releases, we address urgent needs by backporting smaller updates, such as critical bug and security fixes, to earlier versions. This allows us to provide essential updates without altering the predictable rhythm of our major release cycle.
|
||||
|
||||
|
||||
|
||||
## Preparation
|
||||
|
||||
The first quarter of our cycle is for Preparation and Planning, where we create the blueprint for the upcoming major release.
|
||||
During this time, we define the core architecture, map out the implementation strategy, and finalize the design for the new features.
|
||||
|
||||
## Implementation
|
||||
|
||||
The second month is the Implementation and Development Phase, where our engineers build the features defined in the planning stage.
|
||||
|
||||
During this period, we focus on writing the code for the new enhancements.
|
||||
We also integrate accepted contributions from our community and create the necessary documentation alongside the development work.
|
||||
This phase concludes when the new version is feature-complete and ready to enter the testing phase.
|
||||
|
||||
## Release Candidate (RC)
|
||||
|
||||
The first month of the third quarter is for the Release Candidate (RC) and Stabilization Phase.
|
||||
At the beginning of this month, we publish a Release Candidate version.
|
||||
This is a feature-complete version that we believe is ready for public release, made available to our customers and community for widespread testing.
|
||||
|
||||
This phase is critical for ensuring the quality of the final release. We have two main objectives:
|
||||
- **Community Feedback and Bug Fixing**: This is when we rely on your feedback. By testing the RC in your own environments, you help us find and fix bugs and other issues we may have missed. Your active participation is crucial for stabilizing the new version.
|
||||
- **Enhanced Internal Testing**: While the community provides feedback, our internal teams conduct enhanced quality assurance. This includes in-depth feature validation, rigorous testing of upgrade paths from previous versions, and comprehensive performance and benchmark testing.
|
||||
|
||||
The goal of this phase is to use both community feedback and internal testing to ensure the new release is robust, bug-free, and performs well, so our customers can upgrade with confidence.
|
||||
|
||||
## General Availability (GA) / Stable
|
||||
|
||||
Following the month-long Release Candidate and Stabilization phase, we publish the official General Availability (GA) / Stable Release.
|
||||
This is the final, production-ready version of our software that has been thoroughly tested by both our internal teams and the community.
|
||||
|
||||
This release is available to everyone, and we recommend that customers begin reviewing the official upgrade path for their production environments.
|
||||
The deployment of this new major version to our cloud services also happens at this time.
|
||||
|
||||
**Ongoing Maintenance: Minor and Patch Releases**
|
||||
Once a major version becomes stable, we provide ongoing support through back-porting. This means we carefully select and apply critical updates from our main development track to the stable release, ensuring it remains secure and reliable. These updates are delivered in two ways:
|
||||
|
||||
- Minor Releases: These include simple features and enhancements from the next release cycle that are safe to add, requiring no major refactoring or large database migrations.
|
||||
- Patch Releases: These are focused exclusively on high-priority bug and security fixes to address critical issues promptly.
|
||||
|
||||
This process ensures that you can benefit from the stability of a major release while still receiving important updates and fixes in a timely manner.
|
||||
|
||||
## Deprecated
|
||||
|
||||
Each major version is actively supported for a full release cycle after its launch. This means that approximately six months after its initial stable release, a version enters its deprecation period.
|
||||
|
||||
Once a version is deprecated, we strongly encourage all self-hosted customers to upgrade to a newer version as soon as possible to continue receiving the latest features, improvements, and bug fixes.
|
||||
|
||||
For our enterprise customers, we may offer extended support by providing critical security fixes for a deprecated version beyond the standard six-month lifecycle. This extended support is evaluated on a case-by-case basis to ensure a secure and manageable transition for large-scale deployments.
|
||||
@@ -1,775 +1,135 @@
|
||||
---
|
||||
title: Zitadel Release Versions and Roadmap
|
||||
description: "ZITADEL's roadmap including upcoming features, release timelines, and planned improvements."
|
||||
sidebar_label: Release Versions and Roadmap
|
||||
title: Zitadel Roadmap
|
||||
description: "The next generation of Zitadel — strategic platform investments, capabilities, and timelines."
|
||||
sidebar_label: Roadmap
|
||||
---
|
||||
|
||||
import NewFeature from './_new-feature.mdx';
|
||||
import BreakingChanges from './_breaking-changes.mdx';
|
||||
import Deprecated from './_deprecated.mdx';
|
||||
import BetaToGA from './_beta-ga.mdx';
|
||||
import SDKv3 from './_sdk_v3.mdx';
|
||||
|
||||
## Timeline and Overview
|
||||
|
||||
<table id="zitadel-versions">
|
||||
<thead>
|
||||
<tr id="zitadel-versions-year">
|
||||
<th scope="col"></th>
|
||||
<th scope="col" colSpan={12}>2025</th>
|
||||
<th scope="col" colSpan={12}>2026</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="col"></th>
|
||||
<th scope="col" colSpan={3}>Q1</th>
|
||||
<th scope="col" colSpan={3}>Q2</th>
|
||||
<th scope="col" colSpan={3}>Q3</th>
|
||||
<th scope="col" colSpan={3}>Q4</th>
|
||||
<th scope="col" colSpan={3}>Q1</th>
|
||||
<th scope="col" colSpan={3}>Q2</th>
|
||||
<th scope="col" colSpan={3}>Q3</th>
|
||||
<th scope="col" colSpan={3}>Q4</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="col"></th>
|
||||
<th scope="col">Jan</th>
|
||||
<th scope="col">Feb</th>
|
||||
<th scope="col">Mar</th>
|
||||
<th scope="col">Apr</th>
|
||||
<th scope="col">May</th>
|
||||
<th scope="col">Jun</th>
|
||||
<th scope="col">Jul</th>
|
||||
<th scope="col">Aug</th>
|
||||
<th scope="col">Sep</th>
|
||||
<th scope="col">Oct</th>
|
||||
<th scope="col">Nov</th>
|
||||
<th scope="col">Dec</th>
|
||||
<th scope="col">Jan</th>
|
||||
<th scope="col">Feb</th>
|
||||
<th scope="col">Mar</th>
|
||||
<th scope="col">Apr</th>
|
||||
<th scope="col">May</th>
|
||||
<th scope="col">Jun</th>
|
||||
<th scope="col">Jul</th>
|
||||
<th scope="col">Aug</th>
|
||||
<th scope="col">Sep</th>
|
||||
<th scope="col">Oct</th>
|
||||
<th scope="col">Nov</th>
|
||||
<th scope="col">Dec</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td colSpan={25}>Zitadel Versions</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">[v2.x](/product/roadmap#v2-x)</th>
|
||||
<td colSpan={6} className="release-stable">GA / Stable </td>
|
||||
<td colSpan={3} className="release-deprecated">Deprecated</td>
|
||||
<td colSpan={16}></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">[v3.x](/product/roadmap#v3-x)</th>
|
||||
<td colSpan={3} className="release-impl">Implementation</td>
|
||||
<td className="release-rc">RC</td>
|
||||
<td colSpan={5} className="release-stable">GA / Stable </td>
|
||||
<td colSpan={3} className="release-deprecated">Deprecated</td>
|
||||
<td colSpan={12}></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">[v4.x](/product/roadmap#v4-x)</th>
|
||||
<td colSpan={3}></td>
|
||||
<td colSpan={3} className="release-impl">Implementation</td>
|
||||
<td className="release-rc">RC</td>
|
||||
<td colSpan={5} className="release-stable">GA / Stable </td>
|
||||
<td colSpan={3} className="release-deprecated">Deprecated</td>
|
||||
<td colSpan={9}></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">[v5.x](/product/roadmap#v5-x)</th>
|
||||
<td colSpan={24}>TBC</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
For more detailed description about the different stages and the release cycle check out the following Page: [Release Cycle](/product/release-cycle)
|
||||
|
||||
<table id="zitadel-versions">
|
||||
<thead>
|
||||
<tr>
|
||||
<th scope="col">25-Q1</th>
|
||||
<th scope="col">25-Q2</th>
|
||||
<th scope="col">25-Q3</th>
|
||||
<th scope="col">25-Q4</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td colSpan={4}>Zitadel Core</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td scope="row">
|
||||
[v2.x](/product/roadmap#v2-x)
|
||||
</td>
|
||||
<td scope="row">
|
||||
[v3.x](/product/roadmap#v3-x)
|
||||
<ul>
|
||||
<li>
|
||||
Actions V2
|
||||
</li>
|
||||
<li>
|
||||
Removed CockroachDB Support
|
||||
</li>
|
||||
<li>
|
||||
License Change
|
||||
</li>
|
||||
<li>
|
||||
Login v2
|
||||
<ul>
|
||||
<li>
|
||||
Initial Release
|
||||
</li>
|
||||
<li>
|
||||
All standard authentication methods
|
||||
</li>
|
||||
<li>
|
||||
OIDC & SAML
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td scope="row">
|
||||
[v4.x](/product/roadmap#v4-x)
|
||||
<ul>
|
||||
<li>Resource API</li>
|
||||
<li>
|
||||
Login v2 as default
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
Device Authorization Flow
|
||||
</li>
|
||||
<li>
|
||||
LDAP IDP
|
||||
</li>
|
||||
<li>
|
||||
JWT IDP
|
||||
</li>
|
||||
<li>
|
||||
Custom Login UI Texts
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
<td scope="row">
|
||||
[v5.x](/product/roadmap#v5-x)
|
||||
<span>Release: TBC</span>
|
||||
<ul>
|
||||
<li>Analytics</li>
|
||||
<li>User Groups</li>
|
||||
<li>User Uniqueness on Instance Level</li>
|
||||
<li>Remove Required Fields from User</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colSpan={4}>Zitadel SDKs</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td scope="row">
|
||||
|
||||
</td>
|
||||
<td scope="row">
|
||||
|
||||
</td>
|
||||
<td scope="row">
|
||||
<ul>
|
||||
<li>
|
||||
[Initial Version of PHP SDK](/product/roadmap#v-3-x-php)
|
||||
</li>
|
||||
<li>
|
||||
[Initial Version of Java SDK](/product/roadmap#v-3-x-java)
|
||||
</li>
|
||||
<li>
|
||||
[Initial Version of Ruby SDK](/product/roadmap#v-3-x-ruby)
|
||||
</li>
|
||||
<li>
|
||||
[Initial Version of Python SDK](/product/roadmap#v-3-x-python)
|
||||
</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td scope="row">
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## Zitadel Core
|
||||
|
||||
Check out all [Zitadel Release Versions](https://github.com/zitadel/zitadel/releases)
|
||||
|
||||
### v2-x
|
||||
|
||||
**Current State**: General Availability / Stable
|
||||
|
||||
**Release**: [v2.x](https://github.com/zitadel/zitadel/releases?q=v2.&expanded=true)
|
||||
|
||||
In Zitadel versions 2.x and earlier, new releases were deployed with a minimum frequency of every two weeks.
|
||||
This practice resulted in a significant number of individual versions.
|
||||
To review the features and bug fixes for these releases, please consult the linked release information provided above.
|
||||
|
||||
### v3-x
|
||||
|
||||
ZITADEL v3 is here, bringing key changes designed to empower your identity management experience.
|
||||
This release transitions our licensing to AGPLv3, reinforcing our commitment to open and collaborative development.
|
||||
We've streamlined our database support by removing CockroachDB.
|
||||
Excitingly, v3 introduces the foundational elements for Actions V2, opening up a world of possibilities for tailoring and extending ZITADEL to perfectly fit your unique use cases.
|
||||
|
||||
**Current State**: General Availability / Stable
|
||||
|
||||
**Release**: [v3.x](https://github.com/zitadel/zitadel/releases?q=v3.&expanded=true)
|
||||
|
||||
**Blog**: [Zitadel v3: AGPL License, Streamlined Releases, and Platform Updates](https://zitadel.com/blog/zitadel-v3-announcement)
|
||||
|
||||
<details>
|
||||
<summary>New Features</summary>
|
||||
|
||||
<NewFeature components={props.components} />
|
||||
Identity has changed significantly since Zitadel was first built.
|
||||
|
||||
<details>
|
||||
<summary>Actions V2</summary>
|
||||
Over the last few years, we've worked with customers operating everything from modern SaaS applications to large enterprise platforms serving millions of users. As those customers have grown, we've seen the same platform take on increasingly complex identity challenges—from enterprise federation and global deployments to machine identities and AI agents.
|
||||
|
||||
Zitadel Actions V2 empowers you to customize Zitadel's workflows by executing your own logic at specific points. You define external Endpoints containing your code and configure Targets and Executions within Zitadel to trigger them based on various conditions and events.
|
||||
The next generation of Zitadel is built so our customers can continue solving tomorrow's identity challenges on the same platform they choose today. That requires a more flexible foundation—one that supports new identity models, web-scale deployments, and emerging identity patterns without accumulating complexity over time.
|
||||
|
||||
Why we built it: To provide greater flexibility and control, allowing you to implement custom business rules, automate tasks, enrich user data, control access, and integrate with other systems seamlessly. Actions V2 enables you to tailor Zitadel precisely to your unique needs.
|
||||
The roadmap below outlines the strategic platform investments we're making over the coming releases and the customer capabilities they unlock.
|
||||
|
||||
Read more in our [documentation](https://zitadel.com/docs/concepts/features/actions_v2)
|
||||
</details>
|
||||
*This roadmap reflects our current strategic direction rather than a fixed release plan. As we continue validating the next generation of Zitadel with customers and the community, priorities and sequencing may evolve.*
|
||||
|
||||
<details>
|
||||
<summary>License Change Apache 2.0 to AGPL3</summary>
|
||||
## **Strategic Roadmap**
|
||||
|
||||
Zitadel is switching to the AGPL 3.0 license to ensure the project's sustainability and encourage community contributions from commercial users, while keeping the core free and open source.
|
||||
The next generation of Zitadel will be delivered incrementally, with each investment building on the foundations established by the previous one. The roadmap below outlines the major platform capabilities we're investing in and our current target horizon for each.
|
||||
|
||||
Read more about our [decision](https://zitadel.com/blog/apache-to-agpl)
|
||||
</details>
|
||||
</details>
|
||||
| Strategic investment | Key capabilities | Timeline |
|
||||
| :---- | :---- | :---- |
|
||||
| Instant authentication | Working authentication in under a minute, local identity runtime, CLI-first developer workflow | [In preview](https://zitadel.com/blog/next-zitadel-preview) |
|
||||
| [Flexible Identity](#flexible-identity) | User Schemas, composable authentication, identity as code, instant application updates | H2 2026 |
|
||||
| [Enterprise Platform](#enterprise-platform) | One identity model, unified configuration, web-scale identity | H2 2026 |
|
||||
| [AI-Native Identity](#ai-native-identity) | First-class AI identities, delegated authority, AI identity lifecycle | H2 2026 |
|
||||
| [Identity Observability](#identity-observability) | End-to-end identity visibility and audit trail, identity intelligence | H1 2027 |
|
||||
| Production rollout | Migration tooling, production readiness, Cloud & self-hosted adoption | 2027 |
|
||||
|
||||
<details>
|
||||
<summary>Breaking Changes</summary>
|
||||
## **Flexible Identity**
|
||||
|
||||
<BreakingChanges components={props.components} />
|
||||
Every application models identity differently, and those requirements continue to evolve over time. As products grow, new user types emerge, registration flows become more sophisticated, and different applications require different identity models.
|
||||
|
||||
<details>
|
||||
<summary>CockroachDB Support removed</summary>
|
||||
The next generation of Zitadel introduces a more flexible foundation for modelling identity. User schemas become the source of truth for identity, while composable authentication components and identity-as-code make authentication feel like a natural part of your application development workflow.
|
||||
|
||||
After careful consideration, we have made the decision to discontinue support for CockroachDB in Zitadel v3 and beyond.
|
||||
While CockroachDB is an excellent distributed SQL database, supporting multiple database backends has increased our maintenance burden and complicated our testing matrix.
|
||||
Check out our [migration guide](https://zitadel.com/docs/self-hosting/manage/cli/mirror) to migrate from CockroachDB to PostgreSQL.
|
||||
### **Strategic Investments**
|
||||
|
||||
More details can be found [here](https://github.com/zitadel/zitadel/issues/9414)
|
||||
</details>
|
||||
* User Schemas
|
||||
* Identity-as-code
|
||||
* Composable authentication components
|
||||
* Live development preview
|
||||
* Versioned identity configuration
|
||||
|
||||
<details>
|
||||
<summary>Actions API v3 alpha removed</summary>
|
||||
### **Customer Outcomes**
|
||||
|
||||
With the current release we have published the Actions V2 API as a beta version, and got rid of the previously published alpha API.
|
||||
Check out the [new API](/reference/api/action)
|
||||
* Authentication adapts to your application.
|
||||
* Identity models evolve without disruptive migrations.
|
||||
* Identity becomes part of your normal development workflow.
|
||||
|
||||
</details>
|
||||
</details>
|
||||
## **Enterprise Platform**
|
||||
|
||||
### v4-x
|
||||
Enterprise identity becomes increasingly complex as products grow. Every new customer brings different identity providers, organisation-specific requirements, compliance needs, and operational expectations. Over time, those differences can turn into multiple configuration models, overlapping policies, and an increasing number of special cases.
|
||||
|
||||
**Current State**: General Availability / Stable
|
||||
The next generation of Zitadel simplifies that foundation. By moving towards a more unified platform model, we're making enterprise identity easier to operate while building the foundations required for web-scale deployments.
|
||||
|
||||
<details>
|
||||
<summary>New Features</summary>
|
||||
### **Strategic Investments**
|
||||
|
||||
<NewFeature components={props.components} />
|
||||
* Unified identity model
|
||||
* Unified configuration
|
||||
* Web-scale architecture
|
||||
* Regional deployment foundations
|
||||
|
||||
<details>
|
||||
<summary>Resource API (v2)</summary>
|
||||
### **Customer Outcomes**
|
||||
|
||||
We are revamping our APIs to improve the developer experience.
|
||||
Currently, our use-case-based APIs are complex and inconsistent, causing confusion and slowing down integration.
|
||||
To fix this, we're shifting to a resource-based approach.
|
||||
This means developers will use consistent endpoints (e.g., /users) to manage resources, regardless of their own role.
|
||||
This change, along with standardized naming and improved documentation, will simplify integration, accelerate development, and create a more intuitive experience for our customers and community.
|
||||
* Onboard enterprise customers without accumulating operational complexity.
|
||||
* Scale from your first enterprise customer to global deployments on the same platform.
|
||||
* Reduce configuration overhead while supporting increasingly complex identity requirements.
|
||||
|
||||
Resources integrated in this release:
|
||||
- Applications (in beta)
|
||||
- Authorizations (in beta)
|
||||
- Instances (in beta)
|
||||
- Organizations
|
||||
- Permissions (in beta)
|
||||
- Projects (in beta)
|
||||
- Settings (beta) now includes 3 new endpoints: `ListOrganizationSettings()`, `SetOrganizationSettings()` and `DeleteOrganizationSettings()`
|
||||
- Users
|
||||
## **AI-Native Identity**
|
||||
|
||||
For more details read the [Github Issue](https://github.com/zitadel/zitadel/issues/6305)
|
||||
</details>
|
||||
Identity is no longer limited to human users and traditional service accounts. AI agents are increasingly authenticating, accessing APIs, performing delegated actions, and interacting with enterprise systems on behalf of users.
|
||||
|
||||
<details>
|
||||
<summary>Login V2</summary>
|
||||
The next generation of Zitadel treats AI agents as first-class identities. Rather than adapting existing human identity models to new use cases, we're building identity, delegation, and lifecycle management around the way AI agents actually operate.
|
||||
|
||||
Our new login UI has been enhanced with additional features, bringing it to feature parity with Version 1.
|
||||
### **Strategic Investments**
|
||||
|
||||
<details>
|
||||
<summary>Device Authorization Flow</summary>
|
||||
* Agent identities
|
||||
* Delegated authority
|
||||
* Agent lifecycle management
|
||||
* Scoped permissions
|
||||
* Agent-to-agent interactions
|
||||
|
||||
The Device Authorization Grant is an OAuth 2.0 flow designed for devices that have limited input capabilities (like smart TVs, gaming consoles, or IoT devices) or lack a browser.
|
||||
### **Customer Outcomes**
|
||||
|
||||
Read our docs about how to integrate your application using the [Device Authorization Flow](https://zitadel.com/docs/guides/integrate/login/oidc/device-authorization)
|
||||
</details>
|
||||
* Govern AI agents with the same confidence as human identities.
|
||||
* Secure delegated actions without introducing new trust models.
|
||||
* Build AI-native applications on an identity platform designed for autonomous systems.
|
||||
|
||||
<details>
|
||||
<summary>LDAP IDP</summary>
|
||||
## **Identity Observability**
|
||||
|
||||
This feature enables users to log in using their existing LDAP (Lightweight Directory Access Protocol) credentials.
|
||||
It integrates your system with an LDAP directory, allowing it to act as an Identity Provider (IdP) solely for authentication purposes.
|
||||
This means users can securely access the service with their familiar LDAP username and password, streamlining the login process.
|
||||
</details>
|
||||
As organisations adopt more distributed identity models, understanding who did what—and under whose authority—becomes significantly more difficult. A single request may involve a human user, an AI agent, delegated authority, enterprise federation, and multiple systems before it reaches your application.
|
||||
|
||||
<details>
|
||||
<summary>JWT IDP</summary>
|
||||
The next generation of Zitadel brings that visibility closer to the identity layer itself. By connecting authentication, authorization, sessions, delegation, and identity activity, we're building a more complete view of identity across your systems.
|
||||
|
||||
This "JSON Web Token Identity Provider (JWT IdP)" feature allows you to use an existing JSON Web Token (JWT) from another system (like a Web Application Firewall managing a session) as a federated identity for authentication in new applications managed by ZITADEL.
|
||||
### **Strategic Investments**
|
||||
|
||||
Essentially, it enables session reuse by letting ZITADEL trust and validate a JWT issued by an external source. This allows users already authenticated in an existing system to seamlessly access new applications without re-logging in.
|
||||
* Identity observability
|
||||
* End-to-end identity context
|
||||
* Identity activity timeline
|
||||
* Delegation tracking
|
||||
* Identity intelligence
|
||||
|
||||
Read more in our docs about how to login users with [JWT IDP](https://zitadel.com/docs/guides/integrate/identity-providers/jwt_idp)
|
||||
</details>
|
||||
### **Customer Outcomes**
|
||||
|
||||
<details>
|
||||
<summary>Custom Login UI Texts</summary>
|
||||
|
||||
This feature provides customers with the flexibility to personalize the user experience by customizing various text elements across different screens of the login UI. Administrators can modify default messages, labels, and instructions to align with their branding, provide specific guidance, or cater to unique regional or organizational needs, ensuring a more tailored and intuitive authentication process for their users.
|
||||
</details>
|
||||
</details>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>General Availability</summary>
|
||||
|
||||
<BetaToGA components={props.components} />
|
||||
|
||||
<details>
|
||||
<summary>Hosted Login v2</summary>
|
||||
|
||||
We're officially moving our new Login UI v2 from beta to General Availability.
|
||||
Starting now, it will be the default login experience for all new customers.
|
||||
With this release, 8.0 we are also focused on implementing previously missing features, such as device authorization and LDAP IDP support, to make the new UI fully feature-complete.
|
||||
|
||||
- [Hosted Login V2](../guides/integrate/login/hosted-login#hosted-login-version-2)
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Actions v2</summary>
|
||||
|
||||
This API enables you to manage custom executions and targets—formerly known as actions—across your entire ZITADEL instance.
|
||||
With Actions V2, you gain significantly more flexibility to tailor ZITADEL’s behavior compared to previous versions.
|
||||
Actions are now available instance-wide, eliminating the need to configure them for each organization individually.
|
||||
ZITADEL no longer restricts the implementation language, tooling, or runtime for action executions.
|
||||
Instead, you define external endpoints that are called by ZITADEL and maintained by you.
|
||||
|
||||
- [Actions V2](/reference/api/action)
|
||||
</details>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Deprecated endpoints</summary>
|
||||
|
||||
<Deprecated components={props.components} />
|
||||
|
||||
<details>
|
||||
<summary>Organization Objects V1 > Users V1</summary>
|
||||
|
||||
- `AddMachineKey()`
|
||||
- `AddMachineUser()`
|
||||
- `AddPersonalAccessToken()`
|
||||
- `BulkRemoveUserMetadata()`
|
||||
- `BulkSetUserMetadata()`
|
||||
- `GenerateMachineSecret()`
|
||||
- `GetMachineKeyByIDs()`
|
||||
- `GetOrgByDomainGlobal()`
|
||||
- `GetPersonalAccessTokenByIDs()`
|
||||
- `GetUserMetadata()`
|
||||
- `ListAppKeys()`
|
||||
- `ListMachineKeys()`
|
||||
- `ListPersonalAccessTokens()`
|
||||
- `ListUserMetadata()`
|
||||
- `RemoveMachineKey()`
|
||||
- `RemoveMachineSecret()`
|
||||
- `RemovePersonalAccessToken()`
|
||||
- `RemoveUserMetadata()`
|
||||
- `SetUserMetadata()`
|
||||
- `UpdateHumanPhone()`
|
||||
- `UpdateMachine()`
|
||||
- `UpdateUserName()`
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Projects V1</summary>
|
||||
|
||||
- `AddProject()`
|
||||
- `AddProjectGrant()`
|
||||
- `AddProjectRole()`
|
||||
- `BulkAddProjectRoles()`
|
||||
- `DeactivateProject()`
|
||||
- `DeactivateProjectGrant()`
|
||||
- `GetGrantedProjectByID()`
|
||||
- `GetProjectByID()`
|
||||
- `GetProjectGrantByID()`
|
||||
- `ListAllProjectGrants()`
|
||||
- `ListGrantedProjectRoles()`
|
||||
- `ListGrantedProjects()`
|
||||
- `ListProjectGrants()`
|
||||
- `ListProjectRoles()`
|
||||
- `ListProjects()`
|
||||
- `ReactivateProject()`
|
||||
- `ReactivateProjectGrant()`
|
||||
- `RemoveProject()`
|
||||
- `RemoveProjectGrant()`
|
||||
- `RemoveProjectRole()`
|
||||
- `UpdateProject()`
|
||||
- `UpdateProjectGrant()`
|
||||
- `UpdateProjectRole()`
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Members V1</summary>
|
||||
|
||||
- `AddIAMMember()`
|
||||
- `AddOrgMember()`
|
||||
- `AddProjectGrantMember()`
|
||||
- `AddProjectMember()`
|
||||
- `ListIAMMembers()`
|
||||
- `ListOrgMembers()`
|
||||
- `ListProjectGrantMembers()`
|
||||
- `ListProjectMembers()`
|
||||
- `ListUserMemberships()`
|
||||
- `RemoveIAMMember()`
|
||||
- `RemoveOrgMember()`
|
||||
- `RemoveProjectGrantMember()`
|
||||
- `RemoveProjectMember()`
|
||||
- `UpdateIAMMember()`
|
||||
- `UpdateOrgMember()`
|
||||
- `UpdateProjectGrantMember()`
|
||||
- `UpdateProjectMember()`
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Instance Lifecycle V1 > System Service V1</summary>
|
||||
|
||||
- `AddInstanceTrustedDomain()`
|
||||
- `GetMyInstance()`
|
||||
- `ListInstanceDomains()`
|
||||
- `ListInstanceTrustedDomains()`
|
||||
- `RemoveInstanceTrustedDomain()`
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Instance Objects V1 > Organizations V1 </summary>
|
||||
|
||||
- `GetDefaultOrg()`
|
||||
- `GetOrgByID()`
|
||||
- `IsOrgUnique()`
|
||||
</details>
|
||||
</details>
|
||||
|
||||
### v5-x
|
||||
|
||||
**Current State**: Planning
|
||||
|
||||
**Release**: TBC
|
||||
|
||||
<details>
|
||||
<summary>New Features</summary>
|
||||
|
||||
<NewFeature components={props.components} />
|
||||
|
||||
<details>
|
||||
<summary>Analytics</summary>
|
||||
|
||||
We provide comprehensive and insightful analytics capabilities that empower you with the information needed to understand platform usage, monitor system health, and make data-driven decisions.
|
||||
|
||||
<details>
|
||||
<summary>Daily Active Users (DAU) & Monthly Active Users (MAU)</summary>
|
||||
|
||||
Administrators need to track user activity to understand platform usage and identify trends.
|
||||
This feature provides basic metrics for daily and monthly active users, allowing for filtering by date range and scope (instance-wide or within a specific organization).
|
||||
The metrics should ensure that each user is counted only once per day or month, respectively, regardless of how many actions they performed.
|
||||
This minimal feature serves as a foundation for future expansion into more detailed analytics.
|
||||
|
||||
For more details track our [github issue](https://github.com/zitadel/zitadel/issues/7506).
|
||||
</details>
|
||||
* Understand who performed an action, through which identity, and under whose authority.
|
||||
* Investigate identity-related incidents more quickly with complete identity context.
|
||||
* Improve governance, security, and operational visibility across human, machine, and AI identities.
|
||||
|
||||
<details>
|
||||
<summary>Resource Count Metrics</summary>
|
||||
## **Supporting Existing Customers**
|
||||
|
||||
To effectively manage a Zitadel instance, administrators need to understand resource utilization.
|
||||
This feature provides metrics for resource counts, including organizations, users (with filtering options), projects, applications, and authorizations.
|
||||
For users, we will offer filters to retrieve the total count, counts per organization, and counts by user type (human or machine).
|
||||
These metrics will provide administrators with valuable insights into the scale and complexity of their Zitadel instance.
|
||||
The next generation of Zitadel is designed as an evolution of the platform, not a replacement.
|
||||
|
||||
For more details track our [github issue](https://github.com/zitadel/zitadel/issues/9709).
|
||||
</details>
|
||||
While much of our engineering investment is focused on the next generation of Zitadel, we're committed to supporting existing customers throughout the transition.
|
||||
|
||||
<details>
|
||||
<summary>Operational Metrics</summary>
|
||||
Zitadel V4 will continue to be supported for at least 12 months, previous versions will be sunsetted in due course, and we will communicate the timelines shortly. During this period, we'll prioritise security updates, critical customer issues, and high-impact improvements while introducing the next generation incrementally. We'll share the end-of-support timelines for earlier major versions, together with migration guidance, in the coming months.
|
||||
|
||||
To empower customers to better manage and optimize their Zitadel instances, we will provide access to detailed operational metrics.
|
||||
This data will help customers identify potential issues, optimize performance, and ensure the stability of their deployments.
|
||||
The provided data will encompass basic system information, infrastructure details, settings, error reports, and the health status of various Zitadel components, accessible via a user interface or an API.
|
||||
Community contributions remain an important part of Zitadel. If you're maintaining a V4 deployment and would like to contribute fixes or improvements, we'll continue reviewing and working with contributors wherever those changes align with the long-term direction of the platform. Before starting a larger contribution, we encourage you to open a GitHub issue first. This helps us validate the approach, share any relevant roadmap context, and ensure the work aligns with the direction of the platform.
|
||||
|
||||
For more details track our [github issue](https://github.com/zitadel/zitadel/issues/9476).
|
||||
As new platform capabilities become available, we'll provide migration tooling and guidance so teams can adopt them incrementally rather than through a disruptive migration.
|
||||
|
||||
</details>
|
||||
</details>
|
||||
Our goal is to make adoption predictable and low risk, whether you're running Zitadel Cloud or self-hosting your own deployment.
|
||||
|
||||
<details>
|
||||
<summary>User Groups</summary>
|
||||
### **Strategic Investments**
|
||||
|
||||
Administrators will be able to define groups within an organization and assign users to these groups.
|
||||
More details about the feature can be found [here](https://github.com/zitadel/zitadel/issues/9702)
|
||||
</details>
|
||||
* Incremental migration
|
||||
* Compatibility guidance
|
||||
* Migration tooling
|
||||
* Cloud & self-hosted alignment
|
||||
* Long-term platform stability
|
||||
|
||||
<details>
|
||||
<summary>User Uniqueness on Organization Level</summary>
|
||||
### **Customer Outcomes**
|
||||
|
||||
Administrators will be able to define weather users should be unique across the instance or within an organization.
|
||||
This allows managing users independently and avoids conflicts due to shared user identifiers.
|
||||
Example: The user with the username [email protected] can be created in the Organization "Customer A" and "Customer B" if uniqueness is defined on the organization level.
|
||||
|
||||
Stay updated on the progress and details on our [GitHub Issue](https://github.com/zitadel/zitadel/issues/9535)
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Remove Required Fields</summary>
|
||||
|
||||
Currently, the user creation process requires several fields, such as email, first name, and last name, which can be restrictive in certain scenarios. This feature allows administrators to create users with only a username, making other fields optional.
|
||||
This provides flexibility for systems that don't require complete user profiles upon initial creation for example simplified onboarding flows.
|
||||
|
||||
For more details check out our [GitHub Issue](https://github.com/zitadel/zitadel/issues/4386)
|
||||
</details>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Feature Deprecation</summary>
|
||||
|
||||
<Deprecated components={props.components} />
|
||||
|
||||
<details>
|
||||
<summary>Actions V1</summary>
|
||||
</details>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Breaking Changes</summary>
|
||||
|
||||
<BreakingChanges components={props.components} />
|
||||
|
||||
<details>
|
||||
<summary>Hosted Login v1 will be removed</summary>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Zitadel APIs v1 will be removed</summary>
|
||||
</details>
|
||||
</details>
|
||||
|
||||
### v6-x
|
||||
|
||||
<details>
|
||||
<summary>New Features</summary>
|
||||
|
||||
<NewFeature components={props.components} />
|
||||
|
||||
<details>
|
||||
<summary>Basic Threat Detection Framework</summary>
|
||||
|
||||
This initial version of our Threat Detection Framework is designed to enhance the security of your account by identifying and challenging potentially anomalous user behavior.
|
||||
When the system detects unusual activity, it will present a challenge, such as a reCAPTCHA, to verify that the user is legitimate and not a bot or malicious actor.
|
||||
Security administrators will also have the ability to revoke user sessions based on the output of the threat detection model, providing a crucial tool to mitigate potential security risks in real-time.
|
||||
|
||||
We are beginning with a straightforward reCAPTCHA-style challenge to build and refine the core framework.
|
||||
This foundational step will allow us to gather insights into how the system performs and how it can be improved.
|
||||
Future iterations will build upon this groundwork to incorporate more sophisticated detection methods and a wider range of challenge and response mechanisms, ensuring an increasingly robust and intelligent security posture for all users.
|
||||
|
||||
More details can be found in the (GitHub Issue](https://github.com/zitadel/zitadel/issues/9707)
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>SCIM Outbound</summary>
|
||||
|
||||
Automate user provisioning to your external applications with our new SCIM Client.
|
||||
This feature ensures users are automatically created in downstream systems before their first SSO login, preventing access issues and streamlining onboarding.
|
||||
|
||||
It also synchronizes user lifecycle events, so changes like deactivations or deletions are instantly reflected across all connected applications for consistent and secure access management.
|
||||
The initial release will focus on provisioning the user resource.
|
||||
|
||||
More details can be found in the (GitHub Issue](https://github.com/zitadel/zitadel/issues/6601)
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Analytics</summary>
|
||||
|
||||
We provide comprehensive and insightful analytics capabilities that empower you with the information needed to understand platform usage, monitor system health, and make data-driven decisions.
|
||||
|
||||
<details>
|
||||
<summary>Login Insights: Successful and Failed Login Metrics</summary>
|
||||
|
||||
To enhance security monitoring and gain insights into user authentication patterns, administrators need access to login metrics.
|
||||
This feature provides data on successful and failed login attempts, allowing for filtering by time range and level (overall instance, within a specific organization, or for a particular application).
|
||||
This will enable administrators to detect suspicious login activity, analyze authentication trends, and proactively address potential security concerns.
|
||||
|
||||
For more details track our [GitHub issue](https://github.com/zitadel/zitadel/issues/9711).
|
||||
</details>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>Impersonation: External Token Exchange</summary>
|
||||
|
||||
This feature expands our existing impersonation capabilities to support seamless and secure integration with external, third-party applications.
|
||||
Currently, our platform supports impersonation for internal use cases, allowing administrators or support staff to obtain a temporary token for an end-user to troubleshoot issues or provide assistance within applications that already use ZITADEL for authentication. (You can find more details in our [existing documentation](/guides/integrate/token-exchange)).
|
||||
|
||||
The next evolution of this feature will focus on external applications.
|
||||
This enables scenarios where a user, already authenticated in a third-party system (like their primary e-banking portal), can seamlessly access a connected application that is secured by ZITADEL without needing to log in again.
|
||||
|
||||
For example, a user in their e-banking app could click to open an integrated "Budget Planning" tool that relies on ZITADEL for access.
|
||||
Using a secure token exchange, the budget app will grant the user a valid session on their behalf, creating a smooth, uninterrupted user experience while maintaining a high level of security.
|
||||
This enhancement bridges the authentication gap between external platforms and ZITADEL-powered applications.
|
||||
</details>
|
||||
</details>
|
||||
|
||||
### Future Vision / Upcoming Features
|
||||
|
||||
#### Fine Grained Authorization
|
||||
|
||||
We're planning the future of Zitadel and fine-grained authorization is high on our list.
|
||||
While Zitadel already offers strong role-based access (RBAC), we know many of you need more granular control.
|
||||
|
||||
**What is Fine-Grained Authorization?**
|
||||
|
||||
It's about moving beyond broad roles to define precise access based on:
|
||||
|
||||
- Attributes (ABAC): User details (department, location), resource characteristics (sensitivity), or context (time of day).
|
||||
- Relationships (ReBAC): Connections between users and resources (e.g., "owner" of a document, "manager" of a team).
|
||||
- Policies (PBAC): Explicit rules combining attributes and relationships.
|
||||
|
||||
**Why Explore This?**
|
||||
|
||||
Fine-grained authorization can offer:
|
||||
- Tighter Security: Minimize access to only what's essential.
|
||||
- Greater Flexibility: Adapt to complex and dynamic business rules.
|
||||
- Easier Compliance: Meet strict regulatory demands.
|
||||
- Scalable Permissions: Manage access effectively as you grow.
|
||||
|
||||
**We Need Your Input!** 🗣️
|
||||
|
||||
As we explore the best way to bring this to Zitadel, tell us:
|
||||
- Your Use Cases: Where do you need more detailed access control than standard roles provide?
|
||||
- Preferred Models: Are you thinking attribute-based, relationship-based, or something else?
|
||||
- Integration Preferences:
|
||||
- A fully integrated solution within Zitadel?
|
||||
- Or integration with existing authorization vendors (e.g. openFGA, cerbos, etc.)?
|
||||
|
||||
Your feedback is crucial for shaping our roadmap.
|
||||
|
||||
🔗 Share your thoughts and needs in our [discussion forum](https://discord.com/channels/927474939156643850/1368861057669533736)
|
||||
|
||||
#### Threat Detection
|
||||
|
||||
We're taking the next step in securing your applications by exploring a new Threat Detection framework for Zitadel.
|
||||
Our goal is to proactively identify and stop malicious activity in real-time.
|
||||
|
||||
**Our First Step: A Modern reCAPTCHA Alternative**
|
||||
We will begin by building a system to detect and mitigate malicious bots, serving as a smart, privacy-focused alternative to CAPTCHA.
|
||||
This initial use case will help us combat credential stuffing, spam registrations, and other automated attacks, forming the foundation of our larger framework.
|
||||
|
||||
**How We Envision It**
|
||||
|
||||
Our exploration is focused on creating an intelligent system that:
|
||||
- **Analyzes Signals**: Gathers data points like IP reputation, device characteristics, and user behavior to spot suspicious activity.
|
||||
- **Uses AI/**: Trains models to distinguish between legitimate users and bots, reducing friction for real users.
|
||||
- **Mitigates Threats**: Enables flexible responses when a threat is detected, such as blocking the attempt, requiring MFA, or sending an alert.
|
||||
|
||||
**Help Us Shape the Future** 🤝
|
||||
|
||||
As we design this framework, we need to know:
|
||||
- What are your biggest security threats today?
|
||||
- What kind of automated responses (e.g., block, notification) would be most useful for you?
|
||||
- What are your key privacy or compliance concerns regarding threat detection?
|
||||
|
||||
Your feedback will directly influence our development and ensure we build a solution that truly meets your needs.
|
||||
|
||||
🔗 Join the conversation and share your insights [here](https://discord.com/channels/927474939156643850/1375383775164235806)
|
||||
|
||||
#### The Role of AI in Zitadel
|
||||
|
||||
As we look to the future, we believe Artificial Intelligence will be a critical tool for enhancing both user experience and security within Zitadel.
|
||||
Our vision for AI is focused on two key areas: providing intelligent, contextual assistance and building a collective defense against emerging threats.
|
||||
|
||||
1. **AI-Powered Support**
|
||||
|
||||
We want you to get fast, accurate answers to your questions without ever having to leave your workflow.
|
||||
To achieve this, we are integrating an AI-powered support assistant trained on our knowledge base, including our documentation, tutorials, and community discussions.
|
||||
|
||||
Our rollout is planned in phases to ensure we deliver a helpful experience:
|
||||
- **Phase 1 (Happening Now)**: We are currently testing a preliminary version of our AI bot within our [community channels](https://discord.com/channels/927474939156643850/1357076488825995477). This allows us to gather real-world questions and answers, refining the AI's accuracy and helpfulness based on direct feedback.
|
||||
- **Phase 2 (Next Steps)**: Once we are confident in its capabilities, we will integrate this AI assistant directly into our documentation. You'll be able to ask complex questions and get immediate, well-sourced answers.
|
||||
- **Phase 3 (The Ultimate Goal)**: The final step is to embed the assistant directly into the ZITADEL Management Console/Customer Portal. Imagine getting help based on the exact context of what you're doing—whether you're configuring an action, setting up a new organization, or integrating social login.
|
||||
|
||||
2. **Decentralized AI for Threat Detection**
|
||||
|
||||
Security threats are constantly evolving.
|
||||
A threat vector that targets one customer today might target another tomorrow.
|
||||
We believe in the power of collective intelligence to provide proactive security for everyone.
|
||||
|
||||
This leads to our second major AI initiative: **decentralized model training** for our Threat Detection framework.
|
||||
|
||||
Here’s how it would work:
|
||||
- **Collective Data, Anonymously**: Customers across our cloud and self-hosted environments experience different user behaviors and threat vectors. We plan to offer an opt-in system where anonymized, non-sensitive data (like behavioral patterns and threat signals) can be collected from participating instances.
|
||||
- **Centralized Training**: This collective, anonymized data will be used to train powerful, next-generation AI security models. With a much larger and more diverse dataset, these models can learn to identify subtle and emerging threats far more effectively than a model trained on a single instance's data.
|
||||
- **Shared Protection**: These constantly improving models would then be distributed to all participating Zitadel instances.
|
||||
|
||||
The result is a powerful security network effect. You could receive protection from a threat vector you haven't even experienced yet, simply because the system learned from an attack on another member of the community.
|
||||
|
||||
## Zitadel Ecosystem
|
||||
|
||||
### PHP SDK
|
||||
|
||||
GitHub Repository: [PHP SDK](https://github.com/zitadel/client-php)
|
||||
|
||||
#### v3.x (PHP)
|
||||
|
||||
<SDKv3 components={props.components} />
|
||||
|
||||
### Java SDK
|
||||
|
||||
GitHub Repository: [Java SDK](https://github.com/zitadel/client-java)
|
||||
|
||||
#### v3.x (Java)
|
||||
|
||||
<SDKv3 components={props.components} />
|
||||
|
||||
### Ruby SDK
|
||||
|
||||
GitHub Repository: [Ruby SDK](https://github.com/zitadel/client-ruby)
|
||||
|
||||
#### v3.x (Ruby)
|
||||
|
||||
<SDKv3 components={props.components} />
|
||||
|
||||
### Python SDK
|
||||
|
||||
GitHub Repository: [Python SDK](https://github.com/zitadel/client-python)
|
||||
|
||||
#### v3.x (Python)
|
||||
|
||||
<SDKv3 components={props.components} />
|
||||
* Adopt new platform capabilities without disrupting existing deployments.
|
||||
* Plan migration based on your own priorities and timelines.
|
||||
* Continue building on the same platform as your identity requirements evolve.
|
||||
|
||||
@@ -861,11 +861,9 @@ export const guidesSidebar: readonly SidebarItem[] = [
|
||||
collapsed: true,
|
||||
items: [
|
||||
{
|
||||
type: "category",
|
||||
label: "Product Features",
|
||||
items: [
|
||||
"product/roadmap",
|
||||
],
|
||||
type: "doc",
|
||||
id: "product/roadmap",
|
||||
label: "Roadmap",
|
||||
},
|
||||
{
|
||||
type: "category",
|
||||
@@ -876,7 +874,6 @@ export const guidesSidebar: readonly SidebarItem[] = [
|
||||
label: "Changelog",
|
||||
href: "https://zitadel.com/changelog",
|
||||
},
|
||||
"product/release-cycle",
|
||||
],
|
||||
},
|
||||
{
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 100 KiB |
Reference in New Issue
Block a user