Upgrade Smeltr

Upgrade the executable

Complete this checklist in order:

  • Record the installed version, checksum or image digest, and configuration. Read the new version’s release notes before upgrading.
  • Test the upgrade on an isolated copy of your backup. Check worker enrollment, certificates, secrets, and a pipeline that uses your usual sources and destinations.
  • Take a stopped-leader backup and retain the previous binary or image with the matching pre-upgrade state: an image archive or a registry copy you control, not only its digest. Preserve worker directories.
  • Within a maintenance window, stop each process before replacing its executable. The leader upgrades data an earlier release wrote when it starts, with no manual step. A worker on another major release keeps running what it has, takes no new deployment, and shows on Status as On another build. A worker on an older release of the leader’s major keeps taking deployments, but refuses one that uses something newer, so upgrade workers before using what a release adds.
  • Verify login, certificate status, heartbeats, reported commits and destination output before closing the window.

An older build starts on the leader’s upgraded data unless the newer build changed it in a way the older one cannot read. Then the older leader refuses to start and says why: restore the pre-upgrade artifact and its matching backup together. Restoring older configuration can also change what workers deploy.

Operate and upgrade on Kubernetes

  • Keep the leader at one replica. Additional leader replicas would compete for the same installation state; they do not provide automatic recovery.
  • Before a leader upgrade, stop the leader StatefulSet and back up both leader claims, leader-data and leader-secrets, as a matched set. Retain the old image digest and manifests with that backup.
  • Update leader and worker image digests only after testing the new release in an isolated namespace. Keep the leader and workers on one major release: a worker on another major takes no new deployment.
  • When scaling a StatefulSet up, mint a permanent enrollment code for the new pods and temporarily restore the enrollment code Secret and environment entry. Each new worker pod receives its own identity and storage. To scale with load, autoscale the group instead.
  • Revoking a worker in Smeltr does not terminate its pod or external data access. Scale it down or delete the workload, revoke it, and rotate external credentials when required.

Follow Backup and recovery and Operate the fleet for the application-level checks around these Kubernetes actions.