To move to a newer release, re-run the install as an upgrade: same values file, new version.
Upgrade one major version at a time. Skipping major versions is not supported. If your target is more than one major version ahead, upgrade through each intervening major version in order. Verify that the installation is working after each upgrade before continuing.
When upgrading from v2 to v3, follow upgrading from v2 to v3 if you need to retain existing Blobstore data. That guide also explains how to start the Blobstore upgrade fresh when retaining the existing data is unnecessary.
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
Tunnel networks
When tunnels use tunnel.gatewayHostPort, the gateway stops before its replacement starts. Upgrades interrupt tunnel connectivity, and requests still running after the 30-second shutdown window can fail. Exit nodes reconnect automatically once the replacement is ready; recovery time depends on image pulls, scheduling, and startup. Schedule a maintenance window for workloads that depend on tunnels.
With tunnel.gatewayNodePort, the chart starts a replacement before stopping the old gateway and allows up to 330 seconds for shutdown, including five minutes for active streams to drain. The cluster needs capacity for the extra gateway pod during the rollout. This reduces interruption but does not guarantee uninterrupted requests.
Helm preserves the gateway CA and authentication token across upgrades and while tunnels are disabled. Re-enabling tunnels reuses them. Do not delete tunnel-secrets: existing exit nodes trust the saved CA.
Special cases
Changed the license too? Follow applying a license so the tenant bootstrap job applies it to the tenant.
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
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.