In our previous post, we updated the Runtime Fabric license by deleting and re-creating a Kubernetes Secret directly with kubectl. That method works. But it has a weakness: it is imperative. We run a sequence of manual commands. We must remember the exact key name, the -w 0 flag, and the restart step. One missed command leaves things in a broken state.
Helm gives us a better way. Helm is the package manager for Kubernetes. If Runtime Fabric was installed with Helm — which is the standard deployment method — we can pass the new license directly to a
helm upgrade command. Helm handles the secret update and the agent rollout in one operation. In this post, we will see how to use the Helm method end to end.Why Helm Is a Better Fit for License Renewals
Thekubectl method treats the license secret as a standalone object. We manage it independently from the rest of the Runtime Fabric installation. That creates a gap between what Helm thinks is deployed and what is actually running in the cluster.The Helm method keeps everything in sync.
| Concern | kubectl Method | Helm Method |
|---|---|---|
| Secret management | Manual delete and re-create | Helm manages the secret |
| Agent restart | Manual rollout restart | Helm triggers it automatically |
| Drift risk | High — Helm state diverges | None — Helm state stays current |
| Auditability | No record in Helm | helm history tracks every change |
| Rollback | Manual | helm rollback in one command |
If our team uses GitOps or infrastructure-as-code practices, the Helm method is the right choice. It keeps our Helm release state accurate and gives us a full history of changes.
Expected output:
We note the
We also confirm which Helm values were used in the current installation. We will need them when we run the upgrade:
Prerequisites
We need the same Ubuntu server and Kubernetes environment from the previous post, plus:- Helm 3 installed on the server (
helm versionto verify) - The Helm release name for our Runtime Fabric installation
- The Helm chart repository for MuleSoft RTF added and updated
- The new
.licfile uploaded to the server (follow Step 1 from the previous post — all three upload options still apply)
helm list -n rtfNAME NAMESPACE REVISION STATUS CHART
runtime-fabric rtf 3 deployed rtf-agent-3.0.1 NAME value. In this example it is runtime-fabric. We use it in every helm command below.We also confirm which Helm values were used in the current installation. We will need them when we run the upgrade:
helm get values runtime-fabric -n rtf > /home/ubuntu/current-values.yaml
cat /home/ubuntu/current-values.yamlWe save that file. We will pass it back to Helm so we do not lose any existing configuration during the upgrade.
We SSH into the server:
We encode the file:
We verify the variable holds data:
We should see a long string. If the output is blank, the
We confirm this by inspecting the current values we exported in the prerequisite step:
We should see a line like:
Step 1 — Encode the License File on the Server
The Helm chart for Runtime Fabric accepts the license as a Base64-encoded string passed through a Helm value. We encode it the same way we did in thekubectl method — on the server, with the -w 0 flag.We SSH into the server:
ssh ubuntu@<SERVER_IP>LICENSE_B64=$(base64 -w 0 /home/ubuntu/muleSoft.lic)echo $LICENSE_B64 | head -c 100.lic file is missing or empty. We go back and upload it again.Step 2 — Identify the License Value Key in the Helm Chart
Before we run the upgrade, we need to know which Helm value key controls the license. This key is defined by the RTF Helm chart. The correct key is:muleLicensegrep -i license /home/ubuntu/current-values.yamlmuleLicense: <existing_base64_string>If the key is present, we know it is the correct one to override. If it is missing, Runtime Fabric may have been installed without the license value and it was set separately. In that case, the
Step 3 — Run
We run the upgrade. We pass our existing values file back to Helm with
kubectl method from the previous post is the safer choice for this installation.Step 3 — Run helm upgrade with the New License
We run the upgrade. We pass our existing values file back to Helm with -f so we preserve all current configuration. We then override only the muleLicense key with our new encoded value using --set.helm upgrade runtime-fabric rtf/rtf-agent \
-n rtf \
-f /home/ubuntu/current-values.yaml \
--set muleLicense="$LICENSE_B64" \
--reuse-values
-f: We use both here for safety. --reuse-values tells Helm to pull the values from the previous release as a base. The -f flag layers our exported values on top. The --set flag then overrides just the license key. This combination ensures no existing value gets dropped.Do not use
--set-file to pass the .lic file directly. The chart expects a Base64 string, not raw file content. Passing raw content will corrupt the secret.Expected output:
Release "rtf" has been upgraded. Happy Helming!
NAME: rtf
LAST DEPLOYED: <timestamp>
NAMESPACE: rtf
STATUS: deployed
REVISION: 4The revision number increments. That is our confirmation that Helm recorded this change.
Expected output:
We check all pods are healthy:
All pods should show
Step 4 — Verify the Rollout
Helm triggers a rollout of the rtf-agent deployment automatically. We watch it complete:
kubectl rollout status deployment/agent -n rtfdeployment "agent" successfully rolled outkubectl get pods -n rtfRunning status. If any pod is in CrashLoopBackOff, we check the logs:kubectl logs deployment/agent -n rtf -c rtfd| grep -i licenseA license error means the Base64 string was malformed. We check the Troubleshooting section below.
Expected output:
Revision 4 is our license update. Every future operator on this cluster can see exactly when the license was renewed and who ran the command.
Replace
The
The output should look like readable license text, not garbled characters. If it looks wrong, we roll back with
Step 5 — Confirm the License in Anypoint Platform
We log into Anypoint Platform, navigate to Runtime Manager, and open our Runtime Fabric instance. The fabric status should show healthy with no license warnings.
We also confirm the Helm history shows our new revision:helm history runtime-fabric -n rtfREVISION STATUS DESCRIPTION
1 superseded Install complete
2 superseded Upgrade complete
3 superseded Upgrade complete
4 deployed Upgrade completeRolling Back If Something Goes Wrong
This is where Helm earns its place. If the new license causes an unexpected problem, we roll back to the previous release in one command:
helm rollback rtf 3 -n rtf3 with the revision number of the last known-good release from helm history. Helm restores the old secret and triggers another rollout automatically.Troubleshooting
helm upgrade fails with "cannot re-use a name that is still in use"
This error does not apply to upgrade. If we see it, we may have run helm install instead of helm upgrade. We check the command and re-run with upgrade.
The muleLicense key is not in our current values
Our Runtime Fabric installation may have set the license outside of Helm. We verify by running:
helm get values rtf -n rtf --all | grep -i license--all flag shows default values too. If the key still does not appear, we use the kubectl method from the previous post for this installation.The agent pod crashes after the upgrade
We check whether the Base64 encoding was clean:
kubectl get secret mule-license -n rtf -o jsonpath='{.data.license}' | base64 -d | head -c 50helm rollback, re-encode with -w 0, and re-run the upgrade.kubectl vs Helm — Which Should We Use?
Both methods produce the same result. The right choice depends on how Runtime Fabric was installed.
| Situation | Use |
|---|---|
| RTF was installed with Helm | Helm method |
| RTF was installed with a script or operator | kubectl method |
| Team uses GitOps / IaC practices | Helm method |
| Quick fix needed with no Helm access | kubectl method |
| Auditability and rollback are required | Helm method |
When in doubt, check whether a Helm release exists with
helm list -n rtf. If a release is listed, use Helm. If no release is listed, use kubectl.Summary
| Step | Action |
|---|---|
| Prerequisites | Find Helm release name and export current values |
| 1 | Encode the .lic file on the server with -w 0 |
| 2 | Confirm the muleLicense key exists in our Helm values |
| 3 | Run helm upgrade with -f, --set, and --reuse-values |
| 4 | Watch the agent rollout complete |
| 5 | Verify status in Anypoint and review helm history |
The Helm method keeps our cluster state accurate, gives us a full audit trail, and makes rollback a single command. For any team running Runtime Fabric on a Helm-managed cluster, this is the method to standardize on.