Helm basic deployment
A Helm basic deployment runs helm upgrade --install against the target cluster in a single phase. Harness fetches the chart, merges values files, executes the Helm command, and waits for all workloads to reach steady state. If the deployment fails, Harness rolls back automatically by running helm rollback.
Before you begin
- A Helm service: Go Helm services set up a service with a chart source and values files.
- A Helm infrastructure: Go Helm infrastructure connect a cluster and namespace.
- A Harness delegate in the target cluster: The delegate runs Helm commands against your cluster.
- Runtime configuration: Every Helm stage requires a
runtimeblock specifying the connector and namespace. Go Helm runtime configuration understand the required fields.
How basic deployments work
A Helm basic deployment applies your chart directly to all instances in the target namespace in one phase. Harness runs helm upgrade --install, which creates a new release if one does not exist or upgrades it in place if it does. Helm handles revision tracking natively; each upgrade increments the release revision, so rollback targets a specific numbered revision rather than a separate manifest copy.
Use a basic deployment when:
- You want the simplest, single-phase delivery path with automatic rollback on failure.
- Your application does not require canary traffic validation or blue-green isolation before full promotion.
- You are updating a chart that is safe to apply immediately to all instances.
Pipeline YAML
View complete basic stage YAML
pipeline:
name: helm-native-basic
identifier: helm_native_basic
clone:
disabled: true
stages:
- name: basic-deploy
id: basic_deploy
service:
type: helm
items:
- <your-service-id>
environment:
id: <your-environment-id>
deploy-to: <your-infrastructure-id>
steps:
- name: Helm Basic Deploy
id: helmBasicDeployStep
template:
uses: helmBasicDeployStep
rollback:
- group:
steps:
- name: Helm Rollback
id: helmRollbackStep
template:
uses: helmRollbackStep
id: helmBasicRollback
name: Helm Basic Rollback
on-failure:
errors: all
action: stage-rollback
runtime:
kubernetes:
namespace: <target-namespace>
connector: <your-kubernetes-connector-id>
delegate: <your-delegate-name>
Go Helm runtime configuration understand the required runtime block and how to find your connector and namespace values.
Configure basic stage
Select basic strategy
When creating a new Helm stage, the strategy wizard asks you to choose a deployment strategy. Select Basic from the list.
Harness automatically adds one step to the stage canvas.
Configure Helm Basic Deploy step
Click Helm Basic Deploy in the stage canvas to open its configuration panel.
The following fields are available:
| Parameter | Description | Default |
|---|---|---|
| Name | Display name for the step in the pipeline canvas. | Helm Basic Deploy |
| Ignore Failed Release History | When true, proceeds with deployment even if the previous Helm release has a failed status. Use this to recover from a broken release without manual cleanup. | false |
| Skip Steady State Check | When true, skips waiting for all deployed workloads to reach steady state after helm upgrade --install. | false |
| Run Chart Tests | When true, runs helm test against the release after a successful deployment. | false |
| Environment Variables | Additional environment variables to pass into the Helm plugin execution. | none |
| Command Flags | Additional flags to append to the helm upgrade command, for example --atomic or --cleanup-on-fail. | none |
Select + More options to access additional fields:
| Parameter | Description | Default |
|---|---|---|
| Skip Cleanup | When true, skips cleanup of a failed first release. Use this to inspect resources left behind after a failed initial install. | false |
| Print Manifests | When true, logs the full rendered chart manifest to the step output with secrets redacted. | false |
| Server-Side Rendering | When true, passes --server to helm template so manifests are rendered against the live cluster rather than locally. | false |
Go Helm Basic Deploy step reference review the full field reference.
The basic strategy adds a single step by default. You can insert approval, verification, or notification steps anywhere in the stage before or after the Helm Basic Deploy step.
Rollback
If the Helm Basic Deploy step fails, Harness runs the rollback group automatically. The rollback group contains one step: Helm Rollback. Click it in the rollback canvas to configure it.
The following fields are available:
| Parameter | Description | Default |
|---|---|---|
| Name | Display name for the rollback step. | Helm Rollback |
| Skip Steady State Check | When true, skips waiting for workloads to reach steady state after helm rollback. | false |
| Run Chart Tests | When true, runs helm test after a successful rollback. | false |
| Environment Variables | Additional environment variables to pass into the rollback execution. | none |
| Command Flags | Additional flags to append to the helm rollback command. | none |
The step retrieves the previous release revision from Helm's built-in release history and runs helm rollback <release-name> <previous-revision>.
Go Helm Rollback step reference review the full reference.
What happens on execution
When you run a pipeline with a basic stage, the execution view shows the full step sequence. A successful run looks like this:

The execution includes setup steps Harness runs automatically before the configured step:
- Initialize: Provisions and prepares the execution environment for the stage.
- Service: Initializes service configurations, variables, config files, artifact details, and manifest details.
- Infrastructure: Initializes the infrastructure deployment target, variables, and connectivity.
- Harness Manifest: Reviews and finalizes manifests with resolved variables and inputs, preparing for deployment.
- Resource Constraint: Checks infrastructure availability for concurrent deployments. Skipped if no resource constraints are configured.
The configured step follows.
Helm Basic Deploy step in execution
The step executes the following actions internally:
-
Input validation: Resolves and prints all input parameters, including release name, chart path, values files, Helm flags, namespace, and credentials. Prints
PARAM VALIDATION: All looks goodbefore proceeding. -
Helm version check: Detects the Helm CLI version available on the delegate. Harness uses
helm3by default. -
Release history check: Runs
helm historyto inspect the current state of the release. If no release exists, Harness proceeds with a fresh install. If Ignore Failed Release History is enabled and the last release shows a failed status, Harness clears it before upgrading. -
Helm upgrade: Runs
helm upgrade --install <release-name> <chart-path>with all resolved values files and command flags. Helm creates a new revision on the release. -
Steady state check: Polls the cluster until all Deployment, StatefulSet, and DaemonSet workloads in the release reach ready status. Bypassed if Skip Steady State Check is enabled.
Next steps
- Go Helm canary deployment deploy to a subset of instances first and validate before promoting.
- Go Helm blue-green deployment route production traffic between two full release environments.
- Go Helm Basic Deploy step reference review all step settings.