I'm connected to a cluster which has a release, from a chart, but it was installed by someone else who I think used a tweaked, locally-stored chart.

I don't have access to their original chart/repo. Is there a way I can retrieve it from the cluster, so I can tweak/amend, and re-install it?

Or, can I find the URL of the original repo that was used? The chart name is wordpress-0.6.0, but that's of no use, since it's the same as the "official"/original one.

  • is there a code repository for your infrastructure code? Commented Jun 27, 2018 at 3:55
  • There was, but it was a minor project, and the person/people in question are no longer here - I can't find it Commented Jun 27, 2018 at 10:18
  • Are they willing to do some consulting for their previous employer? An hour of their time could save you days of fruitless searching.
    – chicks
    Commented Jun 27, 2018 at 16:56
  • What does your IT department do with old laptops during off-boarding?
    – chicks
    Commented Jun 27, 2018 at 16:57

5 Answers 5


You can use helm get manifest <RELEASE_NAME> to fetch the kubernets manifests and you can use helm get values <RELEASE_NAME> to get the values.yaml from the cluster. But I don't think there is any way to get the chart files back. Sorry.

PS: Please replace <RELEASE_NAME> with your release name.


To get the package to connect to the helm kubernetes cluster and run helm fetch which will

pull down the char from a repository and (optionally) unpack it in the local directory.

use helm fetch --help to see formating options

Use helm --help to see available commands.

Available Commands: completion Generate autocompletions script for the specified shell (bash or zsh) create create a new chart with the given name delete given a release name, delete the release from Kubernetes dependency manage a chart's dependencies diff Preview helm upgrade changes as a diff fetch download a chart from a repository and (optionally) unpack it in local directory get download a named release history fetch release history home displays the location of HELM_HOME init initialize Helm on both client and server inspect inspect a chart install install a chart archive lint examines a chart for possible issues list list releases package package a chart directory into a chart archive plugin add, list, or remove Helm plugins repo add, list, remove, update, and index chart repositories reset uninstalls Tiller from a cluster rollback roll back a release to a previous revision search search for a keyword in charts serve start a local http web server status displays the status of the named release template locally render templates test test a release upgrade upgrade a release verify verify that a chart at the given path has been signed and is valid version print the client/server version information

  • The cluster isn't a repository - are you sure that would work? Commented Jun 28, 2018 at 21:30
  • 1
    Your right that won't work you don't have anything. Something you might be able to do, which I haven't tried is take the chart you do have and do a diff and see what changes would be applied. That would give you the difference I believe. I can't try that right now. Commented Jun 29, 2018 at 0:00

You can download the latest stable or unstable version from the helm repo. First, You need to verify the remote helm repo URL below command.

# helm repo list

For stable repo URL, you will get output like

NAME            URL
stable          https://kubernetes-charts.storage.googleapis.com

It refers to https://github.com/helm/charts/tree/master/stable

Now I will tell you to download the chart from the repo URL.

helm fetch stable/wordpress --version 0.6.0

For the extracted copy of the chart

 helm fetch stable/wordpress --version 0.6.0 --untar

The above command will download the chart in your current directory.


Below worked for me in helm-3:

  1. Get the name of the release of which you want to get charts using helm list
  2. helm get manifest [release name]

You can write this to some text file instead of stdout and separate the charts. ( Cheers🥂 )

Note: You will need to create persistedVolumes & PVC's. Those are not exported using above command


I know this is an old question, but since there aren't yet any correct answers, and it's likely more people will face this issue in the future, here's my 2 cents:

You cannot download an original chart from a Kubernetes cluster, but what you can do is get all of the information that would be in said chart.

Helm creates a release secret (or configMap in Helm v2) which contains pretty much all information which was in the original chart. This is encoded, but we can make this readable.

First, go into the namespace where your install is, and run

kubectl get secrets

There will be a secret similar to this:

sh.helm.release.v1.<chart name>.v1

Provided you have sufficient access rights, you can access the contents of this secret. However, the contents have been Base64 encoded twice, and also gzipped. Hence, in order to create a readable file with all of the information you need, you can run this command:

kubectl get secret sh.helm.release.v1.<chart name>.v1 -o json | jq .data.release | tr -d '"' | base64 --decode | base64 --decode | gzip -d > output.json

Let's break this down a little.

kubectl get secret gets the secret from the cluster

sh.helm.release.v1.<chart name>.v1 is the secret name we got by running kubectl get secrets before

-o json ensures we get a json output

jq .data.release selects the part from the json output we actually want

tr -d '"' deletes unnecessary " characters for further processing

base64 --decode decodes the base64 encoded data. we run this twice

gzip -d unzips the resulting file

>output.json ensures we write the resulting data to a file called output.json for easier reading (otherwise you're looking at dozens to hundreds of lines of output on the terminal)

This results in a json file something like this:

    "name": "chartName",
    "info": {
        "first_deployed": "2023-04-04T12:53:46.750501771Z",
        "last_deployed": "2023-04-04T13:16:24.683772+02:00",
        "deleted": "",
        "description": "Upgrade complete",
        "status": "deployed",
        "notes": "this is a beautiful app for beautiful people"
    "chart": {
        "metadata": {
            "name": "chartname",
            "home": "link-to-homepage.com",
            "sources": [
            "version": "1.0.0",
            "description": "this beautiful chart deploys a beautiful app for beautiful people",
            "maintainers": [
                    "name": "john doe",
                    "email": "[email protected]"
                    "name": "jane doe",
                    "email": "[email protected]"
            "icon": "link-to-icon.png",
            "apiVersion": "v2",
            "appVersion": "v1.0.0",
            "annotations": {
                "artifacthub.io/license": "Apache-2.0",
            "dependencies": [
                    "name": "foo",
                    "version": "1.0.2",
                    "repository": "link-to-repo"
            "type": "application"
        "lock": null,
        "templates": [
                "name": "templates/configmap.yaml",
                "data": "abc123"
                "name": "templates/ingress.yaml",
                "data": "abc123="
        "values": {
            "foo": "bar"
            "boolean": false

The dependencies refer to Helm charts that the release you're looking at depends on.

The templates: all specify a name and data. These names refer to the files that were originally in the Helm chart templates folder, and the data part is their contents (base64 encoded again).

The values: section specifies whatever was in the Helm chart's values.yaml file.

You can use these dependencies, templates and values to re-create the original Helm chart.

Note this is quite a labour-intensive way of retrieving the information, and it will cost quite a bit of time. However, it is to my knowledge the only way to retrieve this information from a cluster if the original Helm Chart is completely lost.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.