Our contributor jmaster1985 proposed to create and publish Helm charts for Operaton, which will allow to deploy Operaton on Kubernetes.
He requests a new repository for the charts. The repository won’t contain much besides the chart. I think it is good to separate this into its own repository. Also the deployment could be then a workflow in this repository.
Do you think “operaton-helm” should be created? Or other preference to host these charts?
I think it’s a nice idea. I don’t have much experience with Helm, but the ability to spin up an Operaton installation in a K8S cluster quickly might help some people.
Apart from the engine and the (optional) database, what else could be configured? Horizontal scaling comes to mind, any other ideas?
I have created the repository operaton-helm now.
Javad will start working on basic helm charts and instructions.
There is also a repository in the camunda 7 community hub with helm charts, perhaps this can be useful => GitHub - camunda-community-hub/camunda-7-community-helm: Camunda public Kubernetes Helm repo and charts
I pointed him to this repo, he is already aware.
Javad made some progress. With the instructions given in his example repo I was able to install and run Operaton on a Minikube Kubernetes cluster.
We’ll shape that now further to get the charts deployed on ArtifactHUB.io and provide the build pipelines.
Great news! Does it already deploy with postgres?
No, the first test is with h2. But Postgres will be a logical consequence for the next steps. I’ll work on Friday with Javad on these topics in an Open Coding Session.
Today we were able to release the first Helm chart for Operaton. These charts are also published to ArtifactHUB, a popular repository for Helm charts.
The operaton-helm repository contains instructions to install the chart.
If you have set up Minikube on your machine, you could even try it locally with the given instructions.
We have some follow-up stories, esp. enabling and documenting the usage of Operaton with Postgres together by default. There we will work on further.
Hi, thanks for creating it, I love that the barrier of entry gets lower and lower with every addition to the infrastructure 
One thing that sticks out to me is that operaton-bpm as a name deviates a little from all the other packages (maven, docker, distributions) we are building. I’m a little worried that this might introduce some confusion about what the “real” name of the product is in the end (like Camunda did with Camunda BPM, Camunda BPM Platform, Camunda Platform, etc…)
If we have an agreement that this has to change then we do this. Are there opinions on the naming from others, too?
I always remove the „-bpm“ and just use Operaton as name
Ok. Created an issue for this. The “-bpm” is a leftover from adopting the Camunda charts. I will tell Javad to care for it.
