BAMOE Canvas Dev Deployments offer extensive customization capabilities to accommodate diverse project requirements and deployment scenarios. You can define deployment configurations with fine-grained control over Kubernetes or OpenShift resources, providing the flexibility to tailor deployments to your exact specifications.

Creating a custom BAMOE Canvas Dev Deployment image

For convenience, one of the deployment options in BAMOE Canvas allows the user to input a custom image and a custom command to start the application once the upload is complete.

BAMOE Canvas expects a few things from a custom image to guarantee it can upload the project assets and manage the deployment on the Kubernetes/OpenShift cluster.

Requirements:

  1. Have the Dev Deployment Upload Service binary installed and available globally, as BAMOE Canvas will override the default command from your image with dev-deployment-upload-service && <CUSTOM_COMMAND> (<CUSTOM_COMMAND> is defined in the UI when deploying the image);

  2. The image must expose port 8080, and all services running on the container should listen to this port. This includes the dev-deployment-upload-service, which can be configured by setting the DEV_DEPLOYMENT__UPLOAD_SERVICE_PORT environment variable to 8080;

  3. After BAMOE Canvas uploads the assets to the dev-deployment-upload-service listening inside your image, and the service finishes unzipping and placing the files in the configured directory, it is expected that an application will start and provide an endpoint /q/health that responds with HTTP 200 so that BAMOE Canvas can acknowledge that the application started successfully and is running;

Example 1: Using the BAMOE Canvas Dev Deployment Base image

The quay.io/bamoe/canvas-dev-deployment-base:9.5.0-ibm-0005 image is used as a base since it already has the dev-deployment-upload-service pre-configured.

Containerfile

# Set the base image with Java 17, Maven, and the dev-deployment-upload-service.
FROM quay.io/bamoe/canvas-dev-deployment-base:9.5.0-ibm-0005

# Start as root to get elevated access.
USER root

# Configure the dev-deployment-upload-service:
# Our extraction directory is /src/main/resources inside our Quarkus app, but it may differ for your application.
# This is the path where all files from your BAMOE Canvas project (including .dmn, .bpmn, etc) will be extracted to after upload.
ENV DEV_DEPLOYMENT__UPLOAD_SERVICE_EXTRACT_TO_DIR=$HOME_PATH/app/src/main/resources
ENV DEV_DEPLOYMENT__UPLOAD_SERVICE_PORT=8080

# Copy your Quarkus app folder with everything needed to run a Quarkus app with .dmn and .bpmn resources,
# setting the permissions/ownership for the target user.
COPY --chown=$USER_ID:$USER_ID ./my-quarkus-app $HOME_PATH/app/

# Expose port 8080
EXPOSE 8080

# Set to a user different than root (in this case, user ID 185, coming from our base image).
USER $USER_ID

# Set the entrypoint to run bash.
ENTRYPOINT ["/bin/bash", "-c"]

# The CMD directive is unnecessary since BAMOE Canvas will overwrite it.

Example 2: Using an OpenJDK base image

Using the icr.io/appcafe/ibm-semeru-runtimes:open-17-jdk-ubi-minimal image as a base, create a Dev Deployment image that follows all the requirements listed above and results in a Quarkus app running with the project files uploaded by BAMOE Canvas.

Containerfile

# Set the base image with Java 17 and Maven.
FROM icr.io/appcafe/ibm-semeru-runtimes:open-17-jdk-ubi-minimal

# Arguments and environment variables to define our user and home path.
# Obs.: This can vary according to your base image.
ARG USER_ID_ARG=185
ARG HOME_PATH_ARG=$HOME
ENV USER_ID=${USER_ID_ARG}
ENV HOME_PATH=${HOME_PATH_ARG}

# Start as root to install all required dependencies.
USER root

