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

<p>PS: Please replace <code>&lt;RELEASE_NAME&gt;</code> with your release name.</p>

CC BY-SA 4.0
2018-07-20T15:52:05.507Z
2018-07-20T15:52:05.507Z
Florian Rusch
<p><em>Below worked for me in helm-3:</em></p>
<ol>
<li>Get the name of the release of which you want to get charts using
<code>helm list</code></li>
<li><code>helm get manifest [release name]</code></li>
</ol>
<p>You can write this to some text file instead of stdout and separate the charts. <strong>( Cheers )</strong></p>
<p><strong>Note:</strong> <em>You will need to create persistedVolumes &amp; PVC's. Those are not exported using above command</em></p>

CC BY-SA 4.0
2020-11-26T04:00:41.030Z
2020-11-26T04:00:41.030Z
Mayur Chavan
<p>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.</p>

<pre><code># helm repo list
</code></pre>

<p>For stable repo URL, you will get output like</p>

<pre><code>NAME            URL
stable          https://kubernetes-charts.storage.googleapis.com
</code></pre>

<p>It refers to <strong><code>https://github.com/helm/charts/tree/master/stable</code></strong></p>

<p>Now I will tell you to download the chart from the repo URL.</p>

<pre><code>helm fetch stable/wordpress --version 0.6.0
</code></pre>

<p>For the extracted copy of the chart</p>

<pre><code> helm fetch stable/wordpress --version 0.6.0 --untar
</code></pre>

<p><strong>The above command will download the chart in your current directory.</strong></p>

