Hello Camunda Team,
Can you advise on the below ask.
We are planning to install Camunda 8.8 self managed enterprise version on AWS. do we need to pull the images from registry.camunda.cloud for elasticsearch , identity, os-shell image as well. Not directly from the open source docker images?
From the Camunda Helm chart, do we need to refer specific values.yaml for the self managed enterprise. if you can provide valid steps for enterprise would be great.
For Camunda 8.8 Self-Managed Enterprise on AWS, you should use the enterprise images from registry.camunda.cloud for Elasticsearch, Identity, and os-shell components rather than open source Docker images, and there is a specific values-enterprise.yaml file for enterprise deployments. I found the following relevant resources:
Does this help? If not, can anyone from the community jump in? 
Hints: Use the Ask AI feature in Camunda’s documentation to chat with AI and get fast help. Report bugs and features in Camuda’s GitHub issue tracker. Trust the process. 
Thanks, I am specifically looking for AKS with Entra ID integration as well. just i need to pass values-enterprise.yaml alone, or anyother values.yaml should i use for other set of parameters.
Any updates pl
Hi @Preethis,
Great questions. Here’s the breakdown:
1. Docker images
There are two categories of images to consider:
camunda/*). No special enterprise registry is needed for these.registry.camunda.cloud, which receive timely security patches.2. Enterprise values file
Yes, Camunda provides a values-enterprise.yaml that configures the chart to use the Bitnami Premium images. To use it:
First, create a registry secret with your Enterprise credentials:
kubectl create secret docker-registry registry-camunda-cloud \
--docker-server=registry.camunda.cloud \
--docker-username=<your-username> \
--docker-password=<your-password> \
--docker-email=unused@example.com
Then include the enterprise values file during installation:
helm install camunda camunda/camunda-platform --version $HELM_CHART_VERSION \
--values https://raw.githubusercontent.com/camunda/camunda-platform-helm/main/charts/camunda-platform-8.8/values-enterprise.yaml
Full details here: Install Bitnami enterprise images
3. AWS deployment
Since you’re deploying on AWS, I recommend following the reference architecture guide for EKS:
Install Camunda 8 on an EKS cluster
Important note for production: Starting with Camunda 8.8, Bitnami subcharts (Elasticsearch, PostgreSQL, Keycloak) are primarily intended for development and testing. For production, Camunda recommends using managed services (e.g., Amazon OpenSearch, Amazon RDS for PostgreSQL) or operator-based deployments. The EKS guide above covers this approach.
4. Values files and Entra ID setup
Which values files do you need?
There is no single monolithic values file that covers everything. You combine multiple values files and --set overrides depending on your setup. Here’s how it works for your case:
values-enterprise.yaml — This only configures the chart to use Bitnami Premium images (Elasticsearch, PostgreSQL, Keycloak) from registry.camunda.cloud. It does not configure Entra ID or any cloud-provider-specific settings.values.yaml — You will need to create your own values file (or use --set flags) for everything else: ingress, database endpoints, Entra ID configuration, etc.Entra ID integration
Entra ID integration is not part of the AKS reference architecture and there is no pre-built values file for it. It is a separate configuration step that you apply on top of the base installation.
Follow this dedicated guide to configure it:
Set up the Helm chart with an external Microsoft Entra tenant
This guide walks you through:
In summary, your Helm install will look something like:
helm install camunda camunda/camunda-platform --version $HELM_CHART_VERSION -–values values-enterprise.yaml --values your-custom-values.yaml
Where your-custom-values.yaml contains the Entra ID OIDC configuration (from the guide above), plus any AKS-specific settings (ingress, external database endpoints, etc.). For the AKS-specific deployment steps, refer to: (Install Camunda 8 on an AKS cluster | Camunda 8 Docs)
For the AKS-specific deployment steps, refer to:
Install Camunda 8 on an AKS cluster
Hope this helps! Let us know if you have further questions.
Thankyou @leiicamundi!
Another ask here, we are finally thinking to set it up on Azure Kubernetes Services. Since you have mentioned below note in the last response. Is this applicable for AKS Production as well with Camunda 8.8 version?
Important note for production: Starting with Camunda 8.8, Bitnami subcharts (Elasticsearch, PostgreSQL, Keycloak) are primarily intended for development and testing. For production, Camunda recommends using managed services (e.g., Amazon OpenSearch, Amazon RDS for PostgreSQL) or operator-based deployments
In general, if I use bitnami image of elastic search, instead of managed one or operator based. Is there any chance losing data if elastic search is corrupted. Or it will be okay if it has max number of master nodes.
Hi @leiicamundi ,
I am also looking to setup self manged version of camunda for non production environment in GCP GKE services. I have gone through the documents but there is nothing specific to GCP GKE.
Local setup is working fine via port forwarding but when am hosting it on gcp cloud , I cant just go for port forwarding, so is there any documentation around it how to use with some load balancers ip or global ip ?
Thanks
@leiicamundi @zee-bot - Can you pl assist.
Hi @Preethis,
Great questions — let me address both.
Yes, absolutely. The recommendation is cloud-agnostic — it applies equally to AKS, EKS, GKE, or any Kubernetes distribution.
Starting with Camunda 8.8, Bitnami subcharts (Elasticsearch, PostgreSQL, Keycloak) are primarily intended for development and testing, regardless of the cloud provider. For production on AKS, Camunda recommends:
See the full guide: Deploy infrastructure with Kubernetes operators
And for context on the Bitnami subchart strategy change: Changes to Camunda Helm Sub-Charts
Camunda provides a complete AKS reference architecture with Terraform modules and Helm deployment guide:
This is an important concern. Here’s the breakdown:
Can you lose data if Elasticsearch is corrupted with Bitnami images?
The risk is not specific to the Bitnami image itself — it’s about how Elasticsearch is deployed and managed:
Why operators or managed services are recommended:
| Capability | Bitnami subchart | ECK Operator | Managed service |
|---|---|---|---|
| Automated backups/snapshots |  Manual |
 Built-in |
Built-in |
| Automated failover | Manual |
|
|
| Rolling upgrades | Manual |
|
|
| CVE patching | Community | Elastic team | Cloud provider |
| Point-in-time recovery | |
Configurable | |
Bottom line: If you decide to use Bitnami Elasticsearch in production, ensure you configure proper snapshot policies (e.g., to Azure Blob Storage) and have a tested restore procedure. But the recommended path is to use either a managed service or the ECK operator, which handles these concerns natively.
Also please note that bitnami charts are deprecated in 8.9 and will be removed in 8.10 (see Camunda 8 Helm Chart Update and the Future of Bitnami Sub-charts | Camunda), in any case, you will need to migrate away from it.
| Topic | Link |
|---|---|
| AKS Terraform setup | Terraform setup |
| AKS Helm install guide | AKS Helm guide |
| Operator-based infrastructure | Deploy with K8s operators |
| External Elasticsearch config | Using external Elasticsearch |
| Bitnami subchart changes blog | Changes to sub-charts |
| Reference architecture | Kubernetes reference architecture |
| Deployment references repo | camunda-deployment-references |
Disclaimer: Responses on this forum are provided on a best-effort basis by community members and Camunda employees. For production-critical decisions or issues, please reach out to Camunda Support through your enterprise support channels.
Hope this helps! Feel free to follow up if you have more specific questions about your AKS setup.
Hi @Anubhav_Jain,
Regarding GKE — this is a separate topic from your original question about Camunda 8.8 Enterprise on AWS/AKS. I’d recommend opening a new thread so it gets proper visibility and doesn’t get buried here.
That said, here’s a quick pointer to get you started:
The key thing you’re looking for is the Ingress setup — this is the cloud-agnostic way to expose Camunda 8 behind a load balancer instead of port-forwarding:
There is also a GKE-specific page covering a Google Cloud Load Balancer health check gotcha:
Please open a dedicated thread with your GKE-specific details (Helm values, errors, etc.) and we can help further there.
Disclaimer: Responses on this forum are provided on a best-effort basis by community members and Camunda employees. For production-critical decisions or issues, please reach out to Camunda Support through your enterprise support channels.
Hope this helps!
Thanks @leiicamundi - We have setup in production which is already provisioned with no DR setup and its kind of standalone setup since the region attributes are not specified during production setup. If i want to setup DR, Do i need to override any attributes in current production setup to make the DR DC2 also insync with Active DC1.
Does Camunda 8.8 supports Active / Active Traffic, both datacenter does workflow executions and ? or it only support Active / Passive.
Active on Region1 and Passive on Region2 where the Zeebe engine, Tasklist, operate, optimize has to be brought down on Region2. need some clarity on this part.
Pl advise @leiicamundi
Please understand that this is a user forum, not an official support channel.
I would recommend opening a support ticket