BAMOE Canvas enables validation and testing of models in a live environment (Kubernetes or OpenShift) through the Dev Deployments feature. Dev Deployments allow users to validate their models without needing to understand the full build and deployment pipeline, bridging the gap between modeling and runtime testing, and enable faster feedback loops.

Dev deployments require multiple components to function together, namely BAMOE Canvas, the Kubernetes/OpenShift cluster, container images, and the upload service.

Connecting to Cloud Providers

Before creating any Dev Deployment, establish a Kubernetes or OpenShift cluster connection to BAMOE Canvas. During connection, BAMOE Canvas automatically fetches all possible API endpoints and maps them to their corresponding Kubernetes resource names, enabling it to apply and manage different resources (Deployments, Ingresses, Routes, Services, etc.). For instructions on connecting to Kubernetes or OpenShift cluster, see Connecting to Git and Cloud providers.

This connection enables the deployment of all Decisions, Workflows, and complete Java projects for development purposes only. Within any open project, you can select the connected account intended for the Dev Deployment and confirm the selection.

Deploying from BAMOE Canvas

After connecting a cluster, deploy your project by opening it in BAMOE Canvas and clicking the Deploy button in the toolbar.

kubernetes deploy
Figure 1. Deploy dropdown for a project on BAMOE Canvas

After clicking Deploy, you will be presented with options for available types of deployment (see Deployment options).

deploy page
Figure 2. Deploy page

Select your deployment option and and click Confirm to start the deployment. You can also configure any available parameters displayed in the dialog (e.g., Docker image, container port, or enable/disable optional components like DMN Form Webapp). For the list of available tokens, see Dev Deployment tokens.

Deployment options

You can either use the default deployment option or you can use the customised deployment option.

If a custom dev deployment is set—either through an accelerator or if you create your own, then only that custom option will be displayed. The default options (Quarkus Blank App and Custom Image) only show up if there isn’t a custom dev deployment option defined.

Quarkus Blank App Dev Deployment option

Quarkus Blank App deployment option is a built-in default deployment options that vary based on the target platform:

Target platform Description

OpenShift

Deploys a pre-built Quarkus container image with an upload service. Supports an optional DMN Form Webapp sidecar for testing DMN models.

Kubernetes

Uses Kubernetes Ingress resources instead of OpenShift Routes. Otherwise identical to the OpenShift variant.
deployment option quarkus blank app
Figure 3. Quarkus Blank App deployment option

This option provides the default and simplest deployment approach with the following requirements:

  • The project should contain only Decision (DMN) and Workflow (BPMN) files. BAMOE Canvas ignores all other files.

  • The deployment fails if any file contains errors.

This option uses a pre-defined Quarkus project template that includes all dependencies necessary to run a Decision or Workflow. It runs on a container image with Java and Maven, as well as the Dev Deployment Upload Service.

BAMOE Canvas shows a parameter that gives you the option to Include DMN Form Webapp. This sidecar container contains a webapp that parses the backend service API and dynamically generates a form with all of the Decisions inputs and outputs, allowing you to fill the inputs and simulate different scenarios.

form
Figure 4. Dev Deployment application for a Decision created from BAMOE Canvas

You can switch between different Decisions using the dropdown in the top-right corner and access the Swagger UI through the kebab menu.

Note
 The DMN Form Webapp works only for Decisions. Handle Workflows directly via the API or Dev UIs.

Images used in the deployment:

Custom Image Dev Deployment option

Custom Image deployment option is a built-in default deployment options that vary based on the target platform:

Option Name Description

OpenShift

Deploys a custom Docker image with configurable container port and startup command. Suitable for full Java projects (Quarkus or Spring Boot).

Kubernetes

Uses Kubernetes Ingress resources instead of OpenShift Routes. Otherwise identical to the OpenShift variant.
deployment option custom image
Figure 5. Custom Image deployment option

This option provides maximum configurability, allowing users to specify custom Docker images, container ports, and startup commands. Use this option for complete Java projects (Quarkus or Spring Boot).

This combination of parameters makes it a highly flexible option, but should be used with care and follow a few requirements:

  • The deployed image must include an instance of the Dev Deployment Upload Service running on startup, with the service binary available in the PATH (BAMOE Canvas executes the Command parameter after the Dev Deployment Upload Service finishes: dev-deployment-upload-service && <CUSTOM_COMMAND>)

  • The Dev Deployment Upload Service must run on the port defined by the Container Port parameter

  • The deployment should expose an HTTP 200 response from the <DEPLOYMENT_URL>/q/health endpoint to verify deployment success (The deployment proceeds without this endpoint, but BAMOE Canvas cannot verify success)

Images used in the deployment:

Note
 This image is used by default, but it can be changed to any other available image. If using another image, it is recommended creating it based off of quay.io/bamoe/canvas-dev-deployment-base:9.5.0-ibm-0005. For informatio, see Creating a custom Dev Deployment image.

Dev Deployment option via User-defined YAMLs file

Using the custom Dev Deployment options via user-defined YAMLs enable you to create deployment configurations tailored to specific use cases and Kubernetes and OpenShift environments. You can define custom deployment configurations using standard Kubernetes YAML manifests, JSON Patches, and descriptor files. This capability provides complete control over application deployment, including:

  • Defining custom Kubernetes resource manifests (Deployments, Services, Routes, Ingresses, etc.)

  • Applying JSON Patches to modify manifests dynamically at deploy time

  • Configuring parameters for adjustment during deployment creation

  • Using token interpolation with recursive JSON Path expressions to reference dynamic values

  • Deploying to Kubernetes environments not officially supported by default options

  • Using custom container images or deployment configurations

  • Defining specific resource requirements, environment variables, or volume mounts

  • Supporting multiple deployment scenarios within the same project

  • Bundling Dev Deployment options with Accelerators for project reuse

For more information, see Customizing Dev Deployment options via user-defined YAMLs.

Dev Deployment tokens

tokens
Figure 6. Dev Deployment tokens list

Dev Deployment tokens are "variables" that can be used inside the parameters on the Dev Deployment modal. They are also used inside the resource YAMLs applied to the Kubernetes/OpenShift cluster (see the topic below). These tokens are then interpolated during the deployment, replacing their strings with a runtime value.

For example,

devDeployment: {
  labels: {
    createdBy: "tools.kie.org/created-by",
    partOf: "tools.kie.org/part-of",
 },
  annotations: {
    workspaceId: "tools.kie.org/workspace-id",
    workspaceName: "tools.kie.org/workspace-name",
 },
  uniqueName: string,
  uploadService: {
    apiKey: string,
 },
  workspace: {
    id: string,
    name: string,
 },
  kubernetes: {
    namespace: string,
 },
},
Note
 Some tokens are pre-defined, and others are generated during runtime (like uniqueName and uploadService.apiKey).

These tokens are referenced in the YAML resources using the following notation ${{ $.varPath.varName }}. Here are some examples from the tokens above:

  • ${{ devDeployment.labels.createdBy }}

  • ${{ devDeployment.annotations.workspaceId }}

  • ${{ devDeployment.uniqueName }}

  • ${{ devDeployment.kubernetes.namespace }}

Resources requirements for Dev Deployment options

The Kubernetes/OpenShift resources created by a Dev Deployment must have specific metadata so that BAMOE Canvas can list and manage these resources. BAMOE Canvas applies this metadata using two different mechanisms:

Automatically applied labels and annotations

BAMOE Canvas automatically force-adds the following labels and annotations to every Kubernetes resource through JSON Patch, regardless of the deployment option (default or custom):

metadata:
  labels:
    \${{ devDeployment.labels.createdBy }}: kie-tools
    \${{ devDeployment.labels.partOf }}: \${{ devDeployment.uniqueName }}
  annotations:
    \${{ devDeployment.annotations.workspaceId }}: \${{ devDeployment.workspace.id }}
    \${{ devDeployment.annotations.workspaceName }}: \${{ devDeployment.workspace.name }}

  • The createdBy label identifies resources created by BAMOE Canvas and always has the value kie-tools.

  • The partOf label groups all resources related to a single deployment.

  • The workspaceId and workspaceName annotations match a deployment to a workspace.

These labels and annotations are NOT configurable and are automatically stamped on every resource by BAMOE Canvas code.

Token-interpolated name and namespace

The resource name and namespace are set through token interpolation in the manifest YAML:

metadata:
  name: \${{ devDeployment.uniqueName }}
  namespace: \${{ devDeployment.kubernetes.namespace }}

  • The name is how the deployment is identified across the board.

  • The namespace is where the deployment should be created in the cluster and should be the same configured in the connected account.

Field Default Dev Deployment Custom Dev Deployment

metadata.name

Always set (all default manifests include the token)

Not guaranteed (custom author must include the token)

metadata.namespace

Always set (all default manifests include the token)

Not guaranteed (custom author must include the token)
Note
 For custom Dev Deployments, you must include the name and namespace tokens in your manifest YAML to ensure proper deployment identification and management.

Post Deployment

Upon confirmation of the Dev Deployment, the Dev Deployments dropdown will open, displaying all active deployments with status icons:

  • Spinning icon — Deployment in progress (resources being created, application starting up)

  • Green checkmark — Deployment is up and healthy

  • Red circle — Deployment encountered an error (health check failed)

  • Warning triangle — Deployment is down (no running replicas)

kubernetes waiting done
Figure 7. Dev Deployments dropdown demonstrating the deployment process

Click on a deployment to open the deployed application in a new browser tab.

After approximately 30 seconds, a green checkmark appears next to the Dev Deployment. When the deployment includes the Include DMN Form Webapp option, selecting an item in the list navigates to the webapp form for decisions. Otherwise, it navigates to the Swagger UI for the application.

Note
 Dev Deployments are immutable; therefore, if an error occurs or a change is required, a new Dev Deployment must be created. They can easily be deleted from the Dev Deployments dropdown.

Deleting Deployments

To delete a deployment, hover over it in the Dev Deployments dropdown and click the trash icon. To delete all deployments at once, click Delete all at the bottom of the dropdown.

Note
 Dev Deployments are immutable. When an error occurs or a change is required, create a new Dev Deployment.
deleting deployments
Figure 8. Deleting Deployments

How Dev Deployments Work

When you click Confirm, BAMOE Canvas executes the following steps:

  1. BAMOE Canvas packages all workspace files into a zip file (ignoring .git directories).

  2. BAMOE Canvas loads the chosen deployment option (default or custom) YAML files and modifies them dynamically:

    • Applies required patches to set BAMOE Canvas labels, annotations, and resource names.

    • Applies patches related to parameters set in the deployment modal (each parameter corresponds to a set of patches and tokens).

    • Interpolates all tokens with their corresponding values, including parameters.

    • Splits YAML files into multiple YAMLs, creating one per resource kind.

  3. Using the Kubernetes resource name and the list of saved API endpoints, BAMOE Canvas makes requests to the cluster to apply each resource YAML, saving the returned resource ID locally for later reference.

  4. The cluster initiates Pods, Services, and other resources. Simultaneously, BAMOE Canvas polls the cluster to determine whether the Deployment is healthy and ready, first by fetching the Deployment resource status, then, when healthy, polling the Dev Deployment Upload Service status to check readiness for upload.

    • When the Deployment resource is not healthy, BAMOE Canvas continues polling its status whenever it lists Kubernetes resources and displays an error icon if the Deployment errors out or a loading icon if the Deployment is pending.

    • When the Deployment is healthy, BAMOE Canvas starts polling the Dev Deployment Upload Service running inside the deployed containers to check readiness for upload.

    • When the Dev Deployment Upload Service fails to respond after a pre-defined timeout, the Dev Deployment fails and BAMOE Canvas updates it with an error icon.

  5. After the Dev Deployment Upload Service reaches "READY" status, BAMOE Canvas uploads the zip file generated in Step 1 to the upload service.

  6. The Dev Deployment Upload Service receives the zip file and extracts it to the defined path (set using configured environment variables on the container). After extraction completes, the service ends with status code 0 and calls the following defined command (usually mvn quarkus:dev or whatever the Custom Image option parameter defines).

  7. A Quarkus application starts loading inside the container, while BAMOE Canvas polls the container to check Quarkus app readiness.

  8. When Quarkus finishes loading and polling succeeds, BAMOE Canvas updates the Dev Deployment icon to a success icon and provides a link to the Dev Deployment endpoint, which can be either:

    • The Quarkus Swagger UI, when deployed via Custom Image or Quarkus Blank App options without the DMN Form Webapp parameter.

    • The DMN Form Webapp when the checkbox for it was checked during deployment creation.

  9. Users interact with the Dev Deployment to test and validate decisions and processes. After completion, delete a deployment by hovering over it in the Dev Deployments list and clicking the trash icon.