Skip to main content
Version: Next

8.6 Announcements

Important changes and updates for the Camunda 8.6 release are summarized below.

Release dateEnd of maintenanceRelease notes
8 October 202414 April 20268.6 release notes

License key changes​

With the 8.6 release, Camunda 8 Self-Managed requires a license key for production usage. For additional details, review the blog post on licensing updates for Camunda 8 Self-Managed.

Review the following documentation for your components for more information on how to provide the license key to each component as an environment variable:

To configure with Helm, visit the Self Managed installation documentation.

note

Camunda 8 components without a valid license may display Non-Production License in the navigation bar and issue warnings in the logs. These warnings have no impact on startup or functionality, with the exception that Web Modeler has a limitation of five users. To obtain a license, visit the Camunda Enterprise page.

Zeebe Java client​

Starting with 8.7, the Zeebe Java client will become the new Camunda Java client. This transition brings a new Java client structure designed to enhance the user experience and introduce new features while maintaining compatibility with existing codebases.

The primary goal of those changes is to enable users to interact with Camunda clusters with one consolidated client rather than multiple. The CamundaClient will replace the ZeebeClient, offering the same functionality and adding new capabilities. If you need to continue using the old ZeebeClient, you can use the version 8.6 artifact without any issues with newer cluster versions as the client is forward-compatible.

note

The Zeebe Java client will not be developed further and will only receive bug fixes for as long as version 8.6 is officially supported.

Key changes​

  • New package structure:
    • Package io.camunda.client: This package contains the new CamundaClient and all the features slated for release in version 8.7.
  • Properties and environment variables refactoring:
    • All old Java client property names will be refactored to more general ones. For instance, zeebe.client.tenantId will become camunda.client.tenantId.
    • Similarly, environment variables will be renamed following the same concept: ZEEBE_REST_ADDRESS will become CAMUNDA_REST_ADDRESS.
  • Artifact ID change:
    • The artifactId will change from zeebe-client-java to camunda-client-java.

Deprecation: Zeebe Go client & CLI client (zbctl)​

The Zeebe Go Client and CLI client (zbctl) will be officially deprecated with the 8.6 release as part of our efforts to streamline the Camunda 8 API experience. This client and CLI utility will not be released starting with Camunda 8.6, will no longer receive new features, and will be transitioned to a community-maintained status.

The documentation of the Zeebe Go Client and CLI client (zbctl) moved to the community clients section.

Camunda 8 SaaS - Required cluster update​

caution

By August 30th, 2024 all automation clusters in Camunda 8 SaaS must be updated to the following versions at a minimum:

  • 8.2+gen27
  • 8.3+gen11
  • 8.4+gen7
  • 8.5+gen2

auth0 announced an End-Of-Life for one of the functionalities that is being utilized by previous automation clusters. The new versions are not using this functionality anymore. This update ensures your cluster will work seamlessly after auth0 deactivates the feature in production.

You minimally need to take the following update path:

  • 8.0.x -> 8.2+gen27
  • 8.1.x -> 8.2+gen27
  • 8.2.x -> 8.2+gen27
  • 8.3.x -> 8.3+gen11
  • 8.4.x -> 8.4+gen7
  • 8.5.x -> 8.5+gen2

If you do not update the cluster by August 30th 2024, we will update the cluster for you. Without an update, you would lose access to your cluster.

Camunda 8 Self-Managed clusters are not affected by this.

Support for Amazon OpenSearch for Optimize​

This release extends the OpenSearch features supported by Optimize. Full support is committed for the next release in January 2025.

Supported environment changes (OpenJDK, ElasticSearch, Amazon OpenSearch)​

Version changes are made to supported environments:

  • OpenJDK minimum version raised to 21+ in Operate
  • ElasticSearch minimum version raised to 8.13+
  • Amazon OpenSearch minimum version raised to 2.9+

To learn more about supported environments, see supported environments.

Connectors​

Deprecation: None start event element templates for Kafka, RabbitMQ, Amazon SQS, and Amazon SNS inbound Connectors​

The none start event element templates for the out-of-the-box Kafka, RabbitMQ, Amazon SQS, and Amazon SNS inbound Connectors have been deprecated in Camunda Modeler.

Users can no longer select these templates when creating a new none start event element in Camunda Modeler. Existing none start event elements with these templates will continue to work as expected, but users are encouraged to migrate to the message start event element templates for these Connectors.

Message start event element templates are better suited for the message-based communication these Connectors provide, and offer more flexibility and features compared to the none start event element templates, such as the ability to define a message ID and a correlation key for idempotency. Read more in the inbound Connectors documentation and the messaging concepts documentation.

Breaking changes in the Connector SDK​

