Upgrades

Once the setup wizard finishes, Argo CD manages Infrared from your gitops repo. Two things get upgraded, in two different ways:

What	How	Who writes the change
Infrared (operator, API, UI, MCP server)	A pin PR that changes the chart version in the gitops repo	You, through a PR
The gitops template (the catalog components and their sync waves)	Bump the GitopsRepo's template version	The operator re-hydrates the repo

Never run helm upgrade against an adopted install. Argo CD reverts it on its next sync.

Upgrade Infrared: a pin PR

Infrared's own Application lives at registry/clusters/<cluster>/components/infrared.yaml in your gitops repo. Its targetRevision is the pin: the chart release to run. Each chart release pins every component image by tag and digest, so the pin fully determines what runs.

1. Open a PR that changes one line:

   -    targetRevision: 0.1.0-alpha.2
   +    targetRevision: 0.1.0-alpha.3

   The pin is the chart version as published on ghcr (0.1.0-alpha.3). Templates before v0.1.4 source the chart from its git repo instead, where the pin is the git tag (v0.1.0-alpha.3).

2. Review and merge it. Argo CD syncs the infrared Application, applies the chart's CRDs first, then rolls the Deployments.

3. Check the result:

   kubectl -n argocd get application infrared
   kubectl -n infrared get pods

The infrared Application is Synced and Healthy, and every pod runs an image pinned to the new release.

Upgrades keep your data. Your AgentRoles, AgentWorkflows and Products are custom resources in ir-org-<org> namespaces; a new release never overwrites an AgentRole your org already has, even when the catalog changes. New orgs are seeded from the new catalog.

Some releases add values the pin PR must carry as well. Chart 0.1.0-alpha.6 adds mcp.access.existingSecret, and you create its Secret first; see Connect an MCP client. The chart rejects values it doesn't know, so the new value and the new targetRevision go in the same PR.

Upgrade the gitops template

The operator hydrated your gitops repo from a pinned version of infrared-gitops-template. To move to a newer template, change the version on the GitopsRepo resource:

kubectl -n ir-org-<org> patch gitopsrepo gitops --type merge \
  -p '{"spec":{"template":{"version":"v0.1.4"}}}'

The operator renders the new template, commits the result to the repo as infrared[bot] ("chore: hydrate from infrared-gitops-template v0.1.4"), and Argo CD syncs it:

kubectl -n ir-org-<org> get gitopsrepo gitops -o jsonpath='{.status.hydratedVersion} {.status.commit}{"\n"}'

Upgrade the template only after the Infrared release that ships with it is running. The rendered infrared.yaml takes its targetRevision from the running operator, so an older operator writes an older pin. Wait for kubectl -n infrared rollout status deploy/infrared-operator after the pin PR syncs, then patch the GitopsRepo. Check the hydration commit's diff in the gitops repo afterwards.

Hydration adds and overwrites files; it never deletes a file. Files you added to the gitops repo stay. If you edited a file the template also owns, the template's version replaces your edit, so keep your own changes in files of your own.

Choosing versions

On the 0.1 track, Infrared ships pre-releases, 0.1.0-alpha.N. Chart and template versions are paired: each chart release defaults to the template version it was tested with. Upgrade the chart first, then move the template to the chart's default (gitops.templateVersion in the chart's values.yaml).