Skip to main content

Helm services

Last updated on

A Harness service for Native Helm represents the application you want to deploy. It holds the Helm chart source, values files, artifact sources, and sidecar definitions that Harness uses to run the Helm release.

Services are independent of pipelines; configure one once and reuse it across stages and pipelines.

Create a Helm service​

  1. Go to Deployments, expand the drop-down, and select Services under Resources.
  2. Select Create Service.
  3. In the Create service panel, select Native Helm from the Deployment Target drop-down.
  4. Harness auto-generates a name and ID. You can change both.
  5. Under Storage, choose Inline (Harness stores the service configuration) or a Git repository.
  6. Configure manifests, additional override files, artifact sources, and sidecars as described in the sections below.
  7. Expand Advanced to add config files, variables, and service hooks.
  8. Select Create.

Add a manifest​

Select + Add under Manifest. Native Helm services support one manifest type: Helm Chart.

Helm Chart​

Use this type for a Helm chart stored in a Harness Code repository, Git provider, HTTP Helm repository, S3 bucket, or GCS bucket. The available fields vary by source.

Common fields (all sources)

FieldDescription
IDA unique identifier for this manifest within the service.
Helm VersionSelect V3.

Harness Code, GitHub, Git, GitLab, Bitbucket, Azure Repos

FieldDescription
SourceSelect the Git provider. Requires a Harness connector for that provider.
RepositoryThe repository that contains your chart.
FetchSelect Branch to track a branch head, or Commit to pin to a specific SHA.
Branch / CommitThe branch name or commit SHA.
Chart PathThe path to the chart folder from the root of the repository. Harness expects a Chart.yaml at this path.

Amazon S3

FieldDescription
ConnectorA Harness AWS connector with s3:GetObject and s3:ListBucket permissions.
RegionThe AWS region where the bucket is located.
Bucket NameThe name of the S3 bucket.
Folder PathThe path to the chart folder or .tgz file within the bucket.

Google Cloud Storage

FieldDescription
ConnectorA Harness GCP connector with Storage Object Viewer role on the bucket.
Bucket NameThe name of the GCS bucket.
Folder PathThe path to the chart folder or .tgz file within the bucket.

HTTP Helm

FieldDescription
ConnectorA Harness HTTP Helm connector pointing to your Helm repository.
Chart NameThe name of the chart in the repository.
Chart VersionThe chart version to deploy. Supports a fixed value, runtime input, or an expression.

Expand Advanced under the manifest form to add values override files. Harness merges these at render time; later files take priority over earlier ones.

Add an additional override file​

Override files let you layer values on top of your base chart at deploy time without modifying the chart itself. Useful for environment-specific configuration.

Select + Add under Additional override file. Set Type to Values YAML, choose a source, and fill in the source-specific fields (same set as the manifest form). When an override file is present, its values take priority over matching keys in the chart's default values.yaml.

You can add multiple override files. Harness merges them in the order listed; later files take priority over earlier ones.

Add an artifact source​

Artifact sources define the container image that Harness injects into your chart at deploy time. Reference the primary artifact image in your values.yaml:

  • CEL: ${{artifacts.primary.image}}
  • JEXL: <+artifacts.primary.image>

If you hardcode the image directly in your chart templates, Harness ignores any artifact sources defined in the service.

Select + Add under Artifact source, choose a type, then configure the connector and image details.

FieldDescription
ConnectorA Harness Docker Registry connector.
Image PathThe full image path, for example library/nginx or myorg/myapp. Wildcards are not supported.
TagThe image tag. Supports a fixed value, runtime input, or a Harness expression.
DigestOptional. Pin the image to a specific digest or SHA value.

Add a sidecar​

Sidecar definitions specify images for containers that run alongside your main application container. Select + Add under Sidecar and configure an artifact source using the same registry types listed above.

The sidecar form requires an ID that uniquely identifies it within the service. Reference the sidecar image in your values.yaml:

  • CEL: ${{artifacts.sidecars.<sidecar-id>.image}}
  • JEXL: <+artifacts.sidecars.<sidecar-id>.image>

Advanced service options​

Expand Advanced on the service to access options that apply across the entire service:

  • Config Files: Attach configuration files such as properties files, certificates, or scripts. Supported sources: Harness Code, GitHub, Git, Bitbucket, and GitLab. Harness makes these available to the delegate at deploy time.
  • Variables: Define service-level variables to use in values files and pipeline expressions. Variables support fixed values, runtime inputs, and expressions. Reference them as:
    • CEL: ${{serviceVariables.<name>}}
    • JEXL: <+serviceVariables.<name>>
  • Service Hooks: Run scripts at specific points in the service lifecycle. Configure a Store Type (Inline), Hook Type (Pre Hook or Post Hook), Actions (which lifecycle event triggers the hook), and the script Content.

Use an existing service​

When you configure a stage, select Existing in the Choose service panel. Only Native Helm services appear when the stage deployment type is Native Helm.

Next steps​

Last updated on