The void correlate(Object variables) method in the InboundConnectorContext interface has been removed, following the deprecation in 8.4.0. Use the CorrelationResult correlateWithResult(Object variables) method instead.

The CorrelationResult record has been changed compared to the previous versions:

  • CorrelationResult.Success now contains a ProcessElementContext that represents the element that was correlated. Compared to the previous version, where the correlated element was returned directly, this change allows accessing element properties after correlation for user-controlled post-correlation actions.
  • CorrelationResult.Failure now provides the CorrelationFailureHandlingStrategy that defines how the failure should be handled.

An example of how to use the new CorrelationResult can be found in the Connector SDK documentation.

Flow control enabled by default in SaaS​

Flow control is now enabled by default in Camunda 8.6 SaaS. This change ensures the cluster is protected from excessive load and can maintain a stable state.

These new configuration defaults are tailored to the cluster size and optimized for a stable performance. However, the cluster might reject requests if the load is too high with this change. The error message for this is Failed to write client request to partition X, because the write limit is exhausted. If the error persists, this may be a sign of underlining issues, or a need to adjust the cluster size.

For more information on how to configure flow control for a Self-Managed cluster, visit the flow control documentation.

Camunda 8 Self-Managed​

Helm chart - Separated Ingress deprecation​

The separated Ingress Helm configuration for Camunda 8 Self-Managed has been deprecated in 8.6, and will be removed from the Helm chart in 8.7. Only the combined Ingress configuration is officially supported. See the Ingress guide for more information on configuring a combined Ingress setup.

Helm chart - global.multiregion.installationType deprecation​

The global.multiregion.installationType option is used in failover and failback scenarios. This option in the Helm chart has been deprecated in 8.6, and will be removed from the Helm chart in 8.7. global.multiregion.installationType was replaced with a set of API endpoints called while following the (dual-region operational procedure)

Helm chart - Elasticsearch nodes number​

The default value of Elasticsearch deployment pods has changed from 2 to 3, and an affinity setting has been added to avoid scheduling Elasticsearch pods on the same Kubernetes worker.

Camunda Optimize artifact and Docker tag separation​

Starting with Camunda 8.6, the Camunda Optimize artifact has been split into two distinct versions, and versioning between Camunda 7 and Camunda 8 is no longer interchangeable:

  • Before Camunda 8.6: Versions like 8.x and 3.x (used for Camunda 7) could sometimes be used interchangeably.
  • From Camunda 8.6 onwards: 8.6 != 3.14. Each version corresponds strictly to its platform:
    • Camunda 7: Uses the 3.x versioning scheme and the latest Docker tag.
    • Camunda 8: Uses the 8.x versioning scheme and the 8-latest Docker tag.

Action required:​

  • Camunda 7 Users: Continue using 3.x versions and the latest Docker tag.
  • Camunda 8 Users: If you haven't already done so, update your configurations to use 8.x versions and the 8-latest Docker tag.

Make sure to update your Docker configurations accordingly to ensure compatibility.

New base path for Operate and Tasklist web applications​

We are introducing a new base path for both the Operate and Tasklist web applications. This change applies to both Self-Managed and SaaS environments.

For Self-Managed​

  • The new base path for Operate is /operate, and for Tasklist, it is /tasklist.
  • For a Separated Ingress configuration:
    • for Operate, the full URL will be {operate-host}/operate. Any calls to {operate-host} will automatically be redirected to {operate-host}/operate
    • for Tasklist, the full URL will be {tasklist-host}/tasklist. Any calls to {tasklist-host} will automatically be redirected to {tasklist-host}/tasklist.
  • For a Combined Ingress configuration:
    • for Operate, the full URL will be {common-host}/{operate-contextPath}/operate. Any calls to {common-host}/{operate-contextPath} will be automatically redirected to {common-host}/{operate-contextPath}/operate.
    • for Tasklist, the full URL will be {common-host}/{tasklist-contextPath}/tasklist. Any calls to {common-host}/{tasklist-contextPath} will be automatically redirected to {common-host}/{tasklist-contextPath}/tasklist.

For SaaS​

  • The full URL for Operate is now structured as https://{region}.operate.camunda.io/{clusterId}/operate.
  • The full URL for Tasklist is now structured as https://{region}.tasklist.camunda.io/{clusterId}/tasklist.
  • Any calls to https://{region}.operate.camunda.io/{clusterId} will be redirected to https://{region}.operate.camunda.io/{clusterId}/operate.
  • Any calls to https://{region}.tasklist.camunda.io/{clusterId} will be redirected to https://{region}.tasklist.camunda.io/{clusterId}/tasklist.
note

API URLs for both Operate and Tasklist remain unchanged.