Skip to main content
Version: 8.6

Configuration

As a Spring Boot application, Operate supports any standard Spring configuration method.

By default, the configuration for Operate is stored in a YAML file (application.yml). All Operate-related settings are prefixed with camunda.operate.

note

Configuration properties can be defined as environment variables using Spring Boot conventions. To define an environment variable, convert the configuration property to uppercase, remove any dashes, and replace any delimiters (.) with _.

For example, the property camunda.operate.elasticsearch.clustername is represented by the environment variable CAMUNDA_OPERATE_ELASTICSEARCH_CLUSTERNAME.

The following parts are configurable:

Licensing

Camunda 8 Self-Managed only

Installations of Camunda 8 Self-Managed which require a license can provide their license key to the components as an environment variable:

Environment variableDescriptionDefault value
CAMUNDA_LICENSE_KEYYour Camunda 8 license key, if your installation requires a license.None

For Helm installations, license keys can be configured globally in your values.yaml file. See the Helm installation documentation for more details.

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.

Webserver

Operate supports customizing the context-path using default Spring configuration.

Example for application.yml: server.servlet.context-path: /operate

Example for environment variable: SERVER_SERVLET_CONTEXT_PATH=/operate

The default context-path is /.

Security

To change the values for http header for security reasons, you can use the configuration parameters:

NameDescriptionDefault value
camunda.operate.websecurity.contentSecurityPolicySee Spring descriptionbase-uri 'self'; default-src 'self' 'unsafe-inline' 'unsafe-eval' cdn.jsdelivr.net;img-src * data:; block-all-mixed-content; form-action 'self'; frame-ancestors 'none'; object-src 'none'; font-src 'self' fonts.camunda.io cdn.jsdelivr.net; sandbox allow-forms allow-scripts allow-same-origin allow-popups
camunda.operate.websecurity.httpStrictTransportSecurityMaxAgeInSecondsSee Spring description63,072,000 (two years)
camunda.operate.websecurity.httpStrictTransportSecurityIncludeSubDomainsSee Spring descriptiontrue

Multi-tenancy

Multi-tenancy in the context of Camunda 8 refers to the ability of Camunda 8 to serve multiple distinct tenants or clients within a single installation.

From version 8.3 onwards, Operate has been enhanced to support multi-tenancy for Self-Managed setups. More information about the feature can be found in the multi-tenancy documentation.

The following configuration is required to enable multi-tenancy in Operate:

YAML pathEnvironment variableDescriptionDefault value
camunda.operate.multiTenancy.enabledCAMUNDA_OPERATE_MULTITENANCY_ENABLEDActivates the multi-tenancy feature within Operate.false

The same rules apply to the Operate API.

note

To ensure seamless integration and functionality, the multi-tenancy feature must also be enabled across all associated components if not configured in Helm so users can view any data from tenants for which they have authorizations configured in Identity.

Find more information (including links to individual component configuration) on the multi-tenancy concepts page.

Securing Operate - Zeebe interaction

While executing user operations, Operate communicates with Zeebe using the Zeebe Java client. For Zeebe to know whether operations are allowed to be executed in terms of tenant assignment, Operate - Zeebe connection must be secured. Check the list of environment variables to be provided in the Zeebe documentation.

Troubleshooting multi-tenancy in Operate

If users can view data from the <default> tenant only and no data from other tenants (and you have not configured multi-tenancy using Helm), multi-tenancy is not enabled in Operate. Refer to the configuration instructions above.

If multi-tenancy is enabled in Operate but disabled in Identity, users will not have any tenant authorizations in Operate and will not be able to access the data of any tenants in Operate.

Elasticsearch or OpenSearch

Operate stores and reads data from Elasticsearch or OpenSearch.

Set the camunda.operate.database to the appropriate database.

Valid values are elasticsearch (default) and opensearch.

Example as environment variable: CAMUNDA_OPERATE_DATABASE=opensearch.

note

As of the 8.4 release, Operate is now compatible with Amazon OpenSearch 2.5.x. Note that using Amazon OpenSearch requires setting up a new Camunda installation. A migration from previous versions or Elasticsearch environments is currently not supported.