# Configure the dev-deployment-upload-service:
# Our extraction directory is /src/main/resources inside our Quarkus app, but it may differ for your application.
# This is the path where all files from your BAMOE Canvas project (including .dmn, .bpmn, etc) will be extracted to after upload.
ENV DEV_DEPLOYMENT__UPLOAD_SERVICE_EXTRACT_TO_DIR=$HOME_PATH/app/src/main/resources
ENV DEV_DEPLOYMENT__UPLOAD_SERVICE_PORT=8080

# Install `tar` and `gzip` packages, as they are required by the dev-deployment-upload-service to unzip the uploaded files.
RUN microdnf --disableplugin=subscription-manager install -y tar gzip \
 && microdnf --disableplugin=subscription-manager clean all

# Create the user home, tmp, and .m2 paths to be used by our application.
# Setting the permission to 777 is important so users can access and modify these files during runtime.
RUN mkdir -p -m 777 $HOME_PATH/app \
 && mkdir -p -m 777 /tmp/app \
 && mkdir -p -m 777 /.m2

# Copy the dev-deployment-upload-service binary to the /usr/local/bin directory, making it globally available.
# NOTE: In this base image /usr/local/bin is included in the PATH environment variable,
# if you are using a different one, make sure the binary is globally accessible.
COPY dev-deployment-upload-service /usr/local/bin

# Another round of changing permissions and ownership of directories.
# This is important because our Quarkus app will make changes to files during runtime.
RUN chgrp -R 0 $HOME_PATH/app && \
 chmod -R 777 $HOME_PATH/app && \
 chgrp -R 0 /.m2 && \
 chmod -R 777 /.m2

# Change the work directory to our app path.
WORKDIR $HOME_PATH/app/

# Copy your Quarkus app folder with everything needed to run a Quarkus app with .dmn and .bpmn resources,
# setting the permissions/ownership for the target user.
COPY --chown=$USER_ID:$USER_ID ./my-quarkus-app $HOME_PATH/app/

# Expose port 8080
EXPOSE 8080

# Set to a user different than root (in this case, user ID 185, but it may vary depending on your base image).
USER $USER_ID

# Set the entrypoint to run bash.
ENTRYPOINT ["/bin/bash", "-c"]

# The CMD directive is unnecessary since BAMOE Canvas will overwrite it.

All that is needed to do is build and publish the image.

Using the custom image on BAMOE Canvas

For the following steps, assume the image tagged and pushed to quay.io/myUserName/myDevDeploymentImage:latest.

When creating a Dev Deployment on BAMOE Canvas, this modal will display:

deployment option quarkus blank app
Figure 1. Deploy modal

By default, it uses the pre-configured Quarkus Blank App option. To use the custom image, open the dropdown and select Custom Image.

deployment option custom image
Figure 2. Custom Image deployment option

Notice the Docker Image parameter; it must be changed to the custom image tag created (quay.io/myUserName/myDevDeploymentImage:latest in this example).

Also, notice the Command parameter; Its value is the command executed inside the $HOME_PATH/app directory after the upload step is finished. In other words, after the token interpolation is finished, the resulting command executed on the container will be dev-deployment-upload-service && ./mvnw quarkus:dev.

This image does not provide the Maven binary globally, so it is not possible to call mvn directly. Instead, the image provides a Maven wrapper that can be called with ./mvnw from the $HOME_PATH directory.

When deploying to a local Kubernetes cluster configured via the Kubernetes Cluster Wizard from BAMOE Canvas, the Command will need a few more parameters for a Quarkus app:

`./mvnw quarkus:dev -Dquarkus.http.non-application-root-path=/${{ devDeployment.uniqueName }}/q -Dquarkus.http.root-path=/${{ devDeployment.uniqueName }}"`

When deploying to an OpenShift cluster, ./mvnw quarkus:dev will work without any flags.

This is because the Ingress controller is configured to use sub-paths for each Dev Deployment instead of new subdomains on the Kubernetes cluster, verify that the Quarkus app conforms to these sub-paths.

Creating a custom Dev Deployment options via user-defined YAMLs

Custom Dev Deployment options give you complete control over how your business automation models deploy to Kubernetes or OpenShift clusters. Use custom Dev Deployment options when you need to match specific infrastructure requirements, comply with organizational standards, or Support unique deployment scenarios.

