Version: 0.2 (next)

Upgrades

Once the setup wizard finishes, Argo CD runs Infrared from your gitops repo, so you upgrade it the same way you change anything else there: with a pull request. You can read the change before it lands, merge it when it suits you, and see in git exactly what runs.

Two things move, each in its own way:

What	How you upgrade it
Infrared itself: the operator, API, UI, MCP server and runner	A pull request that changes the chart version in your gitops repo
The gitops template: the components Argo CD runs beside Infrared, and their sync waves	A patch to the GitopsRepo's template version, after which the operator rewrites the repo

Don't run helm upgrade against an install Argo CD manages. Argo CD puts back what the gitops repo says on its next sync.

Versions and tracks

Infrared's versions are major.minor.patch. A track is one major and minor, such as 0.1: every patch released under it, 0.1.0, 0.1.1, 0.1.2 and on, belongs to the 0.1 track. These docs follow tracks too: the 0.1 docs describe every 0.1 patch.

Patches within a track fix and improve what the track ships. Moving to a newer patch is the everyday upgrade.
Pre-releases, such as 0.1.1-rc.4, are builds on the way to the next patch. They are published to the same chart repository, but a production install normally runs release versions.
A new track, such as 0.2, can change behaviour you rely on. Its release notes say what changed and what to do.

Each chart version pins every component image by tag and digest, so the version alone decides what runs. The release notes list what each release brings.

Upgrade Infrared within a track

Infrared's own Application lives at registry/clusters/<cluster>/components/infrared.yaml in your gitops repo. Its targetRevision is the chart version Argo CD runs.

Open a pull request that changes that one line:
```
-      targetRevision: 0.1.0
+      targetRevision: 0.1.1
```
The chart comes from the chart repository your install pulls from, the repoURL just above that line.
Merge it when you are ready. Argo CD syncs the infrared Application, applies the chart's CRDs first, then rolls each Deployment.
Check the result:
```
kubectl --context <cluster> -n argocd get application infrared
kubectl --context <cluster> -n infrared get pods
```
The infrared Application is Synced and Healthy, and Settings → Installation shows the new version. People with Infrared open in a browser see A new version of Infrared is available and a Reload button; nothing they saved is lost.

To move several patches at once, such as from 0.1.0 to 0.1.3, read the release notes of each patch you pass for anything it asks you to do first.

An upgrade keeps your data. Your orgs, Products, AgentRoles, AgentWorkflows and runs are custom resources in your cluster, and a new release never overwrites an AgentRole your org already has, even when the catalog changes. New orgs start from the new catalog.

The chart checks its values against a schema and refuses one it doesn't know. When a release adds a value your install needs, its release notes say so, and the new value goes in the same pull request as the new targetRevision.

Upgrade to a new track

Move to the newest patch of the track you run, as above, and check it is Synced and Healthy.
Read the new track's release notes, and make any change they ask for first.
Open the pull request to the new track's newest patch.
Upgrade the gitops template to the version that release pairs with (below).

Upgrade the gitops template

The operator built your gitops repo from a pinned version of infrared-gitops-template. Each chart version is tested with one template version, and a new gitops repo starts from it; an existing repo keeps the version it has until you move it.

Move the template after the chart, once the new operator is running. The running operator renders the template, and an older operator may not understand a newer template.

Wait for the new operator:

kubectl --context <cluster> -n infrared rollout status deploy/infrared-operator

Find the template version the running release pairs with:

kubectl --context <cluster> -n infrared get deploy infrared-api \
  -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="INFRARED_GITOPS_TEMPLATE_VERSION")].value}{"\n"}'

It is a tag such as v0.1.11, or a full commit.

Set it on the GitopsRepo:

kubectl --context <cluster> -n ir-org-<platform org> patch gitopsrepo gitops --type merge \
  -p '{"spec":{"template":{"version":"<version>"}}}'

The operator renders the new template, commits it to the repo as infrared[bot] ("chore: hydrate from infrared-gitops-template <version>"), and Argo CD syncs it. Check that it landed:
```
kubectl --context <cluster> -n ir-org-<platform org> get gitopsrepo gitops \
  -o jsonpath='{.status.hydratedVersion} {.status.commit}{"\n"}'
```

Read the hydration commit's diff in your gitops repo afterwards. Hydration never lowers the Infrared pin: infrared.yaml takes the running operator's chart version, or keeps the one already in the repo when that is newer.

Hydration adds and overwrites files; it never deletes one. Files you added stay. If you edited a file the template also writes, the template's version replaces your edit, so keep your own changes in files of your own, such as the values file below.

Values the adopted Application carries

The infrared Application the template writes sets the chart values the install was made with, so that Argo CD's adoption never changes or regenerates them. Among them:

the management cluster's name, the template version and the chart repository;
how Infrared pulls its images: the pull Secret or the registry token, and the image registry and pins;
Infrared's cloud identity, the build registry and the registry inside the cluster;
the edge and Infrared's own address, on an install with the Gateway edge;
the stores, the backup destination and settings, the components left out, and the code index;
existingSecret for the setup token, the session key, the MCP tokens, the platform tokens and, with Gitea, its admin, so none of them is rotated.

Other values you passed to the first helm install or ir install aren't carried over. After adoption the chart's default applies, unless you set them again in your values file.

Values of your own

Put values of your own, such as signIn.password.enabled, api.directory.serviceAccount or the install configuration, in registry/clusters/<cluster>/values/infrared.yaml in your gitops repo, through a pull request. The infrared Application reads that file if it exists, and the template never writes it, so it survives template upgrades.

The chart your install runs, infrared, wraps Infrared's own chart, infrared-core, so your values go under infrared-core::

infrared-core:
  signIn:
    password:
      enabled: false
  api:
    directory:
      serviceAccount: infrared-directory@<project>.iam.gserviceaccount.com

The values the template sets in the Application win over the file. Keep secrets out of it: the file is plain text in git.

Versions and tracks​

Upgrade Infrared within a track​

Upgrade to a new track​

Upgrade the gitops template​

Values the adopted Application carries​

Values of your own​