Skip to main content
Version: 8.0


This page guides you through Camunda Platform 8 Docker images and how to run the platform in a developer setup using Docker Compose.

Docker images

We provide Docker images via Dockerhub. All those images are publicly accessible.


The provided Docker images are supported for production usage only on Linux systems. Windows or macOS are only supported for development environments.

ComponentDocker imageLink to configuration options
Zeebecamunda/zeebe:latestEnvironment variables
Operatecamunda/operate:latestOperate configuration
Tasklistcamunda/tasklist:latestTasklist configuration
Identitycamunda/identity:latestConfiguration variables
Optimizecamunda/optimize:latestEnvironment variables

Zeebe is the only component that is often run on its own as a standalone component. In this scenario, it does not need anything else, so a simple docker run is sufficient:

docker run --name zeebe -p 26500-26502:26500-26502 camunda/zeebe:latest

This will give you a single broker node with the following ports exposed:

  • 26500: Gateway API (this is the port clients need to use)
  • 26501: Command API (internal, gateway-to-broker)
  • 26502: Internal API (internal, broker-to-broker)

Docker Compose

A Docker Compose configuration to run Zeebe, Operate, Tasklist, Optimize, and Identity is available in the camunda-platform repository. Follow the instructions in the README.


While the Docker images themselves are supported for production usage, the Docker Compose files are designed to be used by developers to run an environment locally; they are not designed to be used in production. We recommend to use Kubernetes in production, see also Installation Overview.

This Docker Compose configuration serves two purposes:

  1. It can be used to start up a development environment locally.
  2. It documents how the various components need to be wired together.

We recommend to use Helm + KIND instead of Docker Compose for local environments, as the Helm configurations are battle-tested and much closer to production systems.

Configuration hints



The default data volume is under /usr/local/zeebe/data. It contains all data which should be persisted.


The Zeebe configuration is located at /usr/local/zeebe/config/application.yaml. The logging configuration is located at /usr/local/zeebe/config/log4j2.xml.

The configuration of the Docker image can also be changed using environment variables. The configuration template file also contains information on the environment variables to use for each configuration setting.

Available environment variables:

  • ZEEBE_LOG_LEVEL - Sets the log level of the Zeebe Logger (default: info).
  • ZEEBE_BROKER_NETWORK_HOST - Sets the host address to bind to instead of the IP of the container.
  • ZEEBE_BROKER_CLUSTER_INITIALCONTACTPOINTS - Sets the contact points of other brokers in a cluster setup.


Some configuration properties are optional and have default values. See a description of these properties and their default values in the table below:

NameDescriptionDefault value
SPRING_PROFILES_ACTIVEStarts Optimize in Self-Managed mode.
CAMUNDA_OPTIMIZE_IDENTITY_ISSUER_URLThe URL at which Identity can be accessed by Optimize.
CAMUNDA_OPTIMIZE_IDENTITY_ISSUER_BACKEND_URLThe URL at which the Identity auth provider can be accessed by Optimize. This should match the configured provider in Identity and is to be used for container to container communication.
CAMUNDA_OPTIMIZE_IDENTITY_CLIENTIDThe Client ID used to register Optimize with Identity.
CAMUNDA_OPTIMIZE_IDENTITY_CLIENTSECRETThe Secret used when registering Optimize with Identity.
CAMUNDA_OPTIMIZE_IDENTITY_AUDIENCEThe audience used when registering Optimize with Identity.
OPTIMIZE_ELASTICSEARCH_HOSTThe address/hostname under which the Elasticsearch node is available.localhost
OPTIMIZE_ELASTICSEARCH_HTTP_PORTThe port number used by Elasticsearch to accept HTTP connections.9200
CAMUNDA_OPTIMIZE_SECURITY_AUTH_COOKIE_SAME_SITE_ENABLEDDetermines if same-site is enabled for Optimize cookies. This must be set to false.true
CAMUNDA_OPTIMIZE_ENTERPRISEThis should only be set to true if an Enterprise License has been acquired.true
CAMUNDA_OPTIMIZE_ZEEBE_ENABLEDEnables import of Zeebe data in Optimize.false
CAMUNDA_OPTIMIZE_ZEEBE_NAMEThe record prefix for exported Zeebe records.zeebe-record
CAMUNDA_OPTIMIZE_ZEEBE_PARTITION_COUNTThe number of partitions configured in Zeebe.1
CAMUNDA_OPTIMIZE_SHARING_ENABLEDEnable/disable the possibility to share reports and dashboards.true
CAMUNDA_OPTIMIZE_UI_LOGOUT_HIDDENDisables the logout button (logout is handled by Identity).true
SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URIAuthentication for the Public REST API using a resource server to validate the JWT token. Complete URI to get public keys for JWT validation.null
OPTIMIZE_API_ACCESS_TOKENAuthentication for the Public REST API using a static shared token. Will be ignored if SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_JWK_SET_URI is also set.null

Like for example this docker-compose configuration:

container_name: optimize
image: camunda/optimize:latest
- 8090:8090
- CAMUNDA_OPTIMIZE_IDENTITY_ISSUER_BACKEND_URL=http://keycloak:8080/auth/realms/camunda-platform

Self-Managed Optimize must be able to connect to Elasticsearch to write and read data. In addition, Optimize needs to connect to Identity for authentication purposes. Both of these requirements can be configured with the options described above.

Optimize must also be configured as a client in Identity, and users will only be granted access to Optimize if they have a role that has write:* permission for Optimize.

For Optimize to import Zeebe data, Optimize must also be configured to be aware of the record prefix used when the records are exported to Elasticsearch. This can also be configured per the example above.