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.

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

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.

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).

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

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

steps:
- name: Google Cloud Run Deploy
  id: googleCloudRunDeployStep
  template:
    uses: googleCloudRunDeployStep

With overrides:

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:

{"status":{"traffic":[{"revisionName":"LATEST","percent":100}]}}

Route all traffic to the latest revision:

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:

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 <service> --to-revisions=<stable-revision>=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:

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:

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):

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):

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:

- name: google-cloud-run
  id: googleCloudRun
  service:
    type: google-cloud-run
    items:
    - <service-id>
  environment:
    items:
    - id: <environment-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: <provide the traffic details>
  - name: Google Cloud Run Traffic Shift 100
    id: googleCloudRunTrafficShift100
    template:
      uses: googleCloudRunTrafficShiftStep
      with:
        metadata: <provide the traffic details>
  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.<stage-id>.steps.awsLambdaRollingDeployStep.output.outputVariables.functionName>	Name of the deployed function.
version	<+pipeline.stages.<stage-id>.steps.awsLambdaRollingDeployStep.output.outputVariables.version>	Version number published by this deployment.
runtime	<+pipeline.stages.<stage-id>.steps.awsLambdaRollingDeployStep.output.outputVariables.runtime>	Lambda runtime identifier. Empty for ECR image functions.
functionArn	<+pipeline.stages.<stage-id>.steps.awsLambdaRollingDeployStep.output.outputVariables.functionArn>	Full ARN of the deployed function version.

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.

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.

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.

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.

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.

stages:
  - name: Stage
    id: stage
    service: <your-service-id>
    environment:
      id: <your-environment-id>
      deploy-to: <your-infrastructure-id>
    steps:
      # ... your Lambda steps here
    runtime:
      kubernetes:
        namespace: <your-delegate-namespace>
        connector: <your-k8s-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.

- 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.

- name: AWS SAM Build
  id: awsSamBuildStep
  template:
    uses: awsSamBuildStep
    with:
      connector: <aws-connector>
      region: <aws-region>
      stack: <cloudformation-stack-name>
      cmd_opts: --use-container
      docker_retry_count: '3'
      registry_url: https://index.docker.io/v2/
      registry_username: <registry-username>
      registry_pwd: <registry-password-secret>

---

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.

- name: AWS SAM Deploy
  id: awsSamDeployStep
  template:
    uses: awsSamDeployStep
    with:
      connector: <aws-connector>
      region: <aws-region>
      stack: <cloudformation-stack-name>
      cmd_opts: --capabilities CAPABILITY_IAM --resolve-s3 --no-fail-on-empty-changeset
      registry_url: https://index.docker.io/v2/
      registry_username: <registry-username>
      registry_pwd: <registry-password-secret>

---

AWS SAM complete stage YAML

Complete reference YAML for an AWS SAM stage using the unified platform pipeline format.

stages:
  - name: SAM stage
    id: sam_stage
    service: <your-service-id>
    environment:
      id: <your-environment-id>
      deploy-to: <your-infrastructure-id>
    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: <aws-connector>
            region: <aws-region>
            stack: <cloudformation-stack-name>
            cmd_opts: --use-container
            docker_retry_count: '3'
            registry_url: https://index.docker.io/v2/
            registry_username: <registry-username>
            registry_pwd: <registry-password-secret>
      - name: AWS SAM Deploy
        id: awsSamDeployStep
        template:
          uses: awsSamDeployStep
          with:
            connector: <aws-connector>
            region: <aws-region>
            stack: <cloudformation-stack-name>
            cmd_opts: --capabilities CAPABILITY_IAM --resolve-s3 --no-fail-on-empty-changeset
            registry_url: https://index.docker.io/v2/
            registry_username: <registry-username>
            registry_pwd: <registry-password-secret>
    runtime:
      kubernetes:
        namespace: <kubernetes-namespace>
        connector: <kubernetes-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.

steps:
  - name: Package
    uses: serverlessPackageStep@1.0.0
    with:
      container_registry: <your-registry-connector>
      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.

steps:
  - name: Deploy
    uses: serverlessDeployStep@1.0.0
    with:
      container_registry: <your-registry-connector>
      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.

rollback:
  - group:
      steps:
        - name: Rollback
          uses: serverlessRollbackStep@1.0.0
          with:
            container_registry: <your-registry-connector>
            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:

stages:
  - name: Deploy Lambda
    service: <your-service-id>
    environment:
      id: <your-environment-id>
      deploy-to: <your-infra-id>
    steps:
      - name: Package
        uses: serverlessPackageStep@1.0.0
        with:
          container_registry: <your-registry-connector>
          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: <your-registry-connector>
          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: <your-registry-connector>
                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: <your-k8s-namespace>
        connector: <your-k8s-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.