Zitadel Release Versions and Roadmap

                    <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>

<NewFeature components={props.components} />

<details>
    <summary>Actions V2</summary>

    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.

    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.

    Read more in our [documentation](https://zitadel.com/docs/concepts/features/actions_v2)
</details>

<details>
    <summary>License Change Apache 2.0 to AGPL3</summary>

    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.

    Read more about our [decision](https://zitadel.com/blog/apache-to-agpl)
</details>

<BreakingChanges components={props.components} />

<details>
    <summary>CockroachDB Support removed</summary>

    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.

    More details can be found [here](https://github.com/zitadel/zitadel/issues/9414)
</details>

<details>
    <summary>Actions API v3 alpha removed</summary>

    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)

</details>

<NewFeature components={props.components} />

<details>
    <summary>Resource API (v2)</summary>

    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.

    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

    For more details read the [Github Issue](https://github.com/zitadel/zitadel/issues/6305)
</details>

<details>
    <summary>Login V2</summary>

    Our new login UI has been enhanced with additional features, bringing it to feature parity with Version 1.

    <details>
        <summary>Device Authorization Flow</summary>

        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.

        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>

    <details>
        <summary>LDAP IDP</summary>

        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>

    <details>
        <summary>JWT IDP</summary>

        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.

        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.

        Read more in our docs about how to login users with [JWT IDP](https://zitadel.com/docs/guides/integrate/identity-providers/jwt_idp)
    </details>

    <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>

<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>

<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>

<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>

    <details>
        <summary>Resource Count Metrics</summary>

        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.

        For more details track our [github issue](https://github.com/zitadel/zitadel/issues/9709).
    </details>

    <details>
        <summary>Operational Metrics</summary>

        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.

        For more details track our [github issue](https://github.com/zitadel/zitadel/issues/9476).

    </details>
</details>

<details>
    <summary>User Groups</summary>

    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>

<details>
    <summary>User Uniqueness on Organization Level</summary>

    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>

<Deprecated components={props.components} />

<details>
    <summary>Actions V1</summary>
</details>

<BreakingChanges components={props.components} />

<details>
    <summary>Hosted Login v1 will be removed</summary>
</details>

<details>
    <summary>Zitadel APIs v1 will be removed</summary>
</details>

<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>