Upgrade Enterprise

Before proceeding, preserve the database and matching SESSION_SECRET, CertOps wrapping keys, SSO keyring, license, and deployment configuration. Use the backup procedure in the Core docs version paired with your Enterprise release. Read the target release notes and its Core compatibility manifest. An Enterprise upgrade includes the paired Core runtime; do not independently upgrade the Core subchart.

Reverting an image or chart does not reverse database migrations. Recovery requires a matching backup or an explicitly supported migration path.

Upgrading to 0.17.0 fingerprint inventory

Back up the database and matching secrets, drain automation and prevent lifecycle writes. Apply additive Core migrations 62–66 and deploy the paired Core runtime and Enterprise overlays together before resuming management. Review ambiguous historical retirement evidence and verify grouping, rotation, endpoint removal/re-add, quota and decommission eligibility. Legacy retirement clients must supply the expected certificate identity. Reverting images does not undo migrations; recovery requires a matching pre-upgrade backup.

Each release ships as: new image tags in Harbor, a new Helm chart version in Harbor, and a new install bundle in Harbor. Replace NEXT_VERSION below with the version you are upgrading to. The bundle VERSION file records the version you extracted; TokenTimer support will confirm the target release when you renew.

Retrieve the target bundle

The bundle is published as a generic OCI artifact, pulled with ORAS (a single static binary):

oras login harbor.tokentimer.ch -u 'robot$tokentimer-enterprise+<company>-<your-id>'
# Enter the robot token at the password prompt.
read -r -p 'Target Enterprise release: ' NEXT_VERSION
oras pull harbor.tokentimer.ch/tokentimer-enterprise/bundles/tokentimer-enterprise:"${NEXT_VERSION}"
tar -xzf "tokentimer-enterprise-${NEXT_VERSION}.tar.gz"

Docker Compose

cd compose
# Bump TT_ENTERPRISE_TAG in .env if you pin versions, then:
docker compose -f docker-compose.yml pull
docker compose -f docker-compose.yml up -d

Helm

read -r -p 'Target Enterprise release: ' NEXT_VERSION
helm upgrade tokentimer oci://harbor.tokentimer.ch/tokentimer-enterprise/charts/tokentimer-enterprise \
  --version "$NEXT_VERSION" \
  -n tokentimer \
  -f my-values.yaml

Re-check tokentimer.config.baseUrl and tokentimer.config.apiUrl in my-values.yaml after upgrade if you use SSO; chart defaults are localhost-oriented and are not auto-corrected from ingress hostnames.

Config changes in my-values.yaml (URLs, OIDC/SAML env, SMTP, and so on) take effect after the upgrade rolls the API and dashboard pods. The chart annotates Deployments so helm upgrade triggers that rollout automatically. Editing a running ConfigMap with kubectl alone does not restart pods.

Registry token renewal

Your robot account expires at the same time as your license. When you renew, you receive a new robot token and must update your Docker login and the Kubernetes pull secret. Existing pods continue running with their cached image layers; only the next helm upgrade or docker compose pull re-authenticates. See Rotating credentials at renewal.

Verify after upgrade

Confirm successful migrations, API/dashboard health, worker scheduling, the effective license, and administrator access. Check your first alert; if SSO is configured, check sign-in with an existing administrator before inviting users.

License lifecycle

The license JWT drives feature gating at runtime:

State	Behavior
Valid license	Enterprise features enabled, bell icon clean
Grace period (at most 30 days past expiry; TT_LICENSE_GRACE_DAYS cannot extend past 30)	Features still work, responses carry the X-License-Warning header, bell icon shows yellow
Past grace	SSO endpoints redirect to /login?error=license_<provider>_required, auto-sync POST/PUT/run return 403; existing configs can still be read and deleted (cleanup is allowed)

Admins can also import or remove a license JWT from System Settings > License at runtime. TT_LICENSE_KEY takes precedence over database imports, which take precedence over the mounted file. Resolution order and the grace period variable (TT_LICENSE_GRACE_DAYS, default and maximum 30) are documented in the Configuration reference.