> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/3.0/yaml-reference/step-library-yaml-reference.md). # Step library YAML reference YAML examples for every Kubernetes, Helm, Google Cloud Run, AWS Lambda, AWS SAM, and Serverless Lambda step available in Harness Deployments. Harness provides 16+ Kubernetes steps, 7+ Helm steps, 4 Google Cloud Run steps, 5 AWS Lambda steps, 3 AWS SAM steps, and 3 Serverless Lambda steps. This page collects the YAML for every step in one place, covering rolling, blue-green, and canary deployment strategies as well as utility operations for scaling, patching, traffic routing, and manifest management. *** ### Kubernetes steps #### Kubernetes Rolling Deploy Template ID: `k8sRollingDeployStep` Prepares manifests, applies them to the cluster, and checks resource steady state. Performs a rolling update, gradually replacing old pods with new ones to ensure zero-downtime deployments. | Input | Type | Description | | ------------------------- | ------- | ---------------------------------------------------------------- | | `namespace` | string | Kubernetes namespace for deployment | | `manifests` | array | List of manifest file paths | | `release` | string | Release name | | `skip_dry_run` | boolean | Skip dry run (default: `false`) | | `pruning` | boolean | Remove old resources not in current manifests (default: `false`) | | `server_side_apply` | boolean | Use server-side apply (default: `false`) | | `skip_steady_state_check` | boolean | Skip steady state check (default: `false`) | | `flags` | array | Additional command flags | | `log_level` | select | Log level: `warn`, `error`, `info`, `debug`, `trace` | For rollback, use `k8sRollingRollbackStep` to revert a rolling deployment to its previous state. ```yaml steps: - name: Rolling Deploy uses: k8sRollingDeployStep@1.0.0 with: namespace: production manifests: - k8s/deployment.yaml - k8s/service.yaml pruning: true log_level: info ``` *** #### Kubernetes Rolling Rollback Template ID: `k8sRollingRollbackStep` Re-applies the manifests from the last successful release stored in the cluster release history secret. Harness runs this step automatically when a rolling or canary stage fails. You can also add it manually to a rollback group. | Input | Type | Description | | ----------------- | ------- | ----------------------------------------------------------------------------------------------- | | `namespace` | string | Target namespace | | `release` | string | Release name used to look up rollback target in the cluster secret | | `enable_pruning` | boolean | Remove resources present in current release but absent from rollback release (default: `false`) | | `kubeconfig_path` | string | Path to the kubeconfig file | ```yaml steps: - name: Rolling Rollback uses: k8sRollingRollbackStep@1.0.0 with: namespace: production release: my-release ``` *** #### Kubernetes Blue-Green Deploy Blue-green deployment maintains two identical environments. The new version is deployed to the inactive stage environment, tested, and traffic is switched by swapping service selectors. Provides instant rollback by re-swapping selectors. | Step | Description | | --------------------------------------- | ----------------------------------------------------------- | | `k8sBlueGreenDeployStep` | Creates services and pod sets for blue-green deployment | | `k8sBlueGreenSwapServicesSelectorsStep` | Swaps service selectors to route traffic to the new version | | `k8sBlueGreenStageScaleDownStep` | Scales down the inactive stage environment | Also available as a managed strategy: `k8sBlueGreenDeployStrategy`, which orchestrates all three steps automatically. **Blue-green workflow:** 1. Deploy the new version to the stage environment alongside the active primary environment. 2. Test the stage deployment to verify the new version is healthy. 3. Swap service selectors to route production traffic to the new version. 4. Scale down the old primary environment to free resources. ```yaml steps: - name: Blue-Green Deploy uses: k8sBlueGreenDeployStep@1.0.0 with: namespace: production manifests: - k8s/deployment.yaml - k8s/service.yaml # After testing... - name: Swap Traffic uses: k8sBlueGreenSwapServicesSelectorsStep@1.0.0 - name: Scale Down Old uses: k8sBlueGreenStageScaleDownStep@1.0.0 ``` *** #### Kubernetes Canary Deploy Canary deployment gradually rolls out changes by first deploying a small subset of pods with the new version. Monitor metrics and health before promoting to the full fleet or rolling back. | Step | Description | | --------------------- | ------------------------------------------------------- | | `k8sCanaryDeployStep` | Deploys a subset of pods with the new version | | `k8sCanaryDeleteStep` | Cleans up canary deployment after promotion or rollback | Also available as a managed strategy: `k8sCanaryDeployStrategy`, which handles the canary lifecycle automatically. **Canary workflow:** 1. Deploy a small percentage of pods with the new version. 2. Monitor metrics and health of the canary pods. 3. Promote (trigger a full rolling deploy) or rollback (delete the canary pods). ```yaml steps: - name: Canary Deploy uses: k8sCanaryDeployStep@1.0.0 with: namespace: production manifests: - k8s/deployment.yaml instances: 1 # After validation... - name: Promote / Cleanup uses: k8sCanaryDeleteStep@1.0.0 ``` *** #### Kubernetes Apply Template ID: `k8sApplyStep` Apply manifests directly to the cluster. Supports dry run, pruning, server-side apply, and manifest printing for debugging. | Input | Type | Description | | ------------------- | ------- | ------------------------------------- | | `namespace` | string | Kubernetes namespace | | `manifests` | array | List of manifest file paths | | `skip_dry_run` | boolean | Skip dry run validation | | `pruning` | boolean | Remove old resources not in manifests | | `server_side_apply` | boolean | Use server-side apply | | `print_manifests` | boolean | Print rendered manifests to logs | | `flags` | array | Custom kubectl command flags | ```yaml steps: - name: Apply Manifests uses: k8sApplyStep@1.0.0 with: namespace: production manifests: - k8s/configmap.yaml - k8s/secret.yaml - k8s/deployment.yaml server_side_apply: true print_manifests: true ``` *** #### Kubernetes Delete Template ID: `k8sDeleteStep` Delete Kubernetes resources by name, manifest path, or release name. Useful for cleaning up resources during teardown or rollback workflows. ```yaml steps: - name: Delete Resources uses: k8sDeleteStep@1.0.0 with: namespace: staging manifests: - k8s/deployment.yaml - k8s/service.yaml # Or delete by release name - name: Delete Release uses: k8sDeleteStep@1.0.0 with: namespace: staging release: my-release ``` *** #### Kubernetes Scale Template ID: `k8sScaleStep` Scale Kubernetes workloads up or down by setting the desired replica count on a Deployment, StatefulSet, or other scalable resource. ```yaml steps: - name: Scale Up uses: k8sScaleStep@1.0.0 with: namespace: production workload: Deployment/my-app replicas: 5 - name: Scale Down uses: k8sScaleStep@1.0.0 with: namespace: production workload: Deployment/my-app replicas: 2 ``` *** #### Kubernetes Patch Template ID: `k8sPatchStep` Patch workload resources using strategic merge patch, JSON merge patch, or JSON patch operations. Useful for updating specific fields without a full redeployment. ```yaml steps: - name: Patch Deployment uses: k8sPatchStep@1.0.0 with: namespace: production resource: Deployment/my-app patch: | spec: template: spec: containers: - name: my-app resources: limits: memory: "512Mi" ``` *** #### Kubernetes Traffic Routing Template ID: `k8sTrafficRoutingStep` Shift traffic between different versions of services. Commonly used in canary and blue-green workflows to gradually route a percentage of traffic to the new version. ```yaml steps: - name: Route 10% Traffic uses: k8sTrafficRoutingStep@1.0.0 with: namespace: production service: my-app-svc destinations: - host: my-app-canary weight: 10 - host: my-app-primary weight: 90 # After validation, shift more traffic - name: Route 50% Traffic uses: k8sTrafficRoutingStep@1.0.0 with: namespace: production service: my-app-svc destinations: - host: my-app-canary weight: 50 - host: my-app-primary weight: 50 ``` *** #### Kubernetes Diff Template ID: `k8sDiffStep` Compare current cluster state with desired manifests to preview what would change before applying. Does not modify the cluster. ```yaml steps: - name: Diff Manifests uses: k8sDiffStep@1.0.0 with: namespace: production manifests: - k8s/deployment.yaml ``` *** #### Kubernetes Dry Run Template ID: `k8sDryRunStep` Validate manifests against the cluster API without applying any changes. Catches schema errors and misconfigured resources before they reach the cluster. ```yaml steps: - name: Dry Run uses: k8sDryRunStep@1.0.0 with: namespace: production manifests: - k8s/deployment.yaml ``` *** #### Kubernetes Steady State Check Template ID: `k8sSteadyStateCheckStep` Explicitly wait for workloads to reach steady state (all pods running and ready) at any point in the stage. Useful when you need a health gate between steps. ```yaml steps: - name: Steady State Check uses: k8sSteadyStateCheckStep@1.0.0 with: namespace: production workload: Deployment/my-app timeout: 5m ``` *** #### Kubernetes Rollout Template ID: `k8sRolloutStep` Run `kubectl rollout` subcommands against workloads. Use `restart` to bounce pods after a ConfigMap or Secret update, `status` to wait for a rollout to complete, `undo` to revert to the previous revision, or `pause`/`resume` to control an in-progress rollout. | Command | Description | | --------- | ---------------------------------------------------------------- | | `restart` | Triggers a rolling restart of all pods in the workload | | `status` | Waits for the rollout to complete and returns success or failure | | `undo` | Rolls back the workload to the previous revision | | `pause` | Pauses an in-progress rollout | | `resume` | Resumes a paused rollout | | `history` | Prints the rollout history to the step log | ```yaml steps: # Restart pods to pick up a new ConfigMap - name: Kubernetes Rollout uses: k8sRolloutStep@1.0.0 with: command: restart resources: - default/Deployment/my-app # Restart all workloads in a release - name: Kubernetes Rollout uses: k8sRolloutStep@1.0.0 with: command: restart release_name: my-release ``` *** ### Helm steps #### Helm Basic Deploy Template ID: `helmDeployBasicStep` Deploys a Helm chart using `helm upgrade --install`, waits for all workloads to reach steady state, and optionally runs chart tests. | Input | Type | Description | | -------------------------- | ------- | ---------------------------------------------------- | | `namespace` | string | Kubernetes namespace | | `release` | string | Helm release name | | `manifests` | string | Chart path (.tgz archive or directory) | | `values` | array | Values file paths for overrides | | `ignore_failed_release` | boolean | Proceed even if previous release is in failed state | | `skip_deploy_steady_check` | boolean | Skip steady state check after deploy | | `upgrade_with_install` | boolean | Always use `helm upgrade --install` | | `deploy_test` | boolean | Run `helm test` after deploy | | `server_render` | boolean | Server-side rendering of templates | | `deploy_log_level` | select | Log level: `warn`, `error`, `info`, `debug`, `trace` | ```yaml steps: - name: Deploy with Helm uses: helmDeployBasicStep@1.0.0 with: release: my-release namespace: production values: - helm/values-prod.yaml upgrade_with_install: true ``` *** #### Helm Blue-Green Helm blue-green deployment uses Helm releases to maintain two environments. The new version deploys as a separate Helm release, is tested, then traffic swaps to the new release. | Step | Description | | ------------------------- | ----------------------------------------------------------------- | | `helmDeployBluegreenStep` | Deploy the new version as a Helm release to the stage environment | | `helmBluegreenSwapStep` | Swap traffic from the primary to the stage release | Also available as a managed strategy: `helmDeployBluegreenStrategy`. ```yaml steps: - name: Helm Blue-Green Deploy uses: helmDeployBluegreenStep@1.0.0 with: release: my-release namespace: production values: - helm/values-prod.yaml # After testing the stage release... - name: Swap Traffic uses: helmBluegreenSwapStep@1.0.0 ``` *** #### Helm Canary Helm canary deployment installs a canary Helm release with a subset of traffic routed to it. After validation, the canary is promoted to full deployment or rolled back. | Step | Description | | ---------------------- | ----------------------------------------------------- | | `helmDeployCanaryStep` | Deploy a canary Helm release with a subset of traffic | Also available as a managed strategy: `helmDeployCanaryStrategy`. ```yaml steps: - name: Helm Canary Deploy uses: helmDeployCanaryStep@1.0.0 with: release: my-release-canary namespace: production values: - helm/values-prod.yaml - helm/values-canary.yaml ``` *** #### Helm Canary Delete Template ID: `helmCanaryDeleteStep` Uninstalls the canary Helm release after validation or on rollback. The `release` field is auto-populated from the Canary Deploy step output. The stable release is not affected. In the rollback sequence, the step is pre-wired to `${{rollback.data.PLUGIN_CANARY_RELEASE_NAME}}` and runs only when a canary release was actually created. ```yaml steps: - name: Helm Canary Delete uses: helmCanaryDeleteStep@1.0.0 with: release: my-release-canary namespace: production ``` *** #### Helm Rollback Template ID: `helmRollbackStep` Roll back a Helm release to a previous revision. Harness automatically determines the previous healthy revision, or you can specify a target revision explicitly. ```yaml steps: - name: Rollback Release uses: helmRollbackStep@1.0.0 with: release: my-release namespace: production # Or rollback to a specific revision - name: Rollback to Revision 3 uses: helmRollbackStep@1.0.0 with: release: my-release namespace: production revision: 3 ``` *** #### Helm Delete Template ID: `helmDeleteStep` Uninstall a Helm release and remove all associated Kubernetes resources from the cluster. ```yaml steps: - name: Uninstall Release uses: helmDeleteStep@1.0.0 with: release: my-release namespace: production ``` *** ### Google Cloud Run steps Google Cloud Run steps authenticate with GCP using a connector configured on each step and run `gcloud` CLI commands against your Cloud Run service or job. They use the `template:` wrapper in stage YAML rather than the short `uses:` form used by Kubernetes and Helm steps. *** #### Google Cloud Run Deploy Template ID: `googleCloudRunDeployStep` Applies the service manifest using `gcloud run services replace`, describes the resulting revision, saves rollback data, and performs a Google Cloud Monitoring instance sync. | Input | Type | Description | | ------------------------- | ------- | -------------------------------------------------------------------------------------------- | | `gcp_connector` | string | GCP connector ID. Defaults to the infrastructure definition connector. | | `region` | string | Cloud Run service region. Default: `${{infra.region}}`. | | `project` | string | GCP project. Default: `${{infra.project}}`. | | `service_manifest_path` | string | Path to the service manifest. Default: `${{runtime.manifestPath}}`. | | `service_container_image` | string | Container image to deploy. Default: `${{artifact.image}}`. | | `cmd_options` | string | Additional flags for `gcloud run services replace`. | | `skip_traffic_update` | boolean | When `true`, creates a new revision without shifting traffic. Use with a Traffic Shift step. | | `cmd_timeout` | string | Maximum step duration. Default: `10m`. | | `log_level` | select | Log verbosity: `info`, `debug`, `warn`, `error`. | ```yaml steps: - name: Google Cloud Run Deploy id: googleCloudRunDeployStep template: uses: googleCloudRunDeployStep ``` With overrides: ```yaml steps: - name: Google Cloud Run Deploy id: googleCloudRunDeployStep template: uses: googleCloudRunDeployStep with: skip_traffic_update: true cmd_options: "--port=8080" cmd_timeout: 15m log_level: debug ``` *** #### Google Cloud Run Traffic Shift Template ID: `googleCloudRunTrafficShiftStep` Routes traffic to specific Cloud Run revisions using `gcloud run services update-traffic`. When rollback runs, Harness uses the revision state from the last successful deployment of the stage to restore traffic to the stable revision. | Input | Type | Description | | ----------------------- | ------ | ------------------------------------------------------------------------- | | `metadata` | string | JSON object describing the target traffic distribution. | | `service_manifest_path` | string | Derived from service configuration. Default: `${{runtime.manifestPath}}`. | | `gcp_connector` | string | Derived from infrastructure configuration. | | `region` | string | Derived from infrastructure configuration. | | `project` | string | Derived from infrastructure configuration. | | `command_timeout` | string | Maximum step duration. Default: `10m`. | | `log_level` | select | Log verbosity. | The `metadata` field takes a JSON object that mirrors the Cloud Run service status traffic structure: ```json {"status":{"traffic":[{"revisionName":"LATEST","percent":100}]}} ``` Route all traffic to the latest revision: ```yaml steps: - name: Google Cloud Run Traffic Shift id: googleCloudRunTrafficShiftStep template: uses: googleCloudRunTrafficShiftStep with: metadata: '{"status":{"traffic":[{"revisionName":"LATEST","percent":100}]}}' ``` Split traffic 50/50 between stable and canary: ```yaml steps: - name: Google Cloud Run Traffic Shift id: googleCloudRunTrafficShiftStep template: uses: googleCloudRunTrafficShiftStep with: metadata: '{"status":{"traffic":[{"revisionName":"my-service-00003-abc","percent":50},{"revisionName":"LATEST","percent":50}]}}' ``` *** #### Google Cloud Run Rollback Template ID: `googleCloudRunRollbackStep` Restores the traffic state from the last successful deployment of the stage. Runs `gcloud run revisions list`, reads `rollback.data.REVISION_METADATA` to identify the target revision, then runs `gcloud run services update-traffic --to-revisions==100`. If no prior successful deployment exists, deletes the service using `gcloud run services delete` instead. The Rollback step belongs in the stage `rollback:` phase, not in the main `steps:` list. No `with:` inputs are required — Harness reads rollback state from the last successful deployment automatically. Basic strategy rollback phase: ```yaml rollback: - group: steps: - name: Google Cloud Run Rollback id: googleCloudRunRollbackStep template: uses: googleCloudRunRollbackStep id: googleCloudRunBasicRollback name: Google Cloud Run Basic Rollback ``` Canary strategy rollback phase: ```yaml rollback: - group: steps: - name: Google Cloud Run Rollback id: googleCloudRunRollbackStep template: uses: googleCloudRunRollbackStep id: googleCloudRunCanaryRollback name: Google Cloud Run Canary Rollback ``` *** #### Google Cloud Run Job Template ID: `googleCloudRunJobStep` Deploys or executes a Cloud Run Job. The step operates in one of two modes based on whether `job_name` is set. When `job_name` is set, the step runs execute only. When `job_name` is empty, the step replaces the job definition from the service manifest first, then executes. | Input | Type | Description | | ------------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | `job_name` | string | The name of the Cloud Run job to execute. When set, the step runs execute only. Leave empty to replace the job definition from the service manifest first. | | `replace_command_options` | string | Additional flags for `gcloud run jobs replace`. Only applies when `job_name` is empty. | | `execute_command_options` | string | Additional flags for `gcloud run jobs execute`. Optional. | GCP Connector, GCP Region, and GCP Project are available under **+ More options** in the UI. Execute an existing job by name (execute only): ```yaml steps: - name: Google Cloud Run Job id: googleCloudRunJobStep template: uses: googleCloudRunJobStep with: job_name: my-batch-job execute_command_options: "--update-env-vars=ENV=production" ``` Replace the job definition from the service manifest, then execute (job\_name empty): ```yaml steps: - name: Google Cloud Run Job id: googleCloudRunJobStep template: uses: googleCloudRunJobStep with: replace_command_options: "--async --verbosity=debug" execute_command_options: "--update-env-vars=key1=value1,key2=value2" ``` *** #### Full Google Cloud Run stage (canary) A complete canary deployment stage showing the Deploy step, Traffic Shift step, rollback phase, and failure strategy: ```yaml - name: google-cloud-run id: googleCloudRun service: type: google-cloud-run items: - environment: items: - id: deploy-to: all steps: - name: Google Cloud Run Deploy id: googleCloudRunDeployStep template: uses: googleCloudRunDeployStep with: skip_traffic_update: true - name: Google Cloud Run Traffic Shift 20 id: googleCloudRunTrafficShift20 template: uses: googleCloudRunTrafficShiftStep with: metadata: - name: Google Cloud Run Traffic Shift 100 id: googleCloudRunTrafficShift100 template: uses: googleCloudRunTrafficShiftStep with: metadata: rollback: - group: steps: - name: Google Cloud Run Rollback id: googleCloudRunRollbackStep template: uses: googleCloudRunRollbackStep id: googleCloudRunCanaryRollback name: Google Cloud Run Canary Rollback on-failure: errors: all action: stage-rollback ``` *** ### AWS Lambda steps Lambda steps run inside a `runtime.kubernetes` block that routes execution through a containerized runner on your delegate cluster. All service configuration (function definition path, alias path) and infrastructure configuration (AWS connector, region) are resolved automatically from the stage context — Lambda steps do not take those as explicit `with:` inputs. #### AWS Lambda Rolling Deploy Template ID: `awsLambdaRollingDeployStep` Publishes a new Lambda function version and immediately routes all traffic to it. When the service includes an `AwsLambdaFunctionAliasDefinition` manifest, the step also updates the named alias to point to the new version at 100% weight. **Output variables** | Variable | Expression | Description | | -------------- | ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | | `functionName` | `<+pipeline.stages..steps.awsLambdaRollingDeployStep.output.outputVariables.functionName>` | Name of the deployed function. | | `version` | `<+pipeline.stages..steps.awsLambdaRollingDeployStep.output.outputVariables.version>` | Version number published by this deployment. | | `runtime` | `<+pipeline.stages..steps.awsLambdaRollingDeployStep.output.outputVariables.runtime>` | Lambda runtime identifier. Empty for ECR image functions. | | `functionArn` | `<+pipeline.stages..steps.awsLambdaRollingDeployStep.output.outputVariables.functionArn>` | Full ARN of the deployed function version. | ```yaml steps: - name: AWS Lambda Rolling Deploy id: awsLambdaRollingDeployStep template: uses: awsLambdaRollingDeployStep ``` *** #### AWS Lambda Rolling Rollback Template ID: `awsLambdaRollingRollbackStep` Restores the Lambda function to the version from the last successful rolling deployment. When the original deploy updated an alias, rollback also repoints the alias to the previous version. Harness adds this step automatically to the rollback section of a rolling stage. ```yaml rollback: - group: steps: - name: AWS Lambda Rolling Rollback id: awsLambdaRollingRollbackStep template: uses: awsLambdaRollingRollbackStep ``` *** #### AWS Lambda Canary Deploy Template ID: `awsLambdaCanaryDeployStep` Publishes a new Lambda function version and creates or updates a weighted alias to begin splitting traffic between the previous version and the new one. Use this as the first step in a canary stage, followed by one or more Traffic Shift steps. For ZIP artifact functions (S3, Artifactory, Nexus), the service must include an `AwsLambdaFunctionAliasDefinition` manifest — the step reads it to determine the alias name. For ECR image functions, no alias manifest is required; the step manages the alias automatically. **Output variables** (auto-populate the Traffic Shift step inputs) | Variable | Expression | Description | | -------------- | ------------------------------------------------------------------------------ | -------------------------------------------- | | `functionName` | `<+stage.steps.awsLambdaCanaryDeployStep.output.outputVariables.functionName>` | Name of the deployed function. | | `version` | `<+stage.steps.awsLambdaCanaryDeployStep.output.outputVariables.version>` | Version number published by this deployment. | ```yaml steps: - name: AWS Lambda Canary Deploy id: awsLambdaCanaryDeployStep template: uses: awsLambdaCanaryDeployStep ``` *** #### AWS Lambda Traffic Shift Template ID: `awsLambdaTrafficShiftStep` Updates the weighted alias to route a specified percentage of invocations to the new function version. Add multiple Traffic Shift steps to progressively increase traffic. | Input | Type | Description | | -------------------- | ------ | -------------------------------------------------------------------------------------- | | `traffic_percentage` | string | Percentage of traffic to route to the new version. Must be between `"0"` and `"100"`. | | `function_name` | string | Lambda function name. Auto-populated from the Canary Deploy step output. | | `function_version` | string | Version number of the new function. Auto-populated from the Canary Deploy step output. | ```yaml steps: - name: AWS Lambda Traffic Shift 10 id: awsLambdaTrafficShift10 template: uses: awsLambdaTrafficShiftStep with: traffic_percentage: "10" function_name: <+stage.steps.awsLambdaCanaryDeployStep.output.outputVariables.functionName> function_version: <+stage.steps.awsLambdaCanaryDeployStep.output.outputVariables.version> - name: AWS Lambda Traffic Shift 100 id: awsLambdaTrafficShift100 template: uses: awsLambdaTrafficShiftStep with: traffic_percentage: "100" function_name: <+stage.steps.awsLambdaCanaryDeployStep.output.outputVariables.functionName> function_version: <+stage.steps.awsLambdaCanaryDeployStep.output.outputVariables.version> ``` The `function_name` and `function_version` inputs are wired to the Canary Deploy step's output variables. Do not change these unless you are using a custom step to publish the version. To add an intermediate shift (for example, 50%), copy the 10% step, change the `id`, and set `traffic_percentage: "50"`. *** #### AWS Lambda Canary Rollback Template ID: `awsLambdaCanaryRollbackStep` Resets the weighted alias to route 100% of traffic back to the previous function version and deletes the newly published version. Harness adds this step automatically to the rollback section of a canary stage. It applies to both ZIP and ECR image canary deployments. ```yaml rollback: - group: steps: - name: AWS Lambda Canary Rollback id: awsLambdaCanaryRollbackStep template: uses: awsLambdaCanaryRollbackStep ``` *** #### AWS Lambda stage runtime block All Lambda steps require the stage to declare a `runtime.kubernetes` block that provides the containerized execution environment. This is a stage-level setting, not a per-step setting. ```yaml stages: - name: Stage id: stage service: environment: id: deploy-to: steps: # ... your Lambda steps here runtime: kubernetes: namespace: connector: automount-service-token: true pull: always ``` *** ### AWS SAM steps AWS SAM stages run three steps automatically: a Docker in Docker background step, an AWS SAM Build step, and an AWS SAM Deploy step. All AWS connector and region values are resolved from the stage infrastructure definition. *** #### Docker in Docker A background step that starts a Docker daemon inside the Kubernetes pod for the duration of the stage. SAM Build connects to this daemon when `--use-container` is set in the build command options. ```yaml - name: Docker in Docker id: dind background: shell: sh container: image: docker:dind connector: account.harnessImage privileged: true pull: always ``` *** #### AWS SAM Build Template ID: `awsSamBuildStep` Runs `sam build` against the SAM directory downloaded from the service manifest. The AWS connector and region are resolved from the infrastructure definition. | Input | Type | Description | | --------------------- | ------ | ---------------------------------------------------------------------------------------------------------- | | `connector` | string | Harness AWS connector ID. Resolved from infrastructure definition. | | `region` | string | AWS region, for example `us-east-1`. Resolved from infrastructure definition. | | `stack` | string | CloudFormation stack name. | | `cmd_opts` | string | Flags passed to `sam build`. Default: `--use-container`. | | `template_file_path` | string | Override the template file path relative to the SAM directory root. Defaults to the service configuration. | | `pre_execute_command` | string | Shell command to run before `sam build`, for example `npm install`. | | `working_dir` | string | Working directory for the build. | | `docker_retry_count` | string | Number of times to poll for a running Docker daemon before starting. Default: `3`. | | `registry_url` | string | Registry URL for pulling the Lambda build container. | | `registry_username` | string | Username for the container registry. | | `registry_pwd` | string | Secret reference for the container registry password. | | `command_timeout` | string | Maximum time the step can run, for example `10m`. | | `log_level` | string | Logging verbosity. Default: `info`. | ```yaml - name: AWS SAM Build id: awsSamBuildStep template: uses: awsSamBuildStep with: connector: region: stack: cmd_opts: --use-container docker_retry_count: '3' registry_url: https://index.docker.io/v2/ registry_username: registry_pwd: ``` *** #### AWS SAM Deploy Template ID: `awsSamDeployStep` Packages the build output to S3 and creates or updates the CloudFormation stack. Waits for the stack to reach a stable state and prints CloudFormation events and stack outputs to the step log. | Input | Type | Description | | --------------------- | ------ | -------------------------------------------------------------------------------------------------------------------- | | `connector` | string | Harness AWS connector ID. Resolved from infrastructure definition. | | `region` | string | AWS region. Resolved from infrastructure definition. | | `stack` | string | CloudFormation stack name to create or update. Required. | | `cmd_opts` | string | Flags passed to `sam deploy`, for example `--capabilities CAPABILITY_IAM --resolve-s3 --no-fail-on-empty-changeset`. | | `template_file_path` | string | Override the template file path relative to the SAM directory root. Defaults to the service configuration. | | `pre_execute_command` | string | Shell command to run before `sam deploy`. | | `working_dir` | string | Working directory for the deploy. | | `registry_url` | string | Registry URL, for example `https://index.docker.io/v2/`. | | `registry_username` | string | Username for the container registry. | | `registry_pwd` | string | Secret reference for the container registry password. | | `command_timeout` | string | Maximum time the step can run, for example `10m`. | | `log_level` | string | Logging verbosity. Default: `info`. | ```yaml - name: AWS SAM Deploy id: awsSamDeployStep template: uses: awsSamDeployStep with: connector: region: stack: cmd_opts: --capabilities CAPABILITY_IAM --resolve-s3 --no-fail-on-empty-changeset registry_url: https://index.docker.io/v2/ registry_username: registry_pwd: ``` *** #### AWS SAM complete stage YAML Complete reference YAML for an AWS SAM stage using the unified platform pipeline format. ```yaml stages: - name: SAM stage id: sam_stage service: environment: id: deploy-to: steps: - name: Docker in Docker id: dind background: shell: sh container: image: docker:dind connector: account.harnessImage privileged: true pull: always - name: AWS SAM Build id: awsSamBuildStep template: uses: awsSamBuildStep with: connector: region: stack: cmd_opts: --use-container docker_retry_count: '3' registry_url: https://index.docker.io/v2/ registry_username: registry_pwd: - name: AWS SAM Deploy id: awsSamDeployStep template: uses: awsSamDeployStep with: connector: region: stack: cmd_opts: --capabilities CAPABILITY_IAM --resolve-s3 --no-fail-on-empty-changeset registry_url: https://index.docker.io/v2/ registry_username: registry_pwd: runtime: kubernetes: namespace: connector: automount-service-token: true pull: always on-failure: errors: all action: stage-rollback timeout: 20m shared-paths: - /var/lib/docker - /var/run ``` *** ### Serverless Lambda steps #### Serverless Package Template ID: `serverlessPackageStep` Runs `serverless package` to bundle Lambda functions and prepare the stack template for upload to S3. Runs before the Deploy step. Harness adds this step automatically when you select the **Serverless Deployment With Rollback** strategy. | Input | Type | Description | | -------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------- | | `container_registry` | string | Connector to the registry that hosts the step image. | | `image` | string | The `harness/serverless-plugin` image and tag, for example `harness/serverless-plugin:nodejs20.x-3.39.0-1.1.0-beta-linux-amd64`. | | `cmd_opts` | string | Additional flags appended to `serverless package`, for example `--verbose`. | | `pre_exec_cmd` | string | Shell command that runs before the step logic. | | `env` | object | Environment variables injected into the container. | ```yaml steps: - name: Package uses: serverlessPackageStep@1.0.0 with: container_registry: image: harness/serverless-plugin:nodejs20.x-3.39.0-1.1.0-beta-linux-amd64 ``` *** #### Serverless Deploy Template ID: `serverlessDeployStep` Runs `serverless deploy` to create or update the AWS stack and activate the new Lambda function versions. Before deploying, captures the current stack state automatically for use by the Rollback step. Harness adds this step automatically when you select the **Serverless Deployment With Rollback** strategy. | Input | Type | Description | | -------------------- | ------ | ------------------------------------------------------------------------------------------------------- | | `container_registry` | string | Connector to the registry that hosts the step image. | | `image` | string | The `harness/serverless-plugin` image and tag. Use the same image as the Package step. | | `cmd_opts` | string | Additional flags appended to `serverless deploy`, for example `--aws-s3-accelerate`. | | `pre_exec_cmd` | string | Shell command that runs before the step logic. | | `env` | object | Environment variables injected into the container. For Serverless V4, add `SERVERLESS_ACCESS_KEY` here. | ```yaml steps: - name: Deploy uses: serverlessDeployStep@1.0.0 with: container_registry: image: harness/serverless-plugin:nodejs20.x-3.39.0-1.1.0-beta-linux-amd64 cmd_opts: --aws-s3-accelerate env: SERVERLESS_ACCESS_KEY: <+secrets.getValue("serverless_access_key")> ``` *** #### Serverless Rollback Template ID: `serverlessRollbackStep` Restores the AWS stack to the state captured before the Deploy step ran. Harness adds this step to the rollback section of the stage automatically. Toggle **Rollback** in the stage execution view to see and configure it. | Input | Type | Description | | -------------------- | ------ | ------------------------------------------------------------------------------------- | | `container_registry` | string | Connector to the registry that hosts the step image. | | `image` | string | The `harness/serverless-plugin` image and tag. Use the same image as the Deploy step. | | `pre_exec_cmd` | string | Shell command that runs before the step logic. | | `env` | object | Environment variables injected into the container. | ```yaml rollback: - group: steps: - name: Rollback uses: serverlessRollbackStep@1.0.0 with: container_registry: image: harness/serverless-plugin:nodejs20.x-3.39.0-1.1.0-beta-linux-amd64 ``` Full stage example with all three steps and the rollback failure strategy: ```yaml stages: - name: Deploy Lambda service: environment: id: deploy-to: steps: - name: Package uses: serverlessPackageStep@1.0.0 with: container_registry: image: harness/serverless-plugin:nodejs20.x-3.39.0-1.1.0-beta-linux-amd64 - name: Deploy uses: serverlessDeployStep@1.0.0 with: container_registry: image: harness/serverless-plugin:nodejs20.x-3.39.0-1.1.0-beta-linux-amd64 rollback: - group: steps: - name: Rollback uses: serverlessRollbackStep@1.0.0 with: container_registry: image: harness/serverless-plugin:nodejs20.x-3.39.0-1.1.0-beta-linux-amd64 on-failure: errors: all action: stage-rollback runtime: kubernetes: namespace: connector: ``` *** ### Infrastructure inheritance Steps automatically inherit infrastructure settings from the stage infrastructure configuration. **Kubernetes and Helm** | Inherited value | CEL expression | JEXL expression | | --------------- | ----------------------------- | --------------------------- | | Kubeconfig path | `${{infra.kube_config_path}}` | `<+infra.kube_config_path>` | | Namespace | `${{infra.namespace}}` | `<+infra.namespace>` | | Release name | `${{infra.releaseName}}` | `<+infra.releaseName>` | **AWS Lambda** | Inherited value | CEL expression | JEXL expression | | --------------- | ------------------------- | ----------------------- | | AWS connector | `${{infra.connectorRef}}` | `<+infra.connectorRef>` | | AWS region | `${{infra.region}}` | `<+infra.region>` | **AWS SAM** | Inherited value | CEL expression | JEXL expression | | --------------- | ------------------------- | ----------------------- | | AWS connector | `${{infra.connectorRef}}` | `<+infra.connectorRef>` | | AWS region | `${{infra.region}}` | `<+infra.region>` | Override these values in individual step inputs when you need to target a different connector or region within the same stage. {% @harness-feedback/feedback %}