Before creating your custom deployment option, understand the three key components used to create custom options:

  • Manifests: Standard Kubernetes YAML files that define your deployment resources.

  • Patches: JSON files that modify manifests dynamically at deploy time.

  • Descriptor: The option.json file that ties manifests and patches together.

Setting up the directory structure

Dev Deployment options are defined inside a Business Service project under the .bamoe/dev-deployments/ directory. Each option consists of a subdirectory containing manifests, patches, and a descriptor file:

Business Service Project
└── .bamoe/dev-deployments/
    └── <option-name>/
        ├── manifests/
        │   ├── Deployment.yaml
        │   ├── Service.yaml
        │   └── Route.yaml          (or Ingress.yaml for Kubernetes)
        ├── patches/
        │   ├── baseline-deployment.json
        │   └── include-dmn-form-webapp.json
        └── option.json

Configuring the manifests (manifests/)

Place standard Kubernetes resource YAML files in the manifests/ directory. Each file must contain exactly one resource. Multi-document YAML files with --- separators are not supported.

You can include token interpolation expressions in manifests using the ${{ }} format. BAMOE Canvas replaces these tokens with actual values at deploy time. Keep manifests free of tokens when possible. Use JSON Patches to inject dynamic values instead. This approach lets you use the same manifests for standalone Kubernetes deployments outside BAMOE Canvas.

Deployment Manifest example:
kind: Deployment
apiVersion: apps/v1
metadata:
  name: ${{ $.devDeployment.uniqueName }}
  namespace: ${{ $.devDeployment.kubernetes.namespace }}
  labels:
    app: ${{ $.devDeployment.uniqueName }}
    app.kubernetes.io/component: ${{ $.devDeployment.uniqueName }}
    app.kubernetes.io/instance: ${{ $.devDeployment.uniqueName }}
    app.kubernetes.io/name: ${{ $.devDeployment.uniqueName }}
    app.kubernetes.io/part-of: ${{ $.devDeployment.uniqueName }}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ${{ $.devDeployment.uniqueName }}
  template:
    metadata:
      labels:
        app: ${{ $.devDeployment.uniqueName }}
    spec:
      volumes:
        - name: app-volume
          emptyDir: {}
      containers:
        - name: ${{ $.devDeployment.uniqueName }}
          image: ${{ $.config.quarkusBlankAppImageUrl }}
          imagePullPolicy: ${{ $.config.imagePullPolicy }}
          resources:
            limits:
              memory: "4Gi"
          ports:
            - containerPort: 8080
              protocol: TCP
          env:
            - name: DEV_DEPLOYMENT__UPLOAD_SERVICE_API_KEY
              value: ${{ $.devDeployment.uploadService.apiKey }}
          volumeMounts:
            - mountPath: /tmp/app
              name: app-volume

BAMOE Canvas automatically force-adds required labels and annotations to every Kubernetes resource through JSON Patch during deployment. These are not configurable and you do not need to manually add them to your manifests.

Automatically Added Labels (via JSON Patch):

  • tools.kie.org/created-by — Always set to kie-tools

  • tools.kie.org/part-of — Set to the deployment’s unique name

Automatically Added Annotations (via JSON Patch):

  • tools.kie.org/workspace-id — Links to workspace ID

  • tools.kie.org/workspace-name — Links to workspace name

  • tools.kie.org/deployment-option-name — The name of the deployment option used

  • tools.kie.org/health-status-url-template — (Optional) If defined in option.json

  • tools.kie.org/deployment-access-url-template — (Optional) If defined in option.json

These labels and annotations enable BAMOE Canvas to discover, list, and manage Dev Deployments in the cluster.

Note
 Unlike the automatically added labels and annotations, the metadata.name and metadata.namespace fields are set through token interpolation in your manifest YAML. You must include these tokens (${{ $.devDeployment.uniqueName }} and ${{ $.devDeployment.kubernetes.namespace }}) in your custom manifests to ensure proper deployment identification and management.

Configuring the JSON Patches (patches/)

JSON Patches modify your manifests dynamically at deploy time. Use patches to inject values that change between deployments while keeping your base manifests reusable. Instead of creating multiple manifest files for different environments, you create one base manifest and use patches to customize it. Each patch file contains operations that tell BAMOE Canvas what to change. For example, you might use a patch to:

  • Add environment variables to a container

  • Change the number of replicas

  • Inject authentication tokens

JSON Patches follow the RFC 6902 specification.

The path property uses JSON Pointers to specify where BAMOE Canvas applies the operation. Operations can include token interpolation expressions.

The list of operations are:

  • add: Adds a value at the specified path (use to add new fields or array elements)

  • remove: Removes the value at the specified path (use to delete fields)

  • replace: Replaces the value at the specified path (use to change existing values)

  • test: Tests that a value matches (use as a filter—BAMOE Canvas applies patches only to manifests that pass all test operations)

Baseline deployment patch example

This patch applies only to Deployment resources. The test operation filters which manifests receive the patch:

Example
[
  {
    "op": "test",
    "path": "/kind",
    "value": "Deployment"
  },
  {
    "op": "add",
    "path": "/spec/template/spec/containers/0/env/-",
    "value": {
      "name": "ROOT_PATH",
      "value": "/${{ $.devDeployment.uniqueName }}"
    }
  },
  {
    "op": "add",
    "path": "/spec/template/spec/containers/0/env/-",
    "value": {
      "name": "DEV_DEPLOYMENT__UPLOAD_SERVICE_ROOT_PATH",
      "value": "${{ $.devDeployment.uniqueName }}"
    }
  }
]
Adding a sidecar container example

This patch adds a DMN Form Webapp sidecar container to the Deployment:

Example
[
  {
    "op": "test",
    "path": "/kind",
    "value": "Deployment"
  },
  {
    "op": "add",
    "path": "/spec/template/spec/containers/-",
    "value": {
      "name": "dmn-form-webapp",
      "image": "${{ $.config.dmnFormWebappImageUrl }}",
      "imagePullPolicy": "${{ $.config.imagePullPolicy }}",
      "ports": [
        {
          "containerPort": 8081,
          "protocol": "TCP"
        }
      ]
    }
  }
]

Configuring the Option Descriptor (option.json)

The option.json file is the central configuration for your deployment option. It defines:

  • What manifests to deploy

  • What patches to apply

  • What parameters users can customize

  • How BAMOE Canvas connects to your deployment

Table 1. Option Descriptor parameters
Field Type Required Description

specVersion

string

Yes

The version of the Dev Deployment option specification (currently 0.1)

name

string

Yes

Readable name displayed in the Deploy dropdown

description

string

Yes

Readable description of the deployment option

baselineManifests

string[]

Yes

List of manifest file paths (relative to the option.json directory) that BAMOE Canvas always deploys

baselinePatches

object

No

Map of manifest filenames to arrays of patch file paths that BAMOE Canvas always applies

parameters

object

No

Map of parameter IDs to parameter definitions (see Parameter Types)

eligibleAuthProviderIds

string[]

No

List of auth provider IDs for which this option is available. Valid values: openshift, kind, minikube, kubernetes-cloud. When omitted or empty, the option appears for all providers

uploadServiceUrlTemplate

string

No

URL template for the upload service endpoint, supports token interpolation

healthStatusUrlTemplate

string

No

URL template for the health check endpoint, supports token interpolation

deploymentAccessUrlTemplate

string

No

