Upgrade to the latest Conduktor version.

​
Release cadence

Conduktor provides a new release roughly every month. We suggest that you upgrade no more than two versions apart at a time. To get notified when a new release comes out click Follow from the Conduktor Console and Conduktor Gateway pages.

​
Overview

Each Conduktor component follows an independent release cycle, so versioning is separate for Helm charts, Console/Gateway (the Docker image which includes the related API) and the Terraform provider. All the components follow the semantic versioning of: major.minor.patch.
Before any upgrade we strongly recommend reviewing Conduktor release notes to ensure that there are no breaking changes that might impact your deployment.

​
Upgrade Console

For Docker deployments, we recommend to:
  1. Back up your database, in case a roll-back is required.
  2. Upgrade the Docker image version to the most recent one.
  3. Re-deploy Console with the updated image version.
During startup, Console will automatically apply any necessary database migrations (structure or data changes). These migrations are version-aware and tracked to support version jumps safely.

​
Upgrade Gateway

For Docker deployments, we recommend to:
  1. Upgrade the Docker image version to the most recent one.
  2. Re-deploy Gateway with the updated image version.
To minimize the disruption to your service, perform the upgrade as a rolling update.

​
Terraform compatibility

The Terraform provider compatibility is managed at the resource level, not the overall provider or Console version. New resources may require newer Console API versions. Compatibility details are:

​
Migrate Gateway API from v1 to v2

Gateway v3.3.0 introduces API v2 to enhance user experience when interacting with Gateway resources. When migrating from API v1 to v2, your Gateway resources will be preserved (you can interact with old resources via the v2 API) and only minimal attention is required for two resources: Virtual Clusters and Gateway service account.

​
Virtual Clusters

When migrating to v2:
  • the boolean value for aclEnabled will be automatically derived from the previously used GATEWAY_ACL_STORE_ENABLED variable but
  • you have to populate the superUsers list, as it won’t be done automatically when migrating.
Sample configuration: 
---
apiVersion: gateway/v2
kind: VirtualCluster
metadata:
  name: "mon-app-A"
spec:
  aclEnabled: true # Defaults to false
  superUsers:
  - username1
  - username2

​
Gateway service account

When migrating to v2, user mappings become GatewayServiceAccount. Every existing user mapping is migrated to v2 as EXTERNAL GatewayServiceAccount. If you were using LOCAL users (and generating tokens) with the v1 API, you have to:
  1. Declare LOCAL users in the v2 API.
  2. Generate tokens.