Update 8.6 to 8.7

The following sections explain which adjustments must be made to migrate from Camunda 8.6.x to 8.7.x for each component.

Camunda 8

Log pattern changes

The default log pattern for the Console appender has been changed to display the complete Mapped Diagnostic Context instead of specific keys. This means the following log statement

[2025-03-14 17:44:26.320] [Broker-0] [zb-actors-0] [ZeebePartition-1] INFO
	io.camunda.zeebe.broker.system - Transition to LEADER on term 10 starting

Will be transformed to:

[2025-03-14 17:44:26.320] [zb-actors-0] [{actor-name=ZeebePartition-1, actor-scheduler=Broker-0, partitionId=1}] INFO
	io.camunda.zeebe.broker.system - Transition to LEADER on term 10 starting

If you have any logging based alerts configured, please update them accordingly.

This does not affect the StackdriverLayout, or any other custom layout you may be using.

Backup

Google Cloud Storage

Configuring a non-existing bucket for backups will not prevent Zeebe to start up anymore and will only result in logs (at WARN) in the startup phase.

REST API key attributes change to string

With 8.7, the default REST API key attribute type changes from integer (int64) to string.

Key properties have a key suffix, and they serve as the technical unique identifier for entities, such as processDefinitionKey and tenantKey, with correlationKey being the only exception. Their type now defaults to string for the default application/json content type.

Our API can still work with key attributes as numbers using different content type headers. See the overview about API Key Attributes for more details.

Still using number keys?

If you still wish to use keys as integer (int64) types, you have to include the application/vnd.camunda.api.keys.number+json header in your client requests.

If you are using an 8.6 or 8.5 Java Client, the C8 API will recognize this and automatically return key attributes as integer (int64). You don't need to add the extra content-type header to your client requests.

Identity

Keycloak now requires v25 or v26

Identity 8.7 now requires Keycloak v25 or v26, and Keycloak versions must be updated to match. The following changes to the Helm chart have been made to support this upgrade.

Increase container resources

Keycloak containers require an increase in resources from the default. To set this increase, configure the following in the Camunda Helm chart:

resources:
  requests:
    cpu: 1000m
    memory: 1Gi
  limits:
    cpu: 2000m
    memory: 2Gi

Allow insecure images

As we repackage the Bitnami distribution with our Identity login page, allowInsecureImages must be set to true. This can be configured in the Camunda helm chart via the following:

identityKeycloak:
  global:
    security:
      allowInsecureImages: true

Connectors

Starting with 8.7, the Connector runtime will stop using the deprecated community Spring Zeebe library to communicate with the core APIs of Camunda. The new Camunda Spring Boot SDK will be used instead.

Although the official SDK is largely compatible with the community library, some changes might be required in the configuration of Self-Managed Connector deployments.

The following deprecated properties may cause issues in certain combinations:

• zeebe.client.broker.gatewayAddress (replaced with camunda.client.zeebe.grpcAddress and camunda.client.zeebe.restAddress).
• zeebe.client.security.plaintext (removed in the new SDK, determined automatically based on the http/https protocol choice in address properties above).

We recommend updating the configuration to match the new property format of the Camunda Spring Boot SDK to avoid any issues. The old properties will be removed in a future release.

If you are using the deprecated properties, you can update them as follows:

zeebe.client.broker.gatewayAddress: localhost:26500
zeebe.client.security.plaintext: true

To the new format:

camunda.client.zeebe.grpcAddress: http://localhost:26500
camunda.client.zeebe.restAddress: http://localhost:8080

For more information, see the Connectors configuration guide.