URL template for the user-facing application URL, supports token interpolation
Example:
{
  "specVersion": "0.1",
  "name": "Quarkus Blank App (OpenShift)",
  "description": "Deploy a serverless Quarkus application with optional DMN Form Webapp for testing DMN models on OpenShift",
  "eligibleAuthProviderIds": ["openshift"],
  "baselineManifests": [
    "manifests/Deployment.yaml",
    "manifests/Service.yaml",
    "manifests/Route.yaml"
  ],
  "baselinePatches": {
    "manifests/Deployment.yaml": ["patches/baseline-deployment.json"]
  },
  "parameters": {
    "includeDmnFormWebapp": {
      "id": "includeDmnFormWebapp",
      "name": "Include DMN Form Webapp",
      "description": "Whether to deploy the DMN Form Webapp as a sidecar container",
      "type": "choice",
      "defaultValue": "disabled",
      "maybeApplyPatches": {
        "manifests/Deployment.yaml": ["patches/include-dmn-form-webapp.json"]
      },
      "maybeAddManifests": ["manifests/FormWebappService.yaml", "manifests/FormWebappRoute.yaml"]
    }
  },
  "uploadServiceUrlTemplate": "https://${{ $.devDeployment.resources.Route['${{ $.devDeployment.uniqueName }}'].status.ingress[0].host }}/${{ $.devDeployment.uniqueName }}",
  "healthStatusUrlTemplate": "https://${{ $.devDeployment.resources.Route['${{ $.devDeployment.uniqueName }}'].status.ingress[0].host }}/${{ $.devDeployment.uniqueName }}/q/health",
  "deploymentAccessUrlTemplate": "https://${{ $.devDeployment.resources.Route['${{ $.devDeployment.uniqueName }}'].status.ingress[0].host }}/${{ $.devDeployment.uniqueName }}/q/swagger-ui/"
}

Adding parameters

Parameters enable users to customize deployments during creation. BAMOE Canvas displays appropriate input controls for each parameter type in the deployment dialog.

Text Parameter

Provides free-form text input for values such as Docker image URLs or commands. Use text parameters when users need to specify custom strings that vary between deployments.

For example,

{
  "id": "dockerImage",
  "name": "Docker Image",
  "description": "The URL of the Docker Image to use for the container",
  "type": "text",
  "defaultValue": "${{ $.config.baseImageUrl }}",
  "patches": {
    "manifests/Deployment.yaml": ["patches/docker-image.json"]
  }
}

  • defaultValue: The default text value (can include token interpolation)

  • patches: Patches to apply when using this parameter

  • addManifests: (Optional) Additional manifests to include

Number Parameter

Provides numeric input field. Use the number parameters for numeric values like ports, replica counts, or memory limits.

For example,

{
  "id": "containerPort",
  "name": "Container Port",
  "description": "The port that the container exposes",
  "type": "number",
  "defaultValue": 8080,
  "patches": {
    "manifests/Deployment.yaml": ["patches/deployment-container-port.json"],
    "manifests/Service.yaml": ["patches/service-target-port.json"]
  }
}

  • defaultValue: The default numeric value

  • patches: Patches to apply when using this parameter

  • addManifests: (Optional) Additional manifests to include

Boolean Parameter

Provides checkbox toggle. Use boolean parameters for simple on/off settings like enabling debug mode or verbose logging.

For example,

{
  "id": "enableDebug",
  "name": "Enable Debug",
  "description": "Enable debug mode for the application",
  "type": "boolean",
  "defaultValue": false,
  "patches": {
    "manifests/Deployment.yaml": ["patches/enable-debug.json"]
  }
}

  • defaultValue: true or false (when true, BAMOE Canvas applies associated patches and includes additional manifests)

  • patches: Patches to apply when parameter is true

  • addManifests: (Optional) Additional manifests to include when parameter is true

Choice Parameter

Provides enable/disable toggle. When enabled, BAMOE Canvas conditionally applies associated patches and includes additional manifests.

For example,

{
  "id": "includeDmnFormWebapp",
  "name": "Include DMN Form Webapp",
  "description": "Whether to deploy the DMN Form Webapp as a sidecar container",
  "type": "choice",
  "defaultValue": "disabled",
  "maybeApplyPatches": {
    "manifests/Deployment.yaml": ["patches/include-dmn-form-webapp.json"]
  },
  "maybeAddManifests": ["manifests/FormWebappService.yaml", "manifests/FormWebappRoute.yaml"]
}

  • defaultValue: "enabled" or "disabled"

  • maybeApplyPatches: Patches BAMOE Canvas applies only when enabled

  • maybeAddManifests: Additional manifests included only when enabled

