Deploy Helm Charts
Spinnaker surfaces a “Bake (Manifest)” stage to turn templates into manifests
with the help of a templating engine.
Helm
relies on the helm template
command.
For more details, see helm template --help
.
Note: This stage is intended to help you package and deploy applications that you own, and are actively developing and redeploying frequently. It is not intended to serve as a one-time installation method for third-party packages. If that is your goal, it’s arguably better to call
helm install
once when bootstrapping your Kubernetes cluster.
Note: Make sure that you have configured artifact support in Spinnaker first. All Helm charts are fetched/stored as artifacts in Spinnaker. Read more in the reference pages .
Configure the “Bake (Manifest)” stage
When configuring the “Bake (Manifest)” stage using a Helm (Helm2 or Helm3) render engine, you can specify the following:
The release name (required)
The Helm release name for this chart. This determines the name of the artifact produced by this stage.
Note: this name will override any changes you make to the name in the Produces Artifacts section.
The template artifact (required)
The Helm chart that you will be deploying, stored remotely as a
.tar.gz
archive. You can produce this by runninghelm package /path/to/chart
. For more details,helm package --help
.The release namespace (optional)
The Kubernetes namespace to install release into. If parameter is not specified default namespace will be used.
Note: Not all Helm charts contain namespace definitions in their manifests. Make sure that your manifests contain the following code:
metadata:
namespace: {{ .Release.Namespace }}
Helm chart file path (optional)
Helm chart file path is only relevant (and visible) when the template artifact is a git/repo artifact. It specifies the directory path to Chart.yaml in the git repo. If absent, spinnaker looks for Chart.yaml in the root directory of the git repo.
Given: A git repo where your
Chart.yaml
is in:sub/folder/Chart.yml
Then:helmChartFilePath: "sub/folder/"
Note: Leading slashes will not work in
helmChartFilePath
.
Zero or more override artifacts (optional)
The files passed to
--values
parameter in thehelm template
command. Each is a remotely stored artifact representing a Helm Value File .Statically specified overrides
The set of static key/value pairs that are passed as
--set
parameters to thehelm template
command.
As an example, we have a fully configured Bake (Manifest) stage below:

Notice that in the “Produces Artifacts” section, Spinnaker has automatically
created an embedded/base64
artifact that is bound when the stage
completes, representing the fully baked manifest set to be deployed downstream.

If you are programatically generating stages, here is the JSON representation of the same stage from above:
{
"type": "bakeManifest",
"templateRenderer": "HELM2",
"name": "Bake nginx helm template",
"outputName": "nginx",
"inputArtifacts": [
{
"account": "gcs",
"id": "template-id"
},
{
"account": "gcs",
"id": "value-id"
}
],
"overrides": {
"replicas": "3"
},
"expectedArtifacts": [
{
"defaultArtifact": {},
"id": "baked-template",
"matchArtifact": {
"kind": "base64",
"name": "nginx",
"type": "embedded/base64"
},
"useDefaultArtifact": false
}
]
}
Helmfile
In addition to standard helm deployments, Spinnaker supports Helmfile as a templating engine. Current supported version can be found here .
Configuring a Helmfile deployment follows the specification for standard helm chart deployments (defined above) with one exception - helmChartFilePath
is substituted for helmfileFilePath
and is specified as follows:
helmfile file path (optional)
helmfile file path is only relevant (and visible) when the template artifact is a git/repo artifact. It specifies the directory path to helmfile.yaml in the git repo. If absent, spinnaker looks for helmfile.yaml in the root directory of the git repo.
Given: A git repo where your
helmfile.yaml
is in:sub/folder/helmfile.yml
Then:helmfileFilePath: "sub/folder/"
Note: Leading slashes will not work in
helmfileFilePath
.
Configure a downstream deployment
Now that your manifest set has been baked by Helm, configure a downstream stage (in the same pipeline or in one triggered by this pipeline) your “Deploy (Manifest)” stage to deploy the artifact produced by the “Bake (Manifest)” stage as shown here:

Note: Make sure to select “embedded-artifact” as the artifact account for your base64 manifest set. This is required to translate the manifest set into the format required by the deploy stage.
When this stage runs, you can see every resource in your Helm chart get deployed at once:

Other Templating Engines
In addition to Helm, Spinnaker also supports Kustomize as a templating engine. For more information, see Using Kustomize for Manifests .