Skip to main content

Upgrade DIAL

Move a running DIAL deployment to a new chart version safely, with no data loss and minimal disruption. This guide covers reading the version's upgrade notes, backing up first, running helm upgrade, verifying, and rolling back. It assumes a Helm deployment with kubectl and Helm access.

Rolling updates replace service instances gradually; interruption of active requests depends on the workload and shutdown behavior. The risk is in breaking changes to dependencies and configuration, which the chart documents per version.

Prerequisites​

  • DIAL deployed with the dial umbrella chart
  • A current backup — see Back up and restore DIAL
  • The target chart version you intend to install

Step 1: Read the target version's upgrade notes​

This is the step that prevents failed upgrades. The chart's README keeps an Upgrading section with an entry per significant version. Entries flag breaking changes, dependency bumps (such as Keycloak, Valkey, or Postgres), and the exact manual actions a version requires — for example, editing a realm file, dumping Postgres before the bump, or removing a decommissioned values section. DIAL's release notes and version-specific upgrade guides cover the platform-wide changes behind each version, alongside the chart's own entry.

Read the entry for your target version, and every entry between your current and target version. The maintainers note that the generic steps may not cover every deployment, so treat the version notes as authoritative over this page.

Step 2: Back up before you change anything​

Take a fresh backup of blob storage, configuration, the encryption key, and Postgres if you run Keycloak. Some version upgrades explicitly require a Postgres dump first. Do not skip this even for a patch release.

Step 3: Run the upgrade with a pinned version​

Always pin the chart version rather than tracking latest, so upgrades are deliberate and repeatable:

helm repo update
helm upgrade dial dial/dial \
  -f values.yaml \
  --version <TARGET_CHART_VERSION> \
  --namespace dial

Apply any manual values changes the version notes called for in the same values.yaml.

Step 4: Verify the deployment​

helm list -n dial
kubectl get pods -n dial
kubectl logs -n dial -l app=dial-core --tail=50

Confirm every workload reaches Running, the new image tags are live, and the Core logs are clean. Smoke-test the Unified API and DIAL Chat.

Step 5: Roll back if needed​

If verification fails, roll back to the previous release revision:

helm history dial -n dial
helm rollback dial <PREVIOUS_REVISION> -n dial

Rollback returns the workloads and chart values to the prior state. It does not undo data migrations or manual database changes a version performed, which is why Step 2's backup matters.

Result​

DIAL runs the target chart version after the deployment and smoke checks pass. Confirm active-request behavior, complete the version-specific actions, and retain the backup needed if rollback requires data recovery.

Understanding versions and cadence​

The umbrella chart carries three version numbers: the chart version, the appVersion (the DIAL release it packages), and the pinned versions of each subchart and dependency. DIAL releases on a biweekly cadence following semantic versioning, so minor and patch upgrades are routine and major versions carry the breaking-change notes described above.

Coming soon

DIAL publishes per-version upgrade notes in the chart README and GitHub releases, but no single consolidated cross-component version-compatibility matrix. Until one exists, rely on the chart's pinned dependency versions and the per-version Upgrading entries.

Further reading​