Skip to content

Custom Blueprint

Customers can create and manage "Custom Cluster Blueprints" by adding "addons" to the default cluster blueprints. It is important to emphasize that this "builds on" and "extends" the "Default Cluster Blueprints" and does not replace it.


You can manage the lifecycle of custom blueprints using the Web Console, or RCTL CLI or REST APIs. It is strongly recommended to automate this by integrating RCTL with your existing CI system-based automation pipeline.


Other than the default cluster blueprints, which is common across all projects, all custom blueprints are scoped to a Project. This isolation boundary guarantees that there is no accidental spillover or leakage. If required, blueprints can be shared with selected or all projects.


Users manage the lifecycle of cluster blueprints with an "infrastructure administrator" role in the Org.

Step 1: Create Custom Blueprint

As an Admin in the Web Console,

  • Navigate to the Project
  • Click on Blueprints under Infrastructure
  • Click on New blueprint
  • Provide a name and description

New Blueprint

All custom cluster blueprints are version-controlled so that the lifecycle can be properly managed. In this example, the admin has not yet configured anything. So, no versions are available yet.

New Blueprint

Step 2: New Version

  • Click on New Version and use the wizard to provide details
  • Provide a version number/name
  • Select a Base Blueprint. The four (4) Base Blueprints are default, minimal, default-openshift (specific to OpenShift), and default-aks (specific to AKS). Each Base Blueprint has different group of system add-ons with multiple versions. Users can pick any of these Base Blueprint and customize to create a new Blueprint version
  • Select Pod Security Policies (PSPs) and scoping (cluster or namespace)
  • Optionally,
  • Select a drift detection policy
  • Enable Enable OPA Gatekeeper for this Blueprint and select a policy from the list to enforce on the required cluster
  • Select custom addons and identity version of the addon
  • Optionally disable addons from the default blueprint (i.e. Ingress Controller)
  • Click Save Changes

For more information, refer Add-Ons

  • If you have plans to deploy Virtual Machine Workloads, check the VM Operator option under Managed System Add-ons. When selecting VM Operator, user receives a message "Atleast one node with label should be present in the cluster". This is to ensure that the cluster using this blueprint must have a node with the label
  • Click Save Changes.

Below is an example of creating a custom blueprint called "demo-blueprint".

New Version

View Versions

The entire history of blueprint versions are maintained on the Controller. Admins can view details about the versions of cluster blueprints.

View All Versions

Filter Clusters by Blueprint

Infrastructure admins can "filter" clusters by blueprint name using the Web Console to manage a fleet of clusters efficiently. An illustrative example is shown below.

Filter Clusters by Blueprint

View All Cluster Blueprints

Admins can view all custom cluster blueprints.

  • Navigate to the Project
  • Click on Blueprints under Infrastructure.

This will display both the "default blueprints" and any cluster blueprints that have been created. An illustrative example is shown below.

View Cluster Blueprints

Apply Custom Blueprint

Once a custom cluster blueprint has been created and published, it can be used during the initial provisioning of clusters or applied to existing clusters.

New Clusters

While creating a new cluster, select the "custom blueprint" from the dropdown. An illustrative example is shown below.

Blueprint for New Cluster

Existing Clusters

  • Click on options (gear icon on the far right) for an existing cluster
  • Select "Update Blueprint" from the options
  • Select the "blueprint" and "version" from the dropdown
  • Click on Save and Publish

Blueprint for Existing Cluster

This will update the cluster blueprint on the target cluster. Once all the required resources are operational on the cluster, the blueprint update/sync will be complete.


If the selected blueprint version has VM Operator enabled, minimum one node with label must be available in the selected cluster. This information is presented to the user when selecting the VM Operator is enabled in the blueprint version.

Status and Debug

In addition to using the Zero Trust KubeCTL channel for debugging and diagnostics, admins can also use the built-in status details if issues are encountered during a blueprint sync process with a cluster.

In the Blueprint Sync Status field on the cluster, click on the Status link. This will provide detailed status by component in the blueprint.

An illustrative example is shown below.

Deep Blueprint Status


In some scenarios, there are requirements that certain components (add-ons) need to be installed first before installing the rest of the components (add-ons).

To achieve this, define this dependency when creating the blueprint version. In the below example, install cert-manager before installing vault because vault uses cert-manager to create the certificate for Ingress.

  • Navigate to the Project
  • Click on Blueprints under Infrastructure
  • Click on New blueprint
  • Provide a name and description
  • Click Create
  • Click on New Version and use the wizard to provide details
  • Provide a version number/name
  • Select PSPs and scoping (cluster or namespace)
  • Under add-ons, select cert-manager and its version.
  • Select "ADD MORE" and then select Vault add-on from the dropdown and its version
  • Select "ADD DEPENDENCY" under Vault add-on and select "cert-manager"
  • Click "Save Changes"

add-on Dependency


If an add-on is dependent on multiple add-ons, all these add-ons can be added as dependencies.