Settings to connect

Operate supports basic authentication for Elasticsearch and OpenSearch

Set the appropriate username/password combination in the configuration to use it.

Settings for Elasticsearch

Settings to connect to a secured Elasticsearch instance

To connect to a secured (https) Elasticsearch instance, you normally need to only set the URL protocol part to https instead of http. A secured Elasticsearch instance also needs username and password. The other SSL settings should only be used in case of connection problems; for example, in disabling host verification.

note

You may need to import the certificate into JVM runtime.

Either set host and port (deprecated), or url (recommended).

NameDescriptionDefault value
camunda.operate.elasticsearch.indexPrefixPrefix for index namesoperate
camunda.operate.elasticsearch.clusterNameCluster name of Elasticsearchelasticsearch
camunda.operate.elasticsearch.urlURL of Elasticsearch REST APIhttp://localhost:9200
camunda.operate.elasticsearch.usernameUsername to access Elasticsearch REST API-
camunda.operate.elasticsearch.passwordPassword to access Elasticsearch REST API-
camunda.operate.elasticsearch.ssl.certificatePathPath to certificate used by Elasticsearch-
camunda.operate.elasticsearch.ssl.selfSignedCertificate was self-signedfalse
camunda.operate.elasticsearch.ssl.verifyHostnameShould the hostname be validatedfalse

Settings for shards and replicas

Operate creates the template with index settings named operate-<version>_template that Elasticsearch uses for all Operate indices. These settings can be changed.

The following configuration parameters define the settings:

NameDescriptionDefault value
camunda.operate.elasticsearch.numberOfShardsHow many shards Elasticsearch uses for all Operate indices1
camunda.operate.elasticsearch.numberOfReplicasHow many replicas Elasticsearch uses for all Operate indices0

These values are applied only on first startup of Operate or during version update. After the Operate schema is created, settings may be adjusted directly in the Elasticsearch template, and the new settings are applied to indices created after adjustment.

A snippet from application.yml

camunda.operate:
elasticsearch:
# Cluster name
clusterName: elasticsearch
# Url
url: https://localhost:9200
ssl:
selfSigned: true

Settings for OpenSearch

Settings to connect to a secured OpenSearch instance

To connect to a secured (https) OpenSearch instance, you normally need to only set the URL protocol part to https instead of http. A secured OpenSearch instance also needs username and password.

To use AWS credentials instead of basic auth when connecting to Amazon OpenSearch Services, awsEnabled must be set.

The other SSL settings should only be used in case of connection problems; for example, in disabling host verification.

note

You may need to import the certificate into JVM runtime.

Either set host and port (deprecated), or url (recommended).

NameDescriptionDefault value
camunda.operate.opensearch.indexPrefixPrefix for index namesoperate
camunda.operate.opensearch.clusterNameCluster name of OpenSearchopensearch
camunda.operate.opensearch.urlURL of OpenSearch REST APIhttp://localhost:9200
camunda.operate.opensearch.usernameUsername to access OpenSearch REST API-
camunda.operate.opensearch.passwordPassword to access OpenSearch REST API-
camunda.operate.opensearch.ssl.certificatePathPath to certificate used by OpenSearch-
camunda.operate.opensearch.ssl.selfSignedCertificate was self-signedfalse
camunda.operate.opensearch.ssl.verifyHostnameShould the hostname be validatedfalse
camunda.operate.opensearch.awsEnabledShould AWS credentials be usedfalse

Settings for shards and replicas

Operate creates the template with index settings named operate-<version>_template that OpenSearch uses for all Operate indices. These settings can be changed.

The following configuration parameters define the settings:

NameDescriptionDefault value
camunda.operate.opensearch.numberOfShardsHow many shards OpenSearch uses for all Operate indices1
camunda.operate.opensearch.numberOfReplicasHow many replicas OpenSearch uses for all Operate indices0

These values are applied only on first startup of Operate or during version update. After the Operate schema is created, settings may be adjusted directly in the OpenSearch template, and the new settings are applied to indices created after adjustment.

