System Requirements and Supported Software
Software
The subsequent sections detail the diverse software dependencies for Flowable products, including the specific versions that are supported.
Java
The Flowable products are built on Java and Spring Boot. Depending on the version, there can be variations in which Java version is needed:
Flowable product version | Java version |
---|---|
3.15+ | 17 or 21 |
3.14 or earlier | 8, 11 or 17 |
Servlet Container
There are many ways of running the Flowable products (as a jar, using Docker or Kubernetes, etc.), but when deploying the WAR files on a Java servlet container, the following compatibility requirements apply:
Flowable product version | Servlet version |
---|---|
3.15+ | 5.0+ (Jakarta EE 9) |
3.14 or earlier | 3.1+ (Java EE 7) |
Concretely for Tomcat, as a prima deployment target for many Flowable customers:
Flowable product version | Tomcat version |
---|---|
3.15+ | Tomcat 10.x |
3.14 or earlier | Tomcat 8.5.x or later, Tomcat 9.x |
This table applies to all Flowable products, with the exception of the Angular-based Design which supports only Tomcat 8.5.x and 9.x (not 10.x), due to the namespace change in Java EE / Jakarta EE.
Database
Flowable uses a relational database to store its data. The following databases are officially supported and tested for all Flowable products:
Database | Database Versions | Flowable Versions |
---|---|---|
Oracle | 11g, 12c, 18c, 19c | |
Oracle | 21 | v3.13.0+ |
PostgreSQL | 10, 11, 12 | |
PostgreSQL | 13, 14 | v3.13.0+ |
MySQL | 5.7, 8 | |
MariaDB | 10.6 | v3.11.0+ |
MSSQL | 2016, 2017, 2019 | |
Azure SQL server | Azure provided | v3.14.0+ |
AWS Aurora | AWS provided | v3.14.0+ |
DB2 | 10.x |
The Flowable products use the standard JDBC (Java Database Connectivity) API of connecting to the relation database, so other database implementations may also work but they are not officially supported or tested by Flowable.
The relational database is one of the most important components when it comes to the performance of Flowable. Make sure to run the database system on adequate hardware resources. See the Performance Tuning Guide for more details.
The database schema is automatically created by the Flowable applications on its initial startup. For this process to work, the application needs schema editing permissions on the database (typically called 'DDL rights' in many database management systems).
It is also possible to manually create or update the database schema, see the dedicated documentation. for more information.
Browser
The following browsers are tested and supported for Flowable Control and Design:
Browser | Version |
---|---|
Google Chrome | 69.0 and later |
For end-user facing applications such as Flowable all popular browsers are supported:
Browser | Version |
---|---|
Google Chrome | 69.0 and later |
Microsoft Internet Explorer | 11 and later |
Mozilla Firefox | 63.0 and later |
Apple Safari | 11.1 and later |
Microsoft Edge | 104 and later |
Build Tools
When using the Flowable spring boot starters in a custom project, explicit build support is provided for the following build tools:
Build Tool | Version |
---|---|
Maven | 3.2+ |
Gradle | 4.x |
Hardware
As Flowable is a generic platform to build custom applications with processes, cases and rules, it's very hard to say exactly what type of server hardware should be used. For instance, a system initiating millions of process instances daily without user interaction has vastly different requirements compared to one with numerous concurrent users completing forms. It's not a straightforward calculation; even a single BPMN process model engaging in intensive CPU-bound tasks can alter the hardware needs significantly.
Therefore, the hardware specifications provided below represent an average customer scenario. Like any software system, it's essential to continuously monitor system resources such as CPU, memory, and disk space. If monitoring indicates sustained high resource utilization, it may be necessary to enhance the system resources allocated to the Flowable environment.
Development
For applications that are limited to a restricted group of users, such as Flowable Control or Design:
CPU | RAM | Disk | |
---|---|---|---|
Minimum | 1 | 2 GB | 10 GB |
Recommended | 2 | 4 GB | 100 GB |
For end-user facing products such as Flowable Work:
CPU | RAM | Disk | |
---|---|---|---|
Minimum | 2 | 8 GB | 20 GB |
Recommended | 4 | 16 - 32 GB | 100 GB |
Production
For applications that are limited to a restricted group of users, such as Flowable Control or Design:
CPU | RAM | Disk | |
---|---|---|---|
Minimum | 2 | 4 GB | 10 GB |
Recommended | 2 | 8 GB | 100 GB |
For end-user facing products such as Flowable Work:
CPU | RAM | Disk (DB persistence) | Disk (File persistence) | |
---|---|---|---|---|
Minimum | 2 | 8 GB | 10 GB | 100 GB |
Recommended | 8 | 32 GB | 100 GB | 1 TB |
The Disk
column makes a distinction between storing files on the file system or in the database. The latter approach is NOT RECOMMENDED as it heavily affects performance and
maintainability of the overall system.
This table is based on a configuration where housekeeping routines are configured and actively removing outdated data. As previously emphasized, it is crucial to monitor system resources in a production environment, and adapt the available resources when needed.
For any Flowable product, it is recommended to maintain a High Availability (HA) setup. This is generally achieved by deploying multiple instances of Flowable (at least two) and placing a load balancer in front of these instances.
Note that certain customers expose Flowable Design to a large group of end users. In this case, the second table applies.
Database
When it comes to the relational database system, we advise following system resources:
CPU | RAM | Disk (no BLOBs) | |
---|---|---|---|
Minimum | 4 | 16 GB | 100 GB |
Recommended | 8 | 32 GB | 100 GB |
If files are persisted as BLOBs in the database, the following specifications are applicable:
CPU | RAM | Disk (with BLOBs) | |
---|---|---|---|
Minimum | 8 | 64 GB | 1 TB |
Recommended | 16 | 128 GB | 1 TB |
In terms of runtime performance, such as executing processes, cases, and similar tasks, the database is frequently the limiting factor. Therefore, enhancing the database with more better or additional system resources typically leads to improved performance for Flowable.
Elasticsearch
Elasticsearch (ES) is required by Flowable Work as an index server for fast data listing and search operations. The index is an optimized copy of the data in the database and might be rebuilt from there if needed. It's also possible to run without Elasticsearch, but this comes with a lower performance for certain inbox queries and no availability of dashboards.
The currently recommended version of Elasticsearch for Flowable Work is 7.x or 8.x
You need at least one Elasticsearch node to be able to startup Flowable Work. However, it is not recommended to operate a productive setup with just one ES node but with at least a cluster of the following nodes:
Type | CPU | RAM | Disk | |
---|---|---|---|---|
Node1 | master/data | 8 | 32 GB | 1 TB |
Node2 | master/data | 8 | 32 GB | 1 TB |
Node3 | master/data | 8 | 32 GB | 1 TB |
General recommendations for clustering Elasticsearch are:
The number of master-eligible nodes should always be odd to avoid split brain problems.
Nodes should have not more than 32 GB of RAM on each node. With higher RAM sizes the garbage collector is not efficient. Set the heap size to a third of the machine RAM (in this case, 10 to 12 GB). It can be set higher but no more than 28 GB.
It is better to have more smaller machines than just a few big machines.
It is inefficient to have master-only nodes if the clusters are small (<10 nodes).
Coordinating-only (HTTP) nodes are only relevant for huge clusters (~32 nodes).
The default number of Shards per Elasticsearch node is 5 and 1 replica. We recommend keeping this value unless you know have reason to change it and understand the consequences.
In addition to Elasticsearch itself you may need a plugin to enable security features such as SSL/TLS encryption and to restricted access. The recommended alternatives are:
X-Pack: Elastic’s official security implementation.
SearchGuard: An alternative plugin with multiple licensing models.
While restricting access to Elasticsearch, keep in mind that Flowable needs to be able to create multiple indices and aliases. It is recommended to assign an index prefix to Flowable.