To move to a newer release, re-run the install as an upgrade: same values file, new version.
helm upgrade 3b oci://oci.tines.com/3b/charts/3b \ --version <NEW_VERSION> \ --namespace 3b \ -f values.yaml \ --timeout 15m
What happens:
The application secrets are read back via
lookupand preserved, so no key or database password rotates. The namespace and pull secret you created at install time stay as they are.A one-time database migration job runs for the new version, then the services roll out.
Image tags move to the new release automatically. The chart pins them, so you never edit image versions by hand.
Watch it complete:
kubectl -n 3b get pods -w kubectl -n 3b rollout status deploy/api
Special cases
Changed the license too? A same-version Helm upgrade doesn’t restart running pods; follow applying a license to roll the services that read it.
Secrets managed outside Helm (
secrets.generate: false, e.g. a stack originally provisioned by the single-server installer): keepgenerate: falseon every upgrade. Helm won’t adopt secrets it didn’t create, and flipping it would abort the upgrade with an “invalid ownership metadata” error.
Recommendations
Read the release notes for every version between yours and the target before upgrading.
Take a database backup (and, if in-cluster, snapshot the persistent volumes) before upgrading production.
Upgrade a non-production stack first where you have one.