Running Flowable on Cloud Foundry

Author: Valentin Zickner


Flowable can be deployed in many ways (embedded in an application, microservice or other architecture; standalone as a REST server, etc.) and on many types of environments. One of the core design decisions of Flowable is that we take no opinion on how and where to run it, as we don’t want to impose any architectural hindrance when using Flowable. Of course, for the popular platforms, we make sure there are out-of-the-box integration modules are available.

We’ve seen people running Flowable successfully on a variety of cloud platforms, including AWS, Azure, Google Cloud, … Another popular option is Cloud Foundry and Pivotal’s version (PCF) specifically. Without going into too much detail about Cloud Foundry, the main difference between a ‘regular’ deployment and one on PCF is that everything is a service, even the connection to the database. The benefit of going with this approach is that you can scale your Flowable application easily. However, that means a slightly different way of setting up Flowable and that’s exactly what this post is all about.

Getting started

When you download Flowable from there are already UI applications (based on Spring Boot) included. Flowable ships these applications as war files and the easiest way to get started is to put all of them in a Tomcat webapps folder and start it. For a small introduction to the sample applications please refer to the documentation. A more production-oriented way to deploy them is to create a manifest.yml to deploy all of them to Cloud Foundry.

For pushing the application to Cloud Foundry you can start with a simple manifest to push one application.
A simple manifest to deploy flowable-idm (the Flowable Identity Management application) looks as follows:

With this manifest you simply need to execute cf push to push the flowable idm application to PCF. Please be aware that all hostnames and routes picked in this tutorial might be already taken, so for reproducing the sample you should adapt the hostnames.

With this manifest you will be able to push the flowable-idm application to the domain Since the application has specified a path, you will reach the application at

Advantage of Spring Boot

The Flowable UI applications are using Spring Boot (and there are Spring Boot starters to easily add the Flowable engines to your own application) and Cloud Foundry provides a lot of advantages for Spring Boot applications. Some of the advantages are provided by Cloud Foundry itself, other advantages are provided by the buildpack.

For example, Spring Boot respects environment variables to overwrite configurations. That’s really helpful, as you can specify environment variables with Cloud Foundry, also in your manifest file. The second advantage of Cloud Foundry with Spring Boot is that it provides auto-configuration for data sources. You can buy a data source plan and simply bind the app to it: all other things, the buildpack and Cloud Foundry will do for you.

By default the Flowable applications use an H2 database, which is stored on the host in the home folder (so if you are using Flowable with Tomcat on your local machine, you will find it at ~/flowable-db). For PCF you have several options to use a database, and they are exposed as service providers in the marketplace. One of these providers is, for example, elephantsql, a cloud provider for PostgresSQL databases.

To use it, the only thing you need to do is create a service instance and bind it to the applications. That’s really easy to do, for example with the CF cli:

# Create an elephantsql service with the plan hippo as database flowable-db
cf create-service elephantsql hippo flowable-db

When the service is created, you can bind the database to your application with the following manifest:

By adding the service binding (last two lines), the application is now using a persistent database. The next step is to deploy the remaining applications to take advantage of the full Flowable package.

How the Applications are Integrated

First of all, the IDM application provides us a simple single sign-on interface for the Task, Modeler and Admin interface. It uses cookies, which are shared between the application. It’s not necessary to use the same application server for all the applications, which means we are able to deploy each application separately to Cloud Foundry.

To use the same domain for each application, we can simply change the route to In this case we can reach the applications at exactly the same path. The Java Buildpack avoids the duplicate flowable-idm/flowable-idm in the path. In addition to that, we need to specify a couple of environment variables to ensure that the other applications know where they can find the identity application and all other applications:

We can now create an overall manifest with all combinations to run all these things together.

The Manifest for Deploying all Flowable Apps

The procedure to deploy all apps is now straight-forward, you need to do what we have seen above for the Flowable IDM app for all other applications. Fortunately, Cloud Foundry Manifests provide a way to do that without much duplication.

First of all, you can specify a set of defaults, afterwards you can deploy all apps in one manifest.yml.

The first line is a yaml specific syntax which specifies that we attach everything inside defaults to the placeholder defaults (later on we are able reference it).

And the manifest for the IDM application now looks like:

The manifest for all applications would now look like the following:

Execute `cf push` and afterwards you will have all Flowable applications running in Cloud Foundry.

Note: Flowable 6.3.0 and earlier are using the swagger host `localhost:8080` as default host. In this case, the REST API will not work on other hosts than localhost, fortunately this issue is solved with the current release 6.3.1.


Scaling an application is pretty easy with Cloud Foundry. Either you change the number of instances in the manifest, or you can use the cf cli to do that:

cf scale flowable-rest -i 2

(Note: A new cf push with the manifest will scale down the app again)


For the UI applications, the most tricky part is that you need to configure your Flowable instances to run on the same subdomain to take full advantage of the single-sign on. In addition, you should be aware of the configurations necessary for all applications to be aware of each other. All the rest is straight-forward.

As Flowable provides Spring Boot Applications, it’s very easy to deploy these to Cloud Foundry. When you use the Flowable engines with the Spring Boot starters the process is similar to what’s written above. On top of that, scaling these applications becomes trivial as Flowable has everything built in to make your life as easy as possible!