Updating is intentionally simple.
Standard (online) server
Edit
/opt/3b/.envand change theVERSIONline to the new version (for exampleVERSION=v2.0.1).Re-run the installer:
sudo bash /opt/3b/setup.sh
It pulls the new images, applies any database migrations, and upgrades the Helm release. Your data (in the Kubernetes persistent volumes) is preserved, and your configuration and secrets in /opt/3b/.env are reused. Nothing rotates.
The server needs outbound access to oci.tines.com for every update, just like the first install.
Air-gapped (offline) server
The offline server can’t reach the registry, so you pull the new version’s bundle down on a connected machine, copy it across, extract it into /opt/3b, and re-run setup.sh.
On the connected machine, pull the bundle with the ORAS CLI and your registry credentials. The bundle is an OCI artifact rather than a container image, so docker pull won’t work here:
echo "$OCI_PASSWORD" | oras login oci.tines.com \ --username "$OCI_USERNAME" \ --password-stdin oras pull oci.tines.com/3b/bundles/self-hosted:<new-version>
This downloads 3b-self-hosted-<new-version>.zip into the current directory. Copy it to the offline server by whatever means you use, then extract it and re-run the installer:
sudo unzip 3b-self-hosted-<new-version>.zip -d /opt/3b && cd /opt/3b sudo bash setup.sh
Your configuration and secrets in /opt/3b/.env are preserved. For the full flow, including producing the bundle with the bootstrap script instead, see updating an air-gapped server.
Verify
After the installer finishes, confirm everything rolled out and the UI responds. See verifying the install.
Recommendations
Read the release notes for every version between yours and the target before updating.
Back up
/opt/3b/.envand the database before updating anything you care about.The installer is safe to re-run. If an update is interrupted, run
sudo bash /opt/3b/setup.shagain.