Camunda On STACKIT, Part 1: The First Deploy

In the opening article I explained the reasons why I put Camunda on a European cloud. We still had to figure out what running it on STACKIT means.

Luc Weinbrecht and Sebastian Roseneck of envite had already given us a good starting point at CamundaCon 2026 in Amsterdam. Their deployment brought up Camunda 8.8 in a STACKIT environment and proved that the pieces fit together.

We used their component map as base and moved on to the decisions a platform team would need to make: an existing identity provider, separate environments, and how to operate it.

STACKIT is not one of Camunda's supported cloud providers, so there was no reference architecture where changing some variables produced a deployment. Sebastian and Luc used Camunda's AWS single-region architecture, preserved its shape and implemented each component with STACKIT modules.

Some mappings were direct. Object Storage is based on S3, PostgresFlex is Postgres, and a Gardener extension handles DNS. SKE hands you a bare cluster, which meant ingress, secret sync and TLS certificate automation were missing out of the box.

Consid’s Microsoft Entra tenant was already our authority for users and groups, and because Camunda 8.9 lets each component connect via OIDC (OpenID Connect) to Entra, we could remove the Keycloak broker and database that the POC used. This already spared us some moving parts in the middle to operate.

Camunda’s OIDC setup also supports providers like Okta or Auth0. An existing Keycloak remains a good option when it already brokers SAML or Active Directory, or when other applications depend on its claim and group mappings.

Direct OIDC still needs careful wiring. Each web component needs its own app registration and one helm value pointing to the wring registration sent Web Modeler into a login loop. After fixing that, Camunda Admin denied everybody because our rule compared the group claim for equality even though Entra sends a list. The match had to use contains.

We tested the whole path after that, starting with membership in an Entra group and ending at the authorization Camunda receives. Only members of the mapped group could enter.

Once login worked, we could have cloned the environment and renamed it prod. Instead, we wrote down the job of each one. Test supports developers and validates processes at a lower cost. Prod carries the full product surface and must survive a zone failure, so copying the infrastructure back 1:1 would pay for availability that test doesn’t need.

On STACKIT, each environment is a project. The project is the main boundary for resource ownership, quotas and access control. For the first local applies, I created a project-scoped service account per environment and authenticated Terraform with a service-account key on my laptop.

STACKIT has no AWS AssumeRole-style impersonation. When we later moved the applies to GitHub Actions, Identity Federation let each job exchange its GitHub OIDC token for a short-lived STACKIT access token. Part 2 explains that transition.

Camunda distributes process instances across so called partitions. Each instance stays on one partition for its entire lifetime. Every partition has one leader that processes commands and followers that copy its event log. Similar to Kafka. With a replication factor of three, the partition exists on three brokers: one leader and two followers. If the leader fails, a follower can take over. If the partition loses its majority of brokers, processing stops until quorum is restored. When setting up Camunda, one has to decide how many brokers, partitions and replication the platform needs. They affect parallelism and fail safety.

Cloud providers normally offer availability zones (AZs) in each region. Each AZ represents a physical different server, rack or even data center. In a Kubernetes cluster we can place nodes of the same cluster in different AZs. This prevents a full outage in a cluster if one AZ goes down. We also make use of the AZs to ensure high availability.

Test is deliberately lean: A single broker setup (1 broker on 1 node, in 1 AZ running 1 partition). Camunda 8.9 uses PostgreSQL for secondary storage there, which removes managed OpenSearch, Optimize and the monitoring stack from that environment. It runs in one zone without data-store replicas. Developers still get a shared Camunda installation, while avoiding paying for a miniature copy of every prod service.

Prod carries the full load: A triple broker setup (3 brokers on 3 nodes, in 3 AZs running 3 partitions, replicated over all 3 brokers), OpenSearch for secondary storage, Optimize for process analytics, and monitoring with Prometheus. Three availability zones and replicated data stores keep the platform running when one zone fails.

Both environments run the same node type, a g2i.8 (general purpose, 8 vCPU Intel Icelake, 32 GiB RAM). Everything else differs by design: secondary storage, zones, node count, Optimize and monitoring. STACKIT adds new options from time to time, as of writing this, there is already a newer generation g3i.8 (Intel Emerald Rapid) available which is slightly more expensive, but we resisted the temptation to upgrade.

Storage was the less visible difference. STACKIT defaults block volumes to 500 IOPS (input/output operations per second); the AWS reference assumes a 3.000-IOPS gp3 disk, while Zeebe expects fast SSD storage with 1.000 IOPS as the floor. Reusing the reference volume sizes without checking the storage class would have left the write-ahead log below that minimum, and Kubernetes would have reported nothing wrong.

We assigned IOPS based on workload: 2.000 for Zeebe’s log and snapshots, 1.000 for PostgreSQL, and 500 for node root disks that carry the OS and logs. Test and prod use the same tiers so their behavior stays comparable; only the volume sizes change.

The Helm edit took only minutes. Deciding what each value had to achieve took most of the time. When we finished, Entra logins worked and process instances completed in test and prod. That was enough to call it a real deployment.

We added a small landing page so nobody had to keep a list of application URLs and client endpoints. It brings Operate, Tasklist, Web Modeler, Console, Admin, Management Identity, Optimize (prod), Grafana (prod) and ArgoCD together in one place. Entra and the authorization rules behind each application still decide what a user can open.

My laptop still held credentials. Neither environment had a recovery path, the network trusted far too much, and the sizing rested on arithmetic rather than a load test.

We tackle the operational gaps first. Part 2 turns our setup into a real platform, then Part 3 narrows the network trust. Part 4 looks at what the coding agent contributed and where it failed. In Part 5 we put the platform under load, and Part 6 closes with the operating model, the bill and the verdict.