Skip to content


Expressions enable users to dynamically configure input variables by utilizing the output of other resources or configurations. This helps platform teams in creating programmable templates for provisioning infrastructure and applications.

Using resource output as input to another via expressions typically refers to the practice of taking the output or information from one resource and using it as input or configuration for another resource. If it's a Terraform resource template, and there are output variables defined in the terraform configuration, that constitutes the output of the resource. Currently, only Terraform is supported.

Here is an example of a VPC Terraform output containing values that can be utilized as an input for other resources:

output "vpc_id" {
  value = module.vpc.vpc_id

Application deployments

Let's take the example of an environment named env1 based on an environment template named envtemp. This environment includes resources such as vpc, rds, and a Rafay managed K8s cluster, where the K8s cluster and RDS depend on VPC.

A developer/data scientist wishing to deploy an application to the K8s cluster can avoid hardcoding the workload/application manifest with the environment details and instead use the following expression.


Let's assume that the application needs to include details of the RDS instance. Below is an example snippet of the Terraform output for the RDS resource template.

output "rds_hostname" {
  description = "RDS instance hostname"
  value       = aws_db_instance.db.address
  sensitive   = true

For this specific output example, the workload expression would be:


Below is an example of a workload Helm value file with expressions, where RDS Terraform output values are passed as input values.

  celeryBrokerUrl: 'redis://$(#environment["ec-resoource-tmpl"].configuration_endpoint_address):6379/0'
  celeryResultBackend: 'redis://$(#environment["ec-resoource-tmpl"].configuration_endpoint_address):6379/0'
  debug: "True"
  djangoDb: postgresql
  postgresHost: '$(#environment["rds-resource-tmpl"].rds_hostname)'
  postgresName: postgres
  postgresPassword: '$(#environment["rds-resource-tmpl"].rds_password)'
  postgresPort: '$(#environment["rds-resource-tmpl"].rds_port)'
  postgresUser: '$(#environment["rds-resource-tmpl"].rds_username)'

In case the variable type is a list (array), utilize indexing to reference various values. For example, to bring up a load balancer that has multiple IPs, use the following expression:


If you are leveraging Rafay Workloads, ensure to select the correct Environment Configuration based on the requirement.

Create EKS Cluster


Workload Expressions feature can be leveraged even when third-party GitOps tools such as ArgoCD are used for application deployments.

Dynamic and Static Resource

There could be scenarios where the the output of a dynamic/static resource needs to be passed to another resource as part of the environment creation process. You can use the below expression for such scenarios:


Let's take an example where an environment template includes dynamic resources vpc and rds, and there is a requirement to pass the vpc ID to rds so that rds is installed in that particular vpc ID. To achieve this, pass the output of the vpc to the rds using the following expression:


The above expression references the output value 'vpc_id' from the 'vpc' resource.

Create EKS Cluster

Similarly to dynamic resources, static resource outputs can also be passed to another resource.

Static Environment Resource

To pass the output of a static environment resource to another resource, use the below expression:


Lets' take the example where an environment named "env1" has already been created. If the user intends to create an additional environment with the "rds" resource on top of "env1" without modifying the existing "env1", follow the expression outlined below:


The above expression employs the 'env1' environment name, the static resource name 'rds', and references the output value labeled as 'rds_hostname'. The values can be of any type, such as array, map, and string.

Users can utilize this expression to include 'env1' as a static resource in the new environment alongside the RDS.

Dedicated Resource(s)

When creating an environment template, user has the ability to add dynamic or static resources (pre-existing resources).

When the "dynamic" option is selected for resources, users are allowed to enable the dedicated option. When the dedicated option is enabled, dedicated resources are only brought up when a workload is published to that environment.

Create EKS Cluster

To use the workload attributes as part of the dedicated resource(s), use the following expression:




If ElastiCache is a dedicated resource that needs to be brought up for a workload, the user can use the workload name $($ as input to the name variable of the ElastiCache. So, whenever a workload is published, the dedicated ElastiCache comes up with the name of the workload.

Note: When the workload is unpublished/destroyed, the dedicated resources within that workload will also be destroyed.

Environment Resource(s)

Assume a scenario where a user attempts to set up three to four environments using an environment template, and all the resources are being launched in the same AWS region. To prevent naming conflicts, utilize the following expression to create them with dynamic names and IDs.

  • $($
  • $($
  • $($
  • $($
  • $(environment.labels.key)$

Resource Artifact Variables

There are instances where the user intends to download Terraform working directory at different stages such as Init, Plan (pre-hook & post-hook), Apply, and Output. Users can download the required artifacts via container hooks using the expression below (from the working directory as a token and url). This enables users to access the artifacts and perform necessary actions such as scanning of terraform code, calculate the cost of the infrastructure etc.

Create EKS Cluster

You can use the expressions below to download artifacts:

Artifact Activity


Plan Activity


Trigger Expressions

Trigger expressions are used to enable dynamic event-driven responses within systems by allowing users to leverage the output of trigger events as input for subsequent actions or workflows.

Use the below trigger expressions to dynamically configure actions and workflows based on event triggers.

  • trigger.payload.is_sso_user: To check if the user logged in using Single Sign-On credentials
  • trigger.payload.userid: Retrieves the user's identification, typically their email address
  • trigger.payload.username: Fetches the username, which is usually the user's email address
  • trigger.payload.type (type: destroy, force-destroy, force-release-lock): Identifies the type of action triggered, such as deletion or lock release
  • Provides the unique identifier for the trigger event
  • trigger.payload: Represents all data associated with the trigger event
  • trigger.reason: Captures the reason behind the trigger event


  • When users initiate resource deletion actions, such as "destroy" or "force-destroy," the trigger expression trigger.payload.type identifies the type of deletion request. Based on the detected type, the system dynamically initiates automated cleanup processes, ensuring that associated resources are properly released and decommissioned

  • When a user attempts to log in to the controller, the trigger expression trigger.payload.is_sso_user evaluates whether the user has authenticated using the Single Sign-On mechanism. If the user is an SSO user, expression returns true