camunda-zeebe

Runs a distributed workflow engine for microservice orchestration and durable job execution, typically deployed as part of a Camunda 8 stack. [Docker Hub+1](https://hub.docker.com/r/camunda/zeebe/?utm_source=chatgpt.com)

camunda/operate
camunda/tasklist
camunda/zeebe-gateway
elastic/elasticsearch

What is camunda-zeebe image?

The camunda-zeebe image (published as camunda/zeebe) runs Zeebe, a distributed workflow engine used to orchestrate long-running business processes and microservice interactions using BPMN. Zeebe executes workflows by persisting state and dispatching work to external workers via gRPC, making it well-suited for event-driven architectures where you need retries, timeouts, and backpressure without building that logic into every service. In containerized environments it’s commonly deployed on Kubernetes with multiple brokers for partitioned processing and replication, plus a gateway that routes client requests to the appropriate partitions. Zeebe can be configured through YAML config files and/or environment variables (with env vars taking precedence), which fits well with Kubernetes-style configuration and GitOps workflows. Camunda 8 Docs+1

How to use this image

Zeebe is typically deployed as a cluster (brokers + gateway) using Helm or Docker Compose, but you can run a single-node instance for local development. The gateway exposes gRPC (default 26500) and a REST API (default 8080), and the management/health endpoints are commonly served on port 9600 for readiness/liveness probing. Camunda 8 Docs+1

Run a single-node Zeebe for development:

docker run -d --name zeebe \
  -p 26500:26500 \
  -p 8080:8080 \
  -p 9600:9600 \
  -v zeebe-data:/usr/local/zeebe/data \
  camunda/zeebe:latest

Use health endpoints (example):

curl -s http://localhost:9600/actuator/health

Mount a custom configuration file (preferred when making larger configuration changes):

docker run -d --name zeebe \
  -p 26500:26500 -p 8080:8080 -p 9600:9600 \
  -v $(pwd)/application.yaml:/usr/local/zeebe/config/application.yaml \
  -v zeebe-data:/usr/local/zeebe/data \
  camunda/zeebe:latest

In production, baking configuration into an image (COPY) or managing it via Kubernetes ConfigMaps/Secrets is generally more reproducible than relying on ad hoc local mounts, especially for cluster-wide consistency. Camunda 8 Docs+1

Image variants

Published under camunda/zeebe, the image is available in multiple variants:

  • camunda/zeebe:latest – Tracks the most recent stable release; useful for evaluation and dev, but not recommended for production pinning.
  • camunda/zeebe: – Version-pinned tags (for example, 8.x.y) used to keep broker/gateway behavior consistent across environments; recommended for production.
  • Multi-platform manifests (amd64/arm64) – Camunda publishes multi-platform images; amd64 is typically recommended for production, while arm64 is commonly positioned for development use.

Interested in base images that start and stay clean?