If you don't have special architecture requirements, we recommend using SaaS following the proposed greenfield stack.
This best practice targets Camunda Platform 8 only! If you look for Camunda Platform 7, please refer to Deciding about your Camunda 7 stack.
The greenfield stack
We like to give one greenfield stack recommendation, which is the stack you can simply use if there is no reason against it. And while we went through long and detailed discussions to come to this recommendation, it doesn't mean that it is necessarily superior to alternative stacks. You can still feel confident if you go down another route (see below for alternative options).
The Java greenfield stack
Use the following stack:
Use Camunda Platform 8 SaaS and create a cluster there
Use Maven as a build tool.
Use your favorite IDE, for example Visual Studio Code, IntelliJ or Eclipse.
Use Open JDK 17 as Java runtime.
Model the processes with the Camunda Modeler.
Add your process models and all Java code to the project.
To run the process application in production:
- Run the process application by copying the
jarfile to the server and start it with
java -jar YourProcessApplication.jar. This is most often done via Docker.
See our example application.
We decided on this stack for the following reasons:
- All components are open source and easily available.
- SaaS is the easiest way to consume capabilities like a workflow engine.
- Spring Boot is currently the most adopted way of building Java applications.
- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud.
Take a look at the getting started guide for microservices orchestration or follow the instructions in Spring Zeebe to get started.
You can develop process solutions as decribed with Java above also in any other programming language. Simply use the existing language clients / SDKs for doing this.
Customize your stack
Running Camunda Platform 8 self-managed
You can also run Camunda Platform 8 self-managed on your own Kubernetes cluster. Details can be found in the docs.
While there exists a Docker Compose configuration to run Camunda Cload locally, this is not meant to be used for production, but rather to quickly startup compenents on a developer machine to be able to play around.
Modeling for executable processes
We distinguish two different roles modeling in BPM projects:
Process developers develop an executable process implementation. Process developers implementing solutions with Camunda must use Camunda Modeler to model executable processes, edit technical attributes, and manage and version (e.g. in Git or SVN) the resulting (XML) files as part of the development project.
Process analysts capture the operational know how about a process. For this part of the work, it is possible to use a different tool than Camunda Modeler.
|Camunda Modeler||Third-Party Modeler (BPMN Standard Compliant)||Third-Party Modeler (Non-Compliant to Standard)|
|Roundtrip in between process analysts and developers possible||✔||✔ (Carefully check level of BPMN compliance - the Model Interchange Working Group can serve as a first starting point|
|Use for process analysts||✔||✔|
|Use for process developers||✔|
|Use when||You do not have a BPMN standard compliant modeling tool already rolled out.||You already rolled out a BPMN tool with a standard compliancy sufficient for roundtrip.||Try to avoid|