# helm repo update: Usage, Options & Common CI Errors

> helm repo update refreshes cached repository indexes. Why CI must update before install, and the stale-index and unreachable-repo errors.

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

Refresh the local index so new chart versions appear.

helm repo update re-downloads the index.yaml of your registered repositories so Helm knows about newly published chart versions. Skipping it is a classic reason a just-published chart "cannot be found" in CI.

## What it does

helm repo update refreshes the cached index for all added repos (or just the ones you name). Helm resolves chart versions from these cached indexes, so a chart published after your last update is invisible until you run it. It is a read-only metadata refresh - fast, and safe to run on every CI build.

## Common usage

```Terminal
helm repo update
helm repo update bitnami            # just one repo
helm repo add internal https://charts.example.com && helm repo update internal
helm repo update && helm install web internal/web
```

## Common errors in CI

The symptom of skipping update is "Error: ... chart \"web\" matching <version> not found in <repo> index" - the index is stale, so a freshly published version is missing; always helm repo update after add and before install in CI. "Unable to get an update from the \"X\" chart repository" with a network error means a repo URL is unreachable (DNS, proxy, an outage); update fails the whole refresh if any repo errors unless you scope to the reachable one. Since CI runners start with no cached indexes, add then update every run.

## 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 repo update: Usage, Options & Common CI Errors?

helm repo update re-downloads the index.yaml of your registered repositories so Helm knows about newly published chart versions. Skipping it is a classic reason a just-published chart "cannot be found" in CI.

### What it does?

helm repo update refreshes the cached index for all added repos (or just the ones you name). Helm resolves chart versions from these cached indexes, so a chart published after your last update is invisible until you run it. It is a read-only metadata refresh - fast, and safe to run on every CI build.

### Common errors in CI?

The symptom of skipping update is "Error: ... chart \"web\" matching <version> not found in <repo> index" - the index is stale, so a freshly published version is missing; always helm repo update after add and before install in CI.

---

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