CC BY-SA 4.0
2020-04-21T06:49:11.313Z
2020-04-21T06:49:11.313Z
Arvind Rawat
<p>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:</p>
<p>You cannot download an original chart from a Kubernetes cluster, but what you <em>can</em> do is get all of the information that would be in said chart.</p>
<p>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.</p>
<p>First, go into the namespace where your install is, and run</p>
<p><code>kubectl get secrets</code></p>
<p>There will be a secret similar to this:</p>
<p><code>sh.helm.release.v1.&lt;chart name&gt;.v1</code></p>
<p>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:</p>
<p><code>kubectl get secret sh.helm.release.v1.&lt;chart name&gt;.v1 -o json | jq .data.release | tr -d '&quot;' | base64 --decode | base64 --decode | gzip -d &gt; output.json</code></p>
<p>Let's break this down a little.</p>
<p><code>kubectl get secret</code> gets the secret from the cluster</p>
<p><code>sh.helm.release.v1.&lt;chart name&gt;.v1</code> is the secret name we got by running <code>kubectl get secrets</code> before</p>
<p><code>-o json</code> ensures we get a json output</p>
<p><code>jq .data.release</code> selects the part from the json output we actually want</p>
<p><code>tr -d '&quot;'</code> deletes unnecessary <code>&quot;</code> characters for further processing</p>
<p><code>base64 --decode</code> decodes the base64 encoded data. we run this twice</p>
<p><code>gzip -d</code> unzips the resulting file</p>
<p><code>&gt;output.json</code> ensures we write the resulting data to a file called <code>output.json</code> for easier reading (otherwise you're looking at dozens to hundreds of lines of output on the terminal)</p>
<hr />
<p>This results in a json file something like this:</p>
<pre><code>
{
    &quot;name&quot;: &quot;chartName&quot;,
    &quot;info&quot;: {
        &quot;first_deployed&quot;: &quot;2023-04-04T12:53:46.750501771Z&quot;,
        &quot;last_deployed&quot;: &quot;2023-04-04T13:16:24.683772+02:00&quot;,
        &quot;deleted&quot;: &quot;&quot;,
        &quot;description&quot;: &quot;Upgrade complete&quot;,
        &quot;status&quot;: &quot;deployed&quot;,
        &quot;notes&quot;: &quot;this is a beautiful app for beautiful people&quot;
    },
    &quot;chart&quot;: {
        &quot;metadata&quot;: {
            &quot;name&quot;: &quot;chartname&quot;,
            &quot;home&quot;: &quot;link-to-homepage.com&quot;,
            &quot;sources&quot;: [
                &quot;https://github.com/link/to/source&quot;
            ],
            &quot;version&quot;: &quot;1.0.0&quot;,
            &quot;description&quot;: &quot;this beautiful chart deploys a beautiful app for beautiful people&quot;,
            &quot;maintainers&quot;: [
                {
                    &quot;name&quot;: &quot;john doe&quot;,
                    &quot;email&quot;: &quot;john.doe@company.com&quot;
                },
                {
                    &quot;name&quot;: &quot;jane doe&quot;,
                    &quot;email&quot;: &quot;jane.doe@company.com&quot;
                }
            ],
            &quot;icon&quot;: &quot;link-to-icon.png&quot;,
            &quot;apiVersion&quot;: &quot;v2&quot;,
            &quot;appVersion&quot;: &quot;v1.0.0&quot;,
            &quot;annotations&quot;: {
                &quot;artifacthub.io/license&quot;: &quot;Apache-2.0&quot;,
            }
            &quot;dependencies&quot;: [
                {
                    &quot;name&quot;: &quot;foo&quot;,
                    &quot;version&quot;: &quot;1.0.2&quot;,
                    &quot;repository&quot;: &quot;link-to-repo&quot;
                },
            &quot;type&quot;: &quot;application&quot;
        },
        &quot;lock&quot;: null,
        &quot;templates&quot;: [
            {
                &quot;name&quot;: &quot;templates/configmap.yaml&quot;,
                &quot;data&quot;: &quot;abc123&quot;
            },
            {
                &quot;name&quot;: &quot;templates/ingress.yaml&quot;,
                &quot;data&quot;: &quot;abc123=&quot;
            }],
        &quot;values&quot;: {
            &quot;foo&quot;: &quot;bar&quot;
            &quot;boolean&quot;: false
}
</code></pre>
<p>The <code>dependencies</code> refer to Helm charts that the release you're looking at depends on.</p>
<p>The <code>templates:</code> all specify a <code>name</code> and <code>data</code>. These names refer to the files that were originally in the Helm chart <code>templates</code> folder, and the <code>data</code> part is their contents (base64 encoded again).</p>
<p>The <code>values:</code> section specifies whatever was in the Helm chart's <code>values.yaml</code> file.</p>
<p>You can use these dependencies, templates and values to re-create the original Helm chart.</p>
<p>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.</p>

CC BY-SA 4.0
2023-04-04T15:42:16.613Z
2023-04-04T15:42:16.613Z
Tijmen
<p>To get the package to connect to the helm kubernetes cluster and run <code>helm fetch</code> which will </p>

<blockquote>
  <p>pull down the char from a repository and (optionally) unpack it in the local directory.</p>
</blockquote>

<p>use <code>helm fetch --help</code> to see formating options</p>

<p>Use <code>helm --help</code> to see available commands. </p>

<p><code>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</code></p>

CC BY-SA 4.0
2018-06-28T21:30:25.187Z
The cluster isn't a repository - are you sure that would work?
Kieren Johnstone
CC BY-SA 4.0
2018-06-29T00:00:59.823Z
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.
Jeff Garrett
CC BY-SA 4.0
2018-06-28T21:26:51.140Z
2018-06-28T21:26:51.140Z
Jeff Garrett
<p>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.</p>

<p>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?</p>

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

CC BY-SA 4.0
2018-06-27T03:55:48.210Z
is there a code repository for your infrastructure code?
Jeff Garrett
CC BY-SA 4.0
2018-06-27T10:18:57.003Z
There was, but it was a minor project, and the person/people in question are no longer here - I can't find it
Kieren Johnstone
CC BY-SA 4.0
2018-06-27T16:56:19.183Z
Are they willing to do some consulting for their previous employer?  An hour of their time could save you days of fruitless searching.
chicks
CC BY-SA 4.0
2018-06-27T16:57:03.973Z
What does your IT department do with old laptops during off-boarding?
chicks
<kubernetes><helm><disaster-recovery-plans>
Original Helm chart gone - how can I find / get it from the cluster?
Kieren Johnstone
# Original Helm chart gone - how can I find / get it from the cluster?

(Asked by: username_0 on 2018-06-20)

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.

**Tags:** kubernetes, helm, disaster-recovery-plans

> **Comments:**
> **username_1**: is there a code repository for your infrastructure code?  
> **username_0**: There was, but it was a minor project, and the person/people in question are no longer here - I can't find it  
> **username_2**: Are they willing to do some consulting for their previous employer?  An hour of their time could save you days of fruitless searching.  
> **username_2**: What does your IT department do with old laptops during off-boarding?  

---

## 5 answers

### Answer by username_3 on 2018-07-20. Score: 3

You can use `helm get manifest`  to fetch the kubernets manifests and you can use `helm get values`  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  with your release name.


---

### Answer by username_4 on 2020-11-26. Score: 0

*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*


---

### Answer by username_5 on 2020-04-21. Score: 0

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.


---

### Answer by username_6 on 2023-04-04. Score: 0

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..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..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..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": [
                "https://github.com/link/to/source"
            ],
            "version": "1.0.0",
            "description": "this beautiful chart deploys a beautiful app for beautiful people",
            "maintainers": [
                {
                    "name": "john doe",
                    "email": "john.doe@company.com"
                },
                {
                    "name": "jane doe",
                    "email": "jane.doe@company.com"
                }
            ],
            "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.


---

### Answer by username_1 on 2018-06-28. Score: 0

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`

> **Comments:**
> **username_0**: The cluster isn't a repository - are you sure that would work?  
> **username_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.  

---

