# argocd app set: Update Application Parameters

> argocd app set updates an existing Application: image tags, Helm values, revision, and sync policy. Reference for --helm-set, --revision, -p, and CI errors.

Source: https://latchkey.dev/learn/command-reference/argocd-app-set  
Updated: 2026-06-30

argocd app set changes parameters on an existing Application, such as a Helm value, a parameter override, or the tracked revision.

When a build produces a new image tag, app set is the imperative way to bump it without editing the Application manifest by hand.

## What it does

argocd app set mutates an existing Application in place. It can override Helm values (--helm-set), Kustomize images, plain parameters (-p), the tracked --revision, or the --sync-policy. The change is persisted but does not sync until you run app sync.

## Common usage

```Terminal
# bump a Kustomize image after a build
argocd app set guestbook --kustomize-image acme/web:"$GIT_SHA"
# override a Helm value
argocd app set guestbook --helm-set image.tag="$GIT_SHA"
argocd app sync guestbook
```

## Options

| Flag | What it does |
| --- | --- |
| --helm-set key=value | Override a Helm value |
| --kustomize-image name:tag | Override a Kustomize image |
| -p key=value | Set a plugin/parameter override |
| --revision <ref> | Change the tracked Git revision |
| --sync-policy automated|none | Change the sync policy |

## In CI

app set only records the override; pair it with app sync to actually deploy. For reproducibility, prefer committing the new tag to Git over an imperative app set, but set is convenient for image promotion between environments.

## Common errors in CI

"FATA[0000] rpc error: code = InvalidArgument desc = ... is not a valid value" means a malformed --helm-set or image reference. "application ... not found" means the app does not exist yet (use app create first). Overrides set here can conflict with values in Git and be reverted on the next sync if auto-sync re-renders them.

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

### argocd app set: Update Application Parameters?

When a build produces a new image tag, app set is the imperative way to bump it without editing the Application manifest by hand.

### What it does?

argocd app set mutates an existing Application in place. It can override Helm values (--helm-set), Kustomize images, plain parameters (-p), the tracked --revision, or the --sync-policy. The change is persisted but does not sync until you run app sync.

### In CI?

app set only records the override; pair it with app sync to actually deploy. For reproducibility, prefer committing the new tag to Git over an imperative app set, but set is convenient for image promotion between environments.

### Common errors in CI?

"FATA[0000] rpc error: code = InvalidArgument desc = ... is not a valid value" means a malformed --helm-set or image reference. "application ... not found" means the app does not exist yet (use app create first). Overrides set here can conflict with values in Git and be reverted on the next sync if auto-sync re-renders them.

---

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