Public | Automated Build

Last pushed: 19 days ago
Short Description
Drools Workbench
Full Description

Drools Workbench Docker image

JBoss Drools Workbench Docker image.

Table of contents

  • Introduction
  • Usage
  • Users and roles
  • Logging
  • GIT internal repository
  • Extending this image
  • Experimenting
  • Notes
  • Release notes


The image contains:

  • JBoss Wildfly 10.1.0.Final
  • JBoss Drools Workbench 7.0.0.Final

This image provides the JBoss Drools Workbench web application. It's intended to be extended so you can add your custom configurations.

If you don't want to extend this image and you just want to try Drools Workbench, please take a look at the jboss/drools-workbench-showcase:latest Docker image, it contains some default configurations.


To run a container:

docker run -p 8080:8080 -p 8001:8001 -d --name drools-workbench jboss/drools-workbench:latest

Once container starts, you can navigate into the Drools Workbench at:


Users and roles

The application have no users or roles configured, so you cannot not access it by default,

In order to use it, at least you have to create an application user in JBoss Wildfly with role admin.

If you are looking for a Drools Workbench image that does not require to add custom configurations, try our jboss/drools-workbench-showcase:latest Docker image.

If you want to create your custom configuration and users, role, etc, you can take a look at section Extending this image


You can see all logs generated by the standalone binary running:

docker logs [-f] <container_id>

You can attach the container by running:

docker attach <container_id>

The Drools Workbench web application logs can be found inside the container at path:


sudo nsenter -t $(docker inspect --format '{{ .State.Pid }}' $(docker ps -lq)) -m -u -i -n -p -w
-bash-4.2# tail -f /opt/jboss/wildfly/standalone/log/server.log

GIT internal repository

The workbench stores all the project artifacts in an internal GIT repository. By default, the protocol available for accessing the GIT repository is SSH at port 8001.

You can clone the GIT repository by running:

git clone ssh://admin@localhost:8001/system

By default, the GIT repository is created when the application starts for first time at $WORKING_DIR/.niogit, considering $WORKING_DIR as the current directory where the application server is started.

You can specify a custom repository location by setting the following Java system property to your target file system directory:


NOTE: This directory can be shared with your docker host and with another containers using shared volumes when running the container, if you need so.

If necessary you can make GIT repositories available from outside localhost using the following Java system property:

You can set this Java system properties permanent by adding the following lines in your standalone-full.xml file as:

      <!-- Custom repository location. -->
      <property name="org.uberfire.nio.git.dir" value="/home/youruser/some/path"/>
      <!-- Make GIT repositories available from outside localhost. -->
      <property name="" value=""/>

NOTE: Users and password for ssh access are the same that for the web application users defined at the realm files.

Extending this image

You can extend this image and add your custom layers in order to add custom configurations, users, roles, etc.

In order to extend this image, your Dockerfile must inherit from:

FROM jboss/drools-workbench:latest

Configuring Wildfly

  • The Wildfly configuration files are located at /opt/jboss/wildfly/standalone/configuration
  • In this file you can modify all Wildfly's subsystem configurations
  • Drools Workbench requires running Wildfly using full profile, so custom modifications should be done in standalone-full.xml configuration file

Users and roles

  • By default this image does not provide users and roles for Drools Workbench

  • The available roles for Drools Workbench examples are:

      admin       The administrator
      analyst     The analyst
      developer   The developer
      manager     The manager
      user        The end user
      kiemgmt     KIE management user
      Accounting  Accounting role
      PM          Project manager role
      HR          Human resources role
      sales       Sales role
      IT          IT role

These are the steps to create your custom users and roles by using realm files in Widlfly:

1.- Create a realm properties file for users and deploy it in /opt/jboss/wildfly/standalone/configuration:

2.- Create a realm properties file for roles and deploy it in /opt/jboss/wildfly/standalone/configuration:

3.- Modify your standalone-full.xml in order to:

3.1 - In the management section, modify default the security-realm for the ApplicationRealm as:

    <security-realm name="ApplicationRealm">
        <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
        <properties path="" relative-to="jboss.server.config.dir"/>
        <properties path="" relative-to="jboss.server.config.dir"/>

3.2 - In the security subsystem, modify default the other security-domain for as:

    <security-domain name="other" cache-type="default">
        <login-module code="Remoting" flag="optional">
          <module-option name="password-stacking" value="useFirstPass"/>
        <login-module code="RealmDirect" flag="required">
          <module-option name="password-stacking" value="useFirstPass"/>

You can find an example by looking at the Dockerfile for jboss/drools-workbench-showcase:latest image.


To spin up a shell in one of the containers try:

docker run -p 8080:8080 -p 8001:8001 -d --name drools-workbench jboss/drools-workbench:latest /bin/bash

You can then noodle around the container and run stuff & look at files etc.


If the application can't be accessed via browser (http://localhost:8080/drools-wb) please run the container in host network mode. It seems that latest docker versions have some restrictions on the networking side. Using an older daemon version this does not happen.

docker run .... --network="host .."


  • The context path for Drools Workbench web application is drools-wb
  • Drools Workbench version is 7.0.0.Final
  • Drools Workbench requires running JBoss Wildfly using the full server profile
  • No users or roles are configured by default
  • No support for clustering
  • Use of embedded H2 database server by default
  • No support for Wildfly domain mode, just standalone mode
  • This image is not intended to be run on cloud environments such as RedHat OpenShift or Amazon EC2, as it does not meet all the requirements.
  • Please give us your feedback or report a issue at Drools Setup or Drools Usage Google groups.

Release notes


  • Use Wildfly 10.1.0.Final
Docker Pull Command
Source Repository

Comments (10)
25 days ago

Do you have a time frame for when 7.0.0 will be released on docker?

3 months ago

Hi pdread,

We will try to reproduce it.
Did you try "-d -e KIE_DEMO=false --name drools-workbench". In your comment you said: "-d --name -e KIE_DEMO=false drools-workbench" - this is maybe a typo?


4 months ago

Guess should think this through...

the command I used to start it was the same as the one on jboss/drools-workbench page,

docker run -t -i -p 8080:8080 -p 8001:8001 -d --name -e KIE_DEMO=false drools-workbench <image id>

also tried adding --privileged=false



4 months ago

This was on Centos7 if that helps.

4 months ago

Working in an enclave with no internet access. I tried to deploy docker drools-workbench:latest, 6.5.0-Final, showcase, jbpm-workbench and showcase. All had the same problem. Within a few minutes of deployment they would try to redeploy forever. The only way to get any to work was to export the deployments directory and use the -v to push it back into the container on startup. It looked to be a permission problem but not sure.

Any Ideas as to why this happens?



a year ago

Works fine for me.
Try running with -d:
docker run -p 8080:8080 -p 8001:8001 --hostname=drools --privileged=true -it jboss/drools-workbench

Then look at the log in the terminal

20:12:39,938 INFO [org.jboss.errai.bus.server.service.bootstrap.LoadExtensions] (MSC service thread 1-1) searching for errai extensions ...
20:12:40,027 INFO [org.jboss.errai.bus.server.service.bootstrap.OrderedBootstrap] (MSC service thread 1-1) errai bus started.
20:12:40,085 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Registered web context: /drools-wb
20:12:40,268 INFO [] (ServerService Thread Pool -- 31) JBAS018559: Deployed "drools-wb.war" (runtime-name : "drools-wb.war")
20:12:40,354 INFO [] (Controller Boot Thread) JBAS015961: Http management interface listening on
20:12:40,356 INFO [] (Controller Boot Thread) JBAS015951: Admin console listening on
20:12:40,359 INFO [] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 78678ms - Started 721 of 773 services (103 services are lazy, passive or on-demand)
20:12:40,623 INFO [] (EJB default - 9) Completed indexing of default://master@plugins/
20:12:41,442 INFO [] (EJB default - 1) Completed indexing of default://master@datasets/
20:13:27,837 WARN [ErraiMarshalling] (default task-1) static marshallers were not found.
20:13:27,838 WARN [ErraiMarshalling] (default task-1) using dynamic marshallers. dynamic marshallers are designed for development mode testing, and ideally should not be used in production. *

a year ago

In case anyone else is unfamiliar with Wildfly and having trouble figuring out how to add a user, you can just run:

docker exec -ti drools /opt/jboss/wildfly/bin/

To run a script that will walk you through the process of adding a user. You need to enter "admin" when it prompts you for "group".

a year ago

@sidlors, it takes a little while to get going - I had the same issue but if you monitor the output log, its probably still spinning up.

2 years ago

Hey, please I cannot see the errors in your comments... if you cannot paste them here as well, please use some of our googlegroups forums, eg:!forum/drools-usage

2 years ago

doesn't work, :(

this is my container running the image:

but when i trying show drools app