# helm get: Usage, Options & Common CI Errors

> helm get retrieves the values, manifest, notes, or hooks of a deployed release. Recovering effective values in CI, and the release-not-found error.

Source: https://latchkey.dev/learn/command-reference/helm-get-command  
Updated: 2026-06-25

Pull back exactly what a live release was deployed with.

helm get reads information about an installed release from the cluster: the values it was rendered with, the manifests it applied, its hooks, or its notes. It is how you recover the truth of what is actually running.

## What it does

helm get values NAME prints the user-supplied values for the release (add -a/--all for the full computed values including chart defaults); get manifest prints the rendered Kubernetes objects; get hooks and get notes print those; get all combines everything. --revision inspects a past revision rather than the current one.

## Common usage

```Terminal
helm get values web -n prod
helm get values web -a            # full merged values
helm get manifest web | kubectl diff -f -
helm get values web --revision 4
```

## Common errors in CI

The key gotcha: plain helm get values returns only the overrides you passed, not the chart defaults - so it looks empty for a release installed with no --set. Use -a/--all to get the effective values, which is what you want when reproducing a release or migrating it. "Error: release: not found" means wrong name/namespace/revision. helm get values -a is invaluable in CI for capturing a release's real configuration before an upgrade, so you can diff and roll forward deliberately.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### helm get: Usage, Options & Common CI Errors?

helm get reads information about an installed release from the cluster: the values it was rendered with, the manifests it applied, its hooks, or its notes. It is how you recover the truth of what is actually running.

### What it does?

helm get values NAME prints the user-supplied values for the release (add -a/--all for the full computed values including chart defaults); get manifest prints the rendered Kubernetes objects; get hooks and get notes print those; get all combines everything. --revision inspects a past revision rather than the current one.

### Common errors in CI?

The key gotcha: plain helm get values returns only the overrides you passed, not the chart defaults - so it looks empty for a release installed with no --set. Use -a/--all to get the effective values, which is what you want when reproducing a release or migrating it. "Error: release: not found" means wrong name/namespace/revision.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt