In the last article in this series, I want to give you an overview of our learnings and what we eventually paid during development. We can’t answer every question yet, but we are very close to a production-ready platform that holds the load a customer expects.
To make it short: One day of STACKIT billing across our three projects came to 70 €. Prod accounted for 51 €, test for 16 € and shared infrastructure for 3 €.
That is only the provider bill. The people who build and run the platform cost more than the infrastructure does. We did not do any of this to save money.
What Held
I would use Camunda’s AWS single-region reference again. STACKIT publishes no equivalent blueprint, so we mapped the published architecture component by component, and that mapping is where every major prod choice came from, including the three brokers spread across three availability zones.
The two-repository split and keyless pipeline from Part 2 also held up. Every change that reached a cluster passed a review with a person’s name on it. Infrastructure and platform changes kept separate permissions and separate failure boundaries.
Above the infrastructure layer we wrote exactly one STACKIT-specific line: a load-balancer annotation that turns on PROXY protocol. Everything else is standard charts, manifests and operators. Nothing in the Camunda layer knows which cloud it sits on.
Decision records, a findings log and runbooks kept earlier work available to the next person, and to the next agent session. A hand-maintained set of numbered Markdown files stops working once the platform is live and several people are filing findings at once, so we froze both registers and moved new work into tracked GitHub issues.
Part 5 put a number on the sizing: roughly 72 to 80 accepted process instances per second on the current hardware.
What Hurt
STACKIT’s managed Kubernetes gives you a cluster and stops there. Ingress, certificate automation and secret synchronization were ours to install, and then ours to keep running, including their upgrades and their alerts. On Camunda’s reference cloud two of those three are managed services and the third is an add-on. That work carries on after go-live, so price it in. It is the warning I would give first.
Managed OpenSearch came with a narrower limit. Its application credential has no index-lifecycle permissions, and with Camunda’s retention enabled the engine never finished starting up. We turned native retention off and scheduled a job to prune dated indices instead.
In August, prod’s search cluster was renamed outside Terraform. The provider treats that name as immutable, so the next plan proposed destroying the secondary store and building a new one. Destroy protection stopped the apply. I shipped a temporary name override so the rest of the prod changes could go out, opened a ticket, and removed the override once STACKIT put the original name back.
Ingress ate several days. spec.loadBalancerSourceRanges does enforce the L4 restriction, so the source gate holds at layer 4. Separating the UI audience from the Zeebe audience needs L7 rules on top of that, and those rules only work when the PROXY protocol chain in front of them is correct. Part 3 has the detail, together with our decision to postpone inbound connectors and the broad HTTPS egress that outbound connectors still need.
Entra was worse. One audience value in the wrong field produced a login loop, and a group-mapping rule then used equality against a claim that arrives as a list. We only found them by walking the whole authentication path, from directory membership through to Camunda authorization.
There are few Camunda-on-STACKIT examples to copy, and some provider differences only showed up under load. We upgraded the search plan, and then found an exporter setting that doubled capacity on the hardware we already had. Part 5 tells that story. The bigger plan is independently justified now for its heap and shard budget, and we still bought it in the wrong order: capacity problems come with a bill attached, and the order you investigate them in decides how big it is.
What It Costs
The prod bill shows where the money went.
Test came to 15,80 € for the same platform shape at smaller sizes. Shared infrastructure cost 3,20 €, and almost all of that is one CI runner on a fixed public address. The managed services are gated by address, so a changed IP would lock that runner out of every one of them. Three euros a day is the floor you cannot easily design away.
We hibernate the test and prod clusters outside working hours. On the measured day that put 39 node-hours on prod’s bill instead of 72, and 13 on test’s instead of 24. The infra project has no cluster to hibernate, so its 3,20 € lands every day of the month, weekends included.
August came to 1.240 € for prod, and that is what we actually paid. It is not a rate. We swapped resources in the first week and woke the clusters when there was work rather than to a timetable, so the nodes billed 426 hours across the three of them over the whole month. Take the month as evidence that hibernation works, and take the numbers that follow from one regular day instead.
So take one regular day, the one in the table above, where both clusters woke at 07:00 and slept at 20:00. Both projects run the same machine type at 0,41 € per node-hour, and compute is the only line the schedule moves: around the clock, prod’s three nodes take it from 15,96 € to 29,46 € a day and test’s single node from 5,32 € to 9,82 €. Everything else on the bill, the replicated stores and the storage and the cluster management, holds at its measured level either way, which is why a weekend with both clusters asleep still costs 49,05 € across the three projects. Scaling that one day two ways gives the months below, both of them arithmetic rather than a billed month: the left column keeps the hibernation schedule, the right one never lets the nodes sleep. Put customer processes on this platform and the right column is your bill.
Three services account for 75 % of the prod bill: the nodes, the search cluster and the database. Add cluster management and the share reaches 85 %. All the block storage together is 13 %. The load balancer, the public IPs, DNS, the secret store and object storage come to 1,4 % between them, which is noise. The two replicated data stores cost more than all the compute put together. That is what it costs to let prod survive the loss of an availability zone, and it is why test’s day costs less than a third of prod’s.
A full month sharpens it. In August the search cluster cost 376,53 €, the database 280,81 € and the nodes 174,30 €, so the two replicated stores came to nearly four times the compute rather than the 1,4 times the single day showed. Hibernation is why: the stores bill every hour and the nodes do not.
The larger cost is people. I built this platform with an agent, which is Part 4’s story. Running it takes two, because nobody is on call every day of the year.
Camunda charges two things: a fixed amount per root process instance, and the infrastructure it runs on. Self-managing changes only the second one. You still owe the per-instance amount, and in place of Camunda’s infrastructure component, which is billed at roughly cost recovery and lands below what we pay for prod, you carry your own bill and the people who run it. There is no list price to check that against, because agreements get negotiated around volume and need. Sovereign self-managed prod costs more either way, on the bill and on the team. For an organization that needs EU legal sovereignty, SaaS on US infrastructure is not an option, whatever its price.
Running It
Someone still has to run it. Our runbooks cover credential rotation per credential, an identity-provider outage, a failed apply against a cluster that is not awake, restoring either environment, an unstuck GitOps sync, rebalancing partition leaders, and the day the office address changes and every gate rejects at once. You read them after the build team has moved on, or while something is already broken.
We run the monitoring stack ourselves, the kube-prometheus-stack with Loki for logs, so the alerts and dashboards are ours to keep working. Buying STACKIT’s managed observability instead would have added another 200 € to the monthly bill.
Keeping the platform current is the piece we haven’t automated yet. An agent pins the version it learned, so a chart or provider release that has already been superseded can arrive in a pull request looking current, and a reviewer is a poor detector for that. We plan to put Renovate on both repositories and let a bot watch upstream releases.
Backups run nightly into object storage. Both environments have been restored end to end, and the data came back.
The Verdict
The repositories rebuild both environments, policy checks guard the exposed paths, and Part 5 found the current ceiling. A team of two can run this platform today. That is the bar I would set before calling something a platform.
STACKIT carries Camunda and its process data with no US operator underneath. Two dependencies sit outside that data path: Entra for identity and GitHub for code hosting. The capacity number belongs to our synthetic process shape, so your own process mix still has to be measured.
My verdict: it makes sense when legal sovereignty and less dependence on American hyper-scalers are real requirements. You control where the platform and the process data live, and you carry the higher infrastructure bill and the team that comes with it. Take the requirement away and I would struggle to justify either.
For this build, sovereignty means about 2.650 € a month of projected infrastructure across the three projects, the people who keep it running, and the per-instance fee you would owe Camunda either way.