Introduction

If a Helm release already exists, the fastest way to recover the user-supplied values is helm get values. That command does not recreate the chart’s original values.yaml file exactly, but it does show the values stored for the release, which is usually what you need when auditing or recreating a deployment such as prime-gitlab.

Get The Values For The Existing Release

To print the values that were explicitly set on the release:

helm get values prime-gitlab

To save them into a file:

helm get values prime-gitlab -o yaml > prime-gitlab-values.yaml

That output contains the user-supplied overrides stored in the release metadata.

Include Computed Defaults Too

Sometimes you want the full merged configuration, not just the overrides you passed during install or upgrade. In that case, use --all.

helm get values prime-gitlab --all -o yaml > prime-gitlab-values-all.yaml

This is usually closer to what people mean by "extract the values.yaml" because it includes computed values after Helm merged chart defaults and user overrides.

The distinction matters:

• 'helm get values prime-gitlab shows only saved overrides'
• 'helm get values prime-gitlab --all shows the fully merged release values'

Specify Namespace When Needed

If the release is not in the current namespace, add -n.

helm get values prime-gitlab -n gitlab -o yaml

Without the correct namespace, Helm may report that the release does not exist even though it is present elsewhere in the cluster.

Compare With Chart Defaults

If you still have access to the original chart, compare the live release values against the chart defaults.

helm show values gitlab/gitlab > chart-default-values.yaml
helm get values prime-gitlab --all -n gitlab -o yaml > live-values.yaml

This is useful when you need to see what changed from the chart baseline. It also helps explain why some keys are present in the full merged output but not in the user-supplied overrides.

When values.yaml Is Not Enough

A Helm release also includes rendered Kubernetes manifests. If the goal is to understand what is actually running, the values file alone may not be sufficient. Use helm get manifest as a companion command.

helm get manifest prime-gitlab -n gitlab > prime-gitlab-manifest.yaml

That output shows the rendered resources after templates were evaluated. It is different from values data and often more useful for debugging a live release.

Inspect Release Metadata

If you want a quick summary before extracting values, list or inspect the release first.

helm list -A | grep prime-gitlab
helm status prime-gitlab -n gitlab

This confirms the release name, namespace, and current revision before you capture the values.

Common Pitfalls

The most common mistake is expecting helm get values without --all to reproduce the chart’s full default file. It only returns stored overrides unless you ask for the merged result.

Another mistake is forgetting the namespace. Helm release names are namespace-scoped in common workflows, so the right release can look missing if you query the wrong namespace.

A third issue is using extracted values as if they were a perfect substitute for the original chart package. Some behavior comes from templates, helper functions, and chart version changes, not from values alone.

Summary

• Use helm get values prime-gitlab -o yaml to extract saved release overrides.
• Use --all when you need the full merged values for the running release.
• Add -n if the release is in a non-default namespace.
• Compare with helm show values if you also need the chart defaults.
• Use helm get manifest when the real goal is to inspect rendered Kubernetes resources.