Skip to content

Workload Template

A workload is restricted to a specific namespace and placement policy assigned to it. When a workload is used in multiple stages of a pipeline, there may be a need to use environment/stage specific overrides outside the workload definition. Workload templates do not have "namespace" and "placement" associated with it. Therefore, when a workload template is used in a stage in a pipeline, it is necessary to assign namespace and placement. These can be provided dynamically in a Stage in a pipeline.

Use Cases

Described below are some example use cases where workload templating can be extremely valuable

Developer Test Beds

Every developer in the team is provided their own "test bed". Every time there is a new version/build, the test beds for all developers need to be updated and made current automatically.

Hosted Software

ISV hosts a copy of the same workload in a "separate namespace per customer". ISV wants the software to be kept patched and updated automatically without having to manually handle the workloads one by one.

Create Workload Template

You can create a workload template imperatively using the Console or declaratively using a workload template spec YAML file and use it via the RCTL CLI.

  • Provide a unique name for the workload so that you can refer to it and find it later
  • Specify the package type (Both "Helm 3" or "YAML" formats are supported)
  • Specify how the artifacts can be accessed. You have two options

Upload Artifacts

Upload them to the controller as part of the workload template creation process

Create Workload Template

Repo Sync

Provide the location (Git or Helm repo)

Create Workload Template


If your artifacts are in a private repository, ensure you configure an agent so that the controller can monitor it for updates.

Artifact Details

The artifacts associated with your workload template can either be a Helm chart or k8s YAML file. You can either provide it to the controller by uploading it or have the controller automatically retrieve it from your repository.

Upload Artifacts

Helm Chart

If you selected "upload artifacts" and your package type is "Helm", select the Helm chart (packaged as a TGZ file) and upload it.

Upload Helm Chart

k8s YAML

If you selected "upload artifacts" and your package type is "k8s YAML", select the yaml file and upload it.

Upload Helm Chart


Helm Chart

If you selected "upload artifacts" and your package type is "Helm", select the Helm chart (packaged as a TGZ file) and upload it.

Helm Chart-Repository

Users are also provided with a number of advanced options for Helm

Helm Chart-Repository - Advanced Options

k8s YAML

If you selected "upload artifacts" and your package type is "k8s YAML", select the yaml file and upload it.

k8s YAML-Repository

Use Workload Template

Once created, workload templates can be used in a Stage in a Pipeline.

  • Provide a name for the stage
  • Select "Workload Template" from Actions
  • Select the workload template you need from the dropdown


Since a workload template does not specify the target namespace or placement, you have to specify these here


Either select from (a) the list of existing namespaces OR (b) create a new namespace as part of the stage


Select placement type to determine the target clusters for deployment

Advanced - Node Grouping Keys

Select one or more Node Group Keys to deploy on the target cluster

Placement of workload within multiple node groups in a cluster is supported now. A Node group is a logical collection of nodes based on a specified label key and this key is called nodeGroupingKey

For the nodes present in AWS wavelength zone, the key is available in the system. Users can pick this key as nodeGroupingKey or any customized key to deploy in all wavelength zones in the cluster. Also, you can select multiple node grouping keys across the cluster but no node must appear in more than one node group


Wavelength zone applications can be deployed only using the Workload Templates and GitOps Pipelines

Drift Action

Specify the kind of action you wish to take w.r.t. drift detection (Not Set, Detect and Notify and Detect and Block are possible options)

Revision from Webhook Trigger

By default, Use Revision from Webhook Trigger is set to False, where the commit revision from the trigger will not be used to deploy the workload. Set True to ensure the trigger's repo and workload template's repo are the same and the commit revision due to which the triggered pipeline is present in the workload template's repo

Use Template in Stage