Skip to main content
Every deployment upgrades independently. There is no fleet-wide “upgrade now” button and no automatic rollout — you choose when each one moves, and the control plane tells you which version it should be on.

​
Which version to run

Never install or upgrade to a chart version copied from a document, including this one. The supported version is served by the control plane and tracks the published chart; a literal pinned in a guide rots. An install from a six-month-old chart fails in ways that look like product bugs but are pure version skew.
The control plane reports each deployment’s current version and whether it is still supported, from the data plane’s heartbeat. That report is the source of truth for what to upgrade to. Every published chart version, and the component versions it ships, is listed in Data plane chart releases — useful to see what an upgrade moves, not to pick the target. In STANDALONE mode there is no control plane to ask: upgrades are fully manual, via signed offline bundles.

​
Ordering a fleet

Deployments are independent runtimes, so upgrade them one at a time:
1

Roll a staging deployment first

Pick the deployment whose pipelines you can afford to interrupt.
2

Confirm it comes back

Its status must flip back to Live in the control plane. That flip is driven by the data plane’s first heartbeat on the new version — if it stays Offline, stop and see Troubleshooting.
3

Then move through production

One deployment at a time, confirming Live between each.
Everything except the per-deployment identity and state — images, chart version, ingress class, IAM patterns — should be identical across deployments, so the same upgrade is a repeat of the one you just validated. See Per-deployment isolation for what must never be shared.

​
Kubernetes

The data plane runs its database migrations on startup. Watch a pod’s logs:
Before bumping the broker image on an existing bucket, read the upgrade notes on tansu.image.tag in the chart’s values.yaml. Two of the tags cross an object-layout boundary and need a quiesce-and-flip rather than a rolling upgrade.
Pin both the chart version (--version) and the application image (image.tag) — never deploy latest, or an upgrade becomes whatever happened to be published that day.

​
Uninstalling

By default the PostgreSQL PVC and the broker’s S3 data are kept (postgresql.primary.persistentVolumeClaimRetentionPolicy.whenDeleted=Retain; S3 buckets are external). Delete them manually for a clean slate:

​
Further reading

Deployments and environments

Why deployments are independent runtimes in the first place.

Troubleshooting

When a deployment does not come back Live.