A snippet from application.yml

camunda.operate:
opensearch:
# Cluster name
clusterName: opensearch
# Url
url: https://localhost:9200
ssl:
selfSigned: true

Zeebe Broker connection

Operate needs a connection to the Zeebe Broker to start the import and execute user operations.

Settings to connect

NameDescriptionDefault value
camunda.operate.zeebe.gatewayAddressGateway address that points to Zeebe as hostname and port.localhost:26500
camunda.operate.zeebe.secureConnection should be secure via Transport Layer Security (TLS).false
camunda.operate.zeebe.certificatePathPath to certificate used by Zeebe. This is necessary when the certificate isn't registered in the operating system-

Additionally, visit Zeebe Secure Client Communication for more details.

A snippet from application.yml

camunda.operate:
zeebe:
# Gateway host and port
gatewayAddress: localhost:26500

Zeebe Elasticsearch or OpenSearch exporter

note

Please refer to Supported Environments to find out which versions of Elasticsearch or OpenSearch are supported in a Camunda 8 Self-Managed setup.

For Elasticsearch, Operate imports data from indices created and filled in by the Zeebe Elasticsearch exporter.

For OpenSearch, Operate imports data from indices created and filled in by the Zeebe OpenSearch exporter.

Therefore, settings for this Elasticsearch or OpenSearch connection must be defined and must correspond to the settings on the Zeebe side.

Settings to connect and import

See also settings to connect to a secured Elasticsearch or OpenSearch instance.

note

You may need to import the certificate keystore into the JVM runtime.

# Kubernetes example:
zeebe:

javaOpts: >-

-Djavax.net.ssl.trustStore=/path/to/certificates/elasticsearch.jks
NameDescriptionDefault value
camunda.operate.zeebeElasticsearch.clusterNameCluster name of Elasticsearchelasticsearch
camunda.operate.zeebeElasticsearch.urlURL of Zeebe Elasticsearch REST APIhttp://localhost:9200
camunda.operate.zeebeElasticsearch.prefixIndex prefix as configured in Zeebe Elasticsearch exporterzeebe-record
camunda.operate.zeebeElasticsearch.usernameUsername to access Elasticsearch REST API-
camunda.operate.zeebeElasticsearch.passwordPassword to access Elasticsearch REST API-
camunda.operate.zeebeElasticsearch.ssl.certificatePathPath to certificate used by Elasticsearch-
camunda.operate.zeebeElasticsearch.ssl.selfSignedCertificate was self-signedfalse
camunda.operate.zeebeElasticsearch.ssl.verifyHostnameShould the hostname be validatedfalse

Snippet from application.yml for Elasticsearch

camunda.operate:
zeebeElasticsearch:
# Cluster name
clusterName: elasticsearch
# Url
url: https://localhost:9200
# Index prefix, configured in Zeebe Elasticsearch exporter
prefix: zeebe-record

Example for OpenSearch:

NameDescriptionDefault value
camunda.operate.zeebeOpensearch.clusterNameCluster name of OpenSearchopensearch
camunda.operate.zeebeOpensearch.urlURL of Zeebe OpenSearch REST APIhttp://localhost:9200
camunda.operate.zeebeOpensearch.prefixIndex prefix as configured in Zeebe OpenSearch exporterzeebe-record
camunda.operate.zeebeOpensearch.usernameUsername to access OpenSearch REST API-
camunda.operate.zeebeOpensearch.passwordPassword to access OpenSearch REST API-
camunda.operate.zeebeOpensearch.ssl.certificatePathPath to certificate used by OpenSearch-
camunda.operate.zeebeOpensearch.ssl.selfSignedCertificate was self-signedfalse
camunda.operate.zeebeOpensearch.ssl.verifyHostnameShould the hostname be validatedfalse

Snippet from application.yml for OpenSearch

camunda.operate:
zeebeOpensearch:
# Cluster name
clusterName: opensearch
# Url
url: https://localhost:9200
# Index prefix, configured in Zeebe OpenSearch exporter
prefix: zeebe-record

Operation executor

Operations are user operations, like cancellation of process instance(s) or updating the variable value.

Operations are executed in a multi-threaded manner.

NameDescriptionDefault value
camunda.operate.operationExecutor.threadsCountHow many threads should be used.3

Snippet from application.yml

camunda.operate:
operationExecutor:
threadsCount: 3

Monitoring Operate

Operate includes Spring Boot Actuator inside. This provides the number of monitoring possibilities.

Operate uses the following Actuator configuration by default:

# Disable default health indicators
# https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html#production-ready-health-indicators
management.health.defaults.enabled: false
# enable Kubernetes health groups:
# https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html#production-ready-kubernetes-probes
management.health.probes.enabled: true
# enable several Actuator endpoints
management.endpoints.web.exposure.include: health, prometheus, loggers, usage-metrics, backup

With this configuration, the following endpoints are available for use out of the box:

<server>:8080/actuator/prometheus Prometheus metrics

<server>:8080/actuator/health/liveness Liveness probe

<server>:8080/actuator/health/readiness Readiness probe

This configuration may be overwritten by changing the corresponding configuration parameters values.

Versions before 0.25.0

In versions before 0.25.0, management endpoints look different. Therefore, we recommend reconfiguring for next versions.

NameBefore 0.25.0Starting with 0.25.0
Readiness/api/check/actuator/health/readiness
Liveness/actuator/health/actuator/health/liveness

Logging

Operate uses the Log4j2 framework for logging. In the distribution archive, as well as inside a Docker image, config/log4j2.xml logging configuration files are included and can be further adjusted to your needs:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN" monitorInterval="30">
<Properties>
<Property name="LOG_PATTERN">%clr{%d{yyyy-MM-dd HH:mm:ss.SSS}}{faint} %clr{%5p} %clr{${sys:PID}}{magenta} %clr{---}{faint} %clr{[%15.15t]}{faint} %clr{%-40.40c{1.}}{cyan} %clr{:}{faint} %m%n%xwEx</Property>
</Properties>
<Appenders>
<Console name="Console" target="SYSTEM_OUT" follow="true">
<PatternLayout pattern="${LOG_PATTERN}"/>
</Console>
<Console name="Stackdriver" target="SYSTEM_OUT" follow="true">
<StackdriverJSONLayout/>
</Console>
</Appenders>
<Loggers>
<Logger name="io.camunda.operate" level="info" />
<Root level="info">
<AppenderRef ref="${env:OPERATE_LOG_APPENDER:-Console}"/>
</Root>
</Loggers>
</Configuration>

By default, ConsoleAppender is used.

JSON logging configuration

You can choose to output logs in JSON format (Stackdriver compatible). To enable it, define the environment variable OPERATE_LOG_APPENDER like this:

OPERATE_LOG_APPENDER=Stackdriver

Change logging level at runtime

Operate supports the default scheme for changing logging levels as provided by Spring Boot.

The log level for Operate can be changed by following the Setting a Log Level section.

Set all Operate loggers to DEBUG

curl 'http://localhost:8080/actuator/loggers/io.camunda.operate' -i -X POST \
-H 'Content-Type: application/json' \
-d '{"configuredLevel":"debug"}'

Example of application.yml file

The following snippet represents the default Operate configuration, which is shipped with the distribution. This can be found inside the config folder (config/application.yml) and can be used to adjust Operate to your needs.

# Operate configuration file

camunda.operate:
# Set operate userId, displayName and password.
# If user with <userId> does not exists it will be created.
# Default: demo/demo/demo
userId: anUserId
displayName: nameShownInWebpage
password: aPassword
roles:
- OWNER
- USER
# ELS instance to store Operate data
elasticsearch:
# Cluster name
clusterName: elasticsearch
# Url
url: http://localhost:9200
# Zeebe instance
zeebe:
# Gateway address to zeebe
gatewayAddress: localhost:26500
# ELS instance to export Zeebe data to
zeebeElasticsearch:
# Cluster name
clusterName: elasticsearch
# url
url: http://localhost:9200
# Index prefix, configured in Zeebe Elasticsearch exporter
prefix: zeebe-record