This content is dedicated to our next version. It is work in progress: its content will evolve until the new version is released.

Before that time, it cannot be considered as official.

Production packaging

Before starting, ensure you have Docker installed on your system.

Build a docker image

Add this Dockerfile in your project to the root of your project:

ARG VERSION=1.0.0-beta.3
ARG BASE=bonitasoft.jfrog.io/docker/bonita-ui-builder
FROM ${BASE}:${VERSION}

# Argument for the folder location on the host where exported JSON applications are stored
ARG WORKSPACE=./workspace/

# Make sure that the dev mode is disabled
ENV BONITA_DEV_MODE=false

# Copy JSON applications inside an internal folder to be imported at startup
COPY ${WORKSPACE} /opt/appsmith/workspace/applications/

EXPOSE 80
EXPOSE 443
ENTRYPOINT [ "/opt/appsmith/entrypoint.sh" ]
HEALTHCHECK --interval=15s --timeout=15s --start-period=45s CMD "/opt/appsmith/healthcheck.sh"
CMD ["/usr/bin/supervisord", "-n"]

Unless specific needs, you do not need to edit variables in this dockerfile.

Save the Dockerfile next to the workspace folder which contains all your exported JSON applications:

..
Dockerfile
workspace/
  myApp.json
  myOtherApps.json
You can change the default workspace folder and use any folder, but in this case, edit the dockerfile’s WORKSPACE build argument with the new folder path.

Default build command

With this command, the image will be built with the default values defined in the Dockerfile.

If you use this command, be sure to have the workspace folder next to the Dockerfile. 
docker build -t <image-name> .

Advanced build

You can override some default values by using the following build arguments:

Args Description Default value

BASE

The base image to use

bonitasoft.jfrog.io/docker/bonita-ui-builder

VERSION

The version of image to use

1.0.0-beta.3

WORKSPACE

The folder containing the apps descriptor

./workspace/

 
docker build --build-arg "BASE=bonitasoft.jfrog.io/docker/bonita-ui-builder" \
             --build-arg "VERSION=1.0.0-beta.3" \
             --build-arg "WORKSPACE=./workspace/" \
             -t <image-name>:<version> .

Configure and manage Bonita healthcheck settings in a production environment

The Bonita healthcheck is a mechanism used to monitor the health and availability of Bonita services in production environments. It periodically checks the status of these services to ensure they are functioning properly, helping to identify issues early and maintain system stability.

Changing the default credentials for the healthcheck is crucial for security. The default values for BONITA_HEALTHCHECK_USER and BONITA_HEALTHCHECK_PASSWORD are publicly known, and failing to update them can expose your healthcheck endpoint to unauthorized access and potential manipulation. Configuring Bonita’s healthcheck in a production environment involves several key steps to ensure both security and functionality.

To manage this, begin by assigning custom values to the credentials through environment variables:

  • BONITA_HEALTHCHECK_USER: Defines a custom username. Example: export BONITA_HEALTHCHECK_USER=my_custom_user

  • BONITA_HEALTHCHECK_PASSWORD: Defines a custom password. Example: export BONITA_HEALTHCHECK_PASSWORD=my_secure_password

Healthcheck configurations are not handled via the UI Builder but are instead managed through environment variables on the server where Bonita is deployed. To fine-tune the healthcheck behavior, adjust the following parameters:

  • BONITA_HEALTHCHECK_RETRY_DELAY: Sets the delay (in milliseconds) between retry attempts, with a default of 5000. Example: export BONITA_HEALTHCHECK_RETRY_DELAY=3000 for a 3-second delay.

  • BONITA_HEALTHCHECK_MAX_ATTEMPTS: Specifies the maximum number of retry attempts, defaulting to 20. Example: export BONITA_HEALTHCHECK_MAX_ATTEMPTS=10 reduces the number of attempts.

These variables should be configured in the server environment where Bonita is deployed. After configuration, verify the healthcheck via a browser to ensure the service is responsive and requires custom credentials. If issues arise, check the environment variables, service status, and logs, and adjust the retry delay and maximum attempts as needed.

By following these steps, you can effectively configure Bonita’s healthcheck to maintain both security and optimal performance in your production environment.

Run the production binary

To run the production docker image, you can use the following command:

docker run --name <container-name> -p 8080:80 \
           -e BONITA_API_URL=<bonita-runtime-url>/bonita/API \
           -e APPSMITH_ENCRYPTION_PASSWORD=<encryption-password> \
           -e APPSMITH_ENCRYPTION_SALT=<encryption-salt> \
           <image-name>:<image-version>

You can override and configure all environment variables.

If you want to test your applications before going into production, instead of using docker run, you can use a docker-compose.yml file in the likes of what was done in the first steps (i.e. with a bonita-ui-proxy image and the docker image built previously).

Please note that currently, only a single container instance is supported, which means multiple instances of UI builder for redundancy are not allowed.