Update a DV
It is highly recommended to upgrade your DV stack from time to time. This ensures that your node is secure, performant, up-to-date and you don't miss important hard forks.
To do this, follow these steps:
- charon-distributed-validator-node
- charon-distributed-validator-cluster
- Helm
cd charon-distributed-validator-node
Pull latest changes to the repo​
git pull
Create (or recreate) your DV stack​
docker compose up -d --build
If you run more than one node in a DV Cluster, please take caution upgrading them simultaneously. Particularly if you are updating or changing the validator client used or recreating disks. It is recommended to update nodes on a sequential basis to minimize liveness and safety risks.
Conflicts​
You may get a git conflict error similar to this:
error: Your local changes to the following files would be overwritten by merge:
prometheus/prometheus.yml
Please commit your changes or stash them before you merge.
This is probably because you have made some changes to some of the files, for example to the prometheus/prometheus.yml file.
To resolve this error, you can either:
-
Stash and reapply changes if you want to keep your custom changes:
git stash # Stash your local changesgit pull # Pull the latest changesgit stash apply # Reapply your changes from the stashdocker-compose up -d --build # Recreate your DV stackAfter reapplying your changes, manually resolve any conflicts that may arise between your changes and the pulled changes using a text editor or Git's conflict resolution tools.
-
Override changes and recreate configuration if you don't need to preserve your local changes and want to discard them entirely:
git reset --hard # Discard all local changes and override with the pulled changesgit pull # Pull the latest changesdocker-compose up -d --build # Recreate your DV stackAfter overriding the changes, you will need to recreate your DV stack using the updated files. By following one of these approaches, you should be able to handle Git conflicts when pulling the latest changes to your repository, either preserving your changes or overriding them as per your requirements.
cd charon-distributed-validator-cluster
Pull latest changes to the repo​
git pull
Create (or recreate) your DV stack​
docker compose up -d --build
If you run more than one node in a DV Cluster, please take caution upgrading them simultaneously. Particularly if you are updating or changing the validator client used or recreating disks. It is recommended to update nodes on a sequential basis to minimize liveness and safety risks.
Conflicts​
You may get a git conflict error similar to this:
error: Your local changes to the following files would be overwritten by merge:
prometheus/prometheus.yml
Please commit your changes or stash them before you merge.
This is probably because you have made some changes to some of the files, for example to the prometheus/prometheus.yml file.
To resolve this error, you can either:
-
Stash and reapply changes if you want to keep your custom changes:
git stash # Stash your local changesgit pull # Pull the latest changesgit stash apply # Reapply your changes from the stashdocker-compose up -d --build # Recreate your DV stackAfter reapplying your changes, manually resolve any conflicts that may arise between your changes and the pulled changes using a text editor or Git's conflict resolution tools.
-
Override changes and recreate configuration if you don't need to preserve your local changes and want to discard them entirely:
git reset --hard # Discard all local changes and override with the pulled changesgit pull # Pull the latest changesdocker-compose up -d --build # Recreate your DV stackAfter overriding the changes, you will need to recreate your DV stack using the updated files. By following one of these approaches, you should be able to handle Git conflicts when pulling the latest changes to your repository, either preserving your changes or overriding them as per your requirements.
Update the Helm repository​
helm repo update obol
helm search repo obol/dv-pod --versions | head # available chart versions
helm list -n dv-pod # the chart version you run now
Upgrade the release​
Pin the chart version you're moving to:
helm upgrade my-dv-pod obol/dv-pod --version 0.22.0 -n dv-pod --reuse-values
This upgrades your Charon and validator client containers to that chart version while keeping your existing configuration values. Without --version, Helm installs whatever chart is newest in the repository.
Check the chart changelog before upgrading to review any breaking changes or new configuration options.
Chart 0.22.0 reworks how the pod starts. Read the chart's upgrade notes first. In short:
- The pod gets new init containers (
dkg-sidecar,charon-dkg,dkg-report) that run on every start, including on nodes that already have a cluster-lock, where they finish straight away. The upgrade restarts the pod, and it can't start until it can pull theobolnetwork/charon-dkg-sidecarimage version that the chart uses. Check that image is published before you upgrade. - Your node keeps its identity. The chart reuses the ENR Secret the release already mounts, and it never generates a new key on upgrade. New installs get a per-release Secret,
<release>-enr-key. - Existing releases keep
mode: auto, which works out the same behaviour as before from your values. - The values schema is now strict: unknown keys are rejected. Remove typos, and keys the chart never had, from your values.
charon.builderApiandcharon.directConnectionEnabledare booleans, and"false"now really turns them off.- A readiness probe (
/readyz) is on, and volumes are kept when the StatefulSet is deleted or scaled down.
After the upgrade, check that the pod is Running and Charon is ready (kubectl get pod my-dv-pod-0 -n dv-pod).
With the Obol agent skills installed, paste this into Claude Code:
Upgrade my DVpod to the latest dv-pod chart release, pinned with --version. Review the changelog for breaking changes first and confirm the cluster is healthy afterwards.
If you run more than one node in a DV Cluster, please take caution upgrading them simultaneously. Particularly if you are updating or changing the validator client used or recreating disks. It is recommended to update nodes on a sequential basis to minimize liveness and safety risks.