How can I ship a Helm application as a Replicated appliance?


If I have an existing Helm application, what’s the easiest way to get this created as a Replicated YAML file that will be accepted in and packaged as a Replicated application?


Replicated supports any Kubernetes application, but doesn’t currently support Helm applications natively (and likely won’t as the V3 changes to Helm will likely lead to a more compatible Helm that doesn’t require native support). To ship a Helm application on Replicated, you’ll need to render the Helm charts to get plain Kubernetes YAML.

Create a Replicated values.yaml file

For each chart you need to ship, create a values.yaml file that contains static values for any items that your enterprise customers should not be configuring, and Replicated template functions for configurable items.

To explain this, let’s take a look at a sample, public chart. The Sentry chart is available as a stable chart, and the values file is hosted at There are several values in here that shouldn’t be configured by an enterprise customers, and these have sane defaults already listed. But a few of these values should be configurable from the Replicated Admin Console, such as GITHUB_APP_ID and GITHUB_API_SECRET. Using the Replicated Template Functions, provide references to config items here:

    - name: GITHUB_APP_ID
      value: '{{repl ConfigOption "github_app_id"}}'
      value: '{{repl ConfigOption "github_api_secret"}}'

The full example configured YAML is here.

Render the Helm chart using this values.yaml

Next, using the Helm CLI, render the Helm chart to a dynamic namespace (configured by Replicated at install time), using the values.yaml file just created:

$ helm template --namespace '{{repl Namespace}}' -f ./values.yaml path/to/chart > replicated.yaml

Create Replicated YAML

Each separate document will be separated with:

# Source: sentry/charts/redis/templates/secrets.yaml

To make this compatible with Replicated, we need to insert a line between these two lines, everywhere they appear:

$ sed -i -e 's/---/---\\\n# kind: scheduler-kubernetes/g' replicated.yaml

Add Config items

Finally, add a config section to this YAML file that defines the ConfigOption items in your Kubernetes YAML.


What are best practices around excluding a helm dependency, since this occurs post-render?

That is, if I ship an application where in helm there’s an optional dependency, such as a database.
In Replicated I’d want to choose whether to deploy the database or connect to an external one. So far the only thing I can think of is setting replicas to 0 but still creating the deployment.


Replicated supports templating in Kubernetes YAML, so this can be done after the chart is rendered. You can optionally include or exclude components using the ConfigOptionEquals function:

# kind: replicated

- name: db_settings_type
  title: Database Type
  description: Would you like to run an internal database or provide your own?
  - name: db_type
    type: select_one
    default: embedded
    - name: embedded
      title: Embedded
    - name: external
      title: External


# kind: scheduler-kubernetes

{{repl if ConfigOptionEquals "db_type" "embeded"}}
  ... kubernetes database yaml...
{{repl end}}