Using addManifests with parameters

Use addManifests when a parameter must conditionally deploy additional Kubernetes resources (such as a separate Service, Ingress, or ConfigMap) that don’t exist in the baseline manifests.

For example:

{
  "id": "enableExtraService",
  "name": "Enable Extra Service",
  "description": "Deploy an additional service alongside the main application",
  "type": "boolean",
  "defaultValue": false,
  "addManifests": ["manifests/ExtraService.yaml"],
  "patches": {
    "manifests/Deployment.yaml": ["patches/extra-service-env.json"]
  }
}

When enableExtraService is true:

  • ExtraService.yaml is added to the set of deployed resources

  • extra-service-env.json patch is applied to Deployment.yaml (for example, to inject an environment variable pointing to the extra service)

When enableExtraService is false, neither the manifest nor the patch is included.

Note
 The addManifests field is optional. Use it only when the parameter needs to deploy new Kubernetes resources. If the parameter only modifies existing manifests (like the dockerImage text parameter example), use only the patches field.

URL Templates

URL templates configure how BAMOE Canvas connects to the deployed application for uploading assets, checking health, and providing access links.

Upload Service URL Template

Specifies the URL where BAMOE Canvas uploads workspace assets (BPMN/DMN files) to the deployed application. BAMOE Canvas uses this immediately after deployment to transfer files to the running container.

For example (OpenShift):

https://${{ $.devDeployment.resources.Route['${{ $.devDeployment.uniqueName }}'].status.ingress[0].host }}/${{ $.devDeployment.uniqueName }}
Health Status URL Template

Specifies the URL that BAMOE Canvas polls every 30 seconds to check the health of the deployed application. The endpoint should return HTTP 200 when the application is healthy.

For example (OpenShift, Quarkus):

https://${{ $.devDeployment.resources.Route['${{ $.devDeployment.uniqueName }}'].status.ingress[0].host }}/${{ $.devDeployment.uniqueName }}/q/health

When this template is provided, BAMOE Canvas uses it directly for health checks. When not provided, BAMOE Canvas falls back to probing both Quarkus (/q/health) and Spring Boot (/actuator/health) endpoints.

Deployment Access URL Template

Specifies the URL displayed to the user as a clickable link to access the deployed application.

For example (OpenShift, Quarkus with Swagger UI):

https://${{ $.devDeployment.resources.Route['${{ $.devDeployment.uniqueName }}'].status.ingress[0].host }}/${{ $.devDeployment.uniqueName }}/q/swagger-ui/

Token Interpolation

Tokens allow you to inject dynamic values into manifests at deployment time. Define a token using the ${{ }} syntax and provide a JSON Path expression (following RFC 9535) that identifies the value to insert.

For example, ${{ $.devDeployment.uniqueName }} resolves to the actual deployment name, such as dev-deployment-abc123.

During deployment, BAMOE Canvas resolves each token and replaces it with the corresponding value.

Tokens can contain other tokens (Nested tokens). BAMOE Canvas resolves them from inside out (maximum depth: 50).

Example of nested token resolution
Original:
${{ $.devDeployment.resources.Route['${{ $.devDeployment.uniqueName }}'].status.ingress[0].host }}

Step 1: Resolve inner token
${{ $.devDeployment.uniqueName }} → dev-deployment-abc123

Step 2: Resolve outer token
${{ $.devDeployment.resources.Route['dev-deployment-abc123'].status.ingress[0].host }}
→ dev-deployment-abc123.apps.cluster.example.com

Available Tokens

The following tokens are available in manifests and patches at deploy time:

Token Path Description

$.devDeployment.uniqueName

The unique name generated for this deployment (e.g., dev-deployment-abc123)

$.devDeployment.workspace.id

The ID of the current workspace

$.devDeployment.workspace.name

The name of the current workspace

$.devDeployment.kubernetes.namespace

The target Kubernetes namespace

$.devDeployment.uploadService.apiKey

The API key for the upload service

$.devDeployment.labels.createdBy

The label key for identifying resources created by BAMOE Canvas (tools.kie.org/created-by)

$.devDeployment.labels.partOf

The label key for grouping related resources (tools.kie.org/part-of)

$.devDeployment.annotations.workspaceId

The annotation key for the workspace ID (tools.kie.org/workspace-id)

$.devDeployment.annotations.workspaceName

The annotation key for the workspace name (tools.kie.org/workspace-name)

$.config.baseImageUrl

The base container image URL (from KIE_SANDBOX_DEV_DEPLOYMENT_BASE_IMAGE_URL)

$.config.quarkusBlankAppImageUrl

The Quarkus blank app container image URL (from KIE_SANDBOX_DEV_DEPLOYMENT_QUARKUS_BLANK_APP_IMAGE_URL)

$.config.dmnFormWebappImageUrl

The DMN Form Webapp container image URL (from KIE_SANDBOX_DEV_DEPLOYMENT_DMN_FORM_WEBAPP_IMAGE_URL)

$.config.imagePullPolicy

The image pull policy (from KIE_SANDBOX_DEV_DEPLOYMENT_IMAGE_PULL_POLICY)

$.parameters.<parameterId>

The value of a user-configured parameter

Additional Tokens in URL Templates

After deployment, you can access properties of deployed Kubernetes resources using URL templates. This is useful when you need to reference dynamic values like hostnames.

URL templates provide access to deployed Kubernetes resources:

Token Path Description

$.devDeployment.resources.<Kind>['<resourceName>']

Access to Kubernetes resources created during deployment, indexed by resource kind and metadata.name. Provides access to the full resource object including metadata, spec, and status.

For example:

  • Accessing the hostname from an OpenShift Route:

    ${{ $.devDeployment.resources.Route['${{ $.devDeployment.uniqueName }}'].status.ingress[0].host }}

  • Accessing the hostname from a Kubernetes Ingress:

    ${{ $.devDeployment.resources.Ingress['${{ $.devDeployment.uniqueName }}'].status.loadBalancer.ingress[0].hostname }}

Bundling Custom Dev Deployments with Accelerators

Bundle your custom Dev Deployment options with accelerators to make them available automatically when developers apply the accelerator.

For more information on configuring custom Accelerators, see Configuring custom Accelerators for your organization. For more information on using accelerators see Using Accelerators.

Creating Dev Deployment options in a Business Service project

You can create custom Dev Deployment options tailored to your Business Service project’s specific requirements by defining user-defined YAML manifests and configuration files within your project structure. To create a custom Dev Deployment option:

  1. Create the directory structure .bamoe/dev-deployments/<option-name>/.

  2. Add Kubernetes resource YAML manifests to the manifests/ subdirectory (one resource per file).

  3. Optionally, create JSON Patch files in the patches/ subdirectory.

  4. Create the option.json descriptor file that references manifests, patches, and defines configurable parameters and URL templates.

  5. Commit the files to the project repository.

When you open the Deploy dialog in BAMOE Canvas, displays custom options (filtered by the connected provider type).

Validating Dev Deployment

BAMOE Canvas validates option.json files against a JSON schema derived from TypeScript type definitions. BAMOE Canvas displays validation errors in the Deploy dialog with specific error messages.

Common validation errors include:

  • Missing required fields (name, description, specVersion, baselineManifests)

  • Invalid parameter types

  • Manifest files referenced in option.json not found in the manifests/ directory

  • Patch files referenced in option.json not found in the patches/ directory

  • Invalid JSON in patch files

  • Invalid YAML in manifest files

Note
 When some options load successfully and others fail, BAMOE Canvas displays a warning and lists only the valid options. Fix the errors in the failing options and reopen the Deploy dialog.