Suggest architecture for multiple teams

Hello, I am new to Camunda and I am evaluating it. I would like to better understand how is supposed to be used in an enterprise scenario of multiple teams, with multiple projects and multiple departments.

Let’s say each team develops an app, so we have a total of 20 apps that needs a workflow engine.
Each team is an agile team with full Devops control.

How is Camunda supposed to be configured?

  • one unique instance running 20 “projects” ?
  • 20 separate Camunda instances, 1 for each project ?
  • 20 tenants ?
  • 20 “process engines” ?
  • something else?

The goal would be to follow the best practice for Camunda, but at the same time give the most flexibility and control to each team.

Hi Pastine,

This is very much tricky scenario. There were many question that need to be asked before we decide how many instance will be running and what will be multi-tenant architecture looks like,

Question will be like:-
a) How many business critical processes you are planning to run. Does it need 24X7 or you have a bandwidth to give time for upgrade?
b) How many request per process you are expecting approximately. In case of high traffic the configuration will be little different
c) I would also try to find out Data sharing between processes. Will there be any regulation that stops you to share data between the processes. If yes then I would definitely think on Multitenancy scenario
d) Other questions were like how many process you have where process is waiting for external activity to respond, Is there any long running process
e) Are you thinking to run Camunda on cloud or you are thinking to run on prem? What is the disaster recovery strategy you are looking for? What is RTO and RPO you are looking for.
f) I would also have a sneak peek in the financial part of infrastructure because have 20 instance of Camunda mean more historical data got generated and in case you need to keep it for long then you definitely incur cost around it.

If you can provide some answers to above scenarios then we would love to give you generic infrastructure solution


Any of these are ways that Camunda is supposed to be configured. It’s a somewhat “you do you” system.

That said, I would suggest that you look towards the 20 separate Camunda instances options.
This will allow all the DevOps teams to work independently, upgrade the servers as needed, etc.

It will also enforce data contracts between processes.
It also sets you on a good path for migrating one at a time to C8.

The big reason to go to 1 instance with 20 projects would be if the underlying supporting teams have workflows that move between them automatically and you don’t want to have data contracts and messaging between them (think Employee Time Off process: Employee requests time off to boss, boss approves it, the work should automatically go to payroll without needed a message to change the pay for that day)

That all said… I’ll also caution you not to follow my advice, since I mainly use Camunda to document processes, not run them.