v2.1.6+Migrating from Bitnami Valkey to Official Valkey Chart

When upgrading UnO Agentic AI Builder from version 2.1.5.0 to 2.1.6.0, the underlying key-value store architecture changes. This topic provides instructions for migrating your existing database records from a legacy Bitnami Valkey deployment to a new instance running on the official Valkey Helm chart.

The migration utilizes data replication to synchronize data between the source and target instances, minimizing application downtime during the cutover phase.

Before you begin

Ensure that you have the following prerequisites and information available:

  • Access to the Kubernetes cluster with kubectl and helm CLIs configured.

  • The target environment namespace variable ($NS) exported in your terminal session.

  • The pod name of the newly deployed Valkey target pod ($NEW_POD_NAME) and the IP address of the source Bitnami Valkey pod ($OLD_POD_IP).

Procedure

Step 1: Deploy the New Valkey Instance

Deploy the target instance using the official Valkey Helm chart under a new release name (valkey-new). This deployment reuses your existing password secret.

Run the following command to perform the installation:

helm upgrade --install valkey-new valkey/valkey \
  -n "$NS" \
  --version 0.9.4 \
  --set architecture=standalone \
  --set auth.enabled=true \
  --set auth.usersExistingSecret=valkey-password-secret \
  --set auth.aclUsers.default.passwordKey=password \
  --set auth.aclUsers.default.permissions="~* &* +@all" \
  --set dataStorage.enabled=true \
  --set dataStorage.requestedSize=8Gi \
  --set dataStorage.keepPvc=true

Step 2: Export the Existing Password

Extract and decode the password string from your existing Kubernetes secret. This token is used for CLI authentication during the database synchronization process.

export PASS=$(kubectl get secret -n "$NS" valkey-password-secret -o jsonpath="{.data.password}" | base64 --decode)

Step 3: Configure Primary Authentication on the New Pod

Configure the target Valkey instance to use the existing password string when connecting to the source instance as a replica target.

kubectl exec -n "$NS" "$NEW_POD_NAME" -- valkey-cli -a "$PASS" --no-auth-warning config set primaryauth "$PASS"

Expected Output: OK

Step 4: Start Live Data Replication

Configure the target Valkey instance to act as a replica of the source Bitnami instance. The target pod connects immediately to initiate the data stream and clone all existing database records.

kubectl exec -n "$NS" "$NEW_POD_NAME" -- valkey-cli -a "$PASS" --no-auth-warning replicaof $OLD_POD_IP 6379

Expected Output: OK

Step 5: Verify Data Synchronization

Check the replication status metrics on the target pod to verify that the dataset cloning phase is complete and the connection status remains stable.

kubectl exec -n "$NS" "$NEW_POD_NAME" -- valkey-cli -a "$PASS" --no-auth-warning info replication

Review the output buffer and ensure that the master_link_status key reads up before proceeding to the database cutover step.

Step 6: Promote the New Pod to Primary (Cutover)

Once the underlying data is fully synchronized between instances, sever the data replication pipeline link. This operation promotes the target instance to a standalone, primary database.

kubectl exec -n "$NS" "$NEW_POD_NAME" -- valkey-cli -a "$PASS" --no-auth-warning replicaof no one

Expected Output: OK

Step 7: Update Application Routing

Update your application deployment configurations to redirect active workloads to the newly established database instance.

  1. Open your custom deployment configurations file (such as your chart's values.yaml).

  2. Locate the parameter block controlling your data store location (e.g., valkeyHost or the database connection string definition).

  3. Modify the value properties to point to the new release name: valkey-new.

  4. Redeploy your application containers to apply the infrastructure routing changes.

Step 8: Cleanup Old Resources

After validating that the application components are successfully communicating with the target Valkey instance and passing health checks, safely remove the legacy Bitnami infrastructure components.

Run the following commands to delete the old Helm release and its associated Persistent Volume Claims (PVC):

helm uninstall valkey -n "$NS"
kubectl delete pvc -l app.kubernetes.io/instance=valkey -n "$NS"

Results

The database migration to the official Valkey chart is complete. The UnO Agentic AI Builder infrastructure components are successfully upgraded to version 2.1.6.0 with database consistency preserved.