HashiCorp Vault — Upgrade Strategies
Upgrading Vault requires careful planning to avoid downtime and data loss — especially in production HA clusters.
Upgrade Rules
- Always read the release notes — check for breaking changes
- Never skip major versions — upgrade incrementally (1.14 → 1.15 → 1.16)
- Backup before upgrading — take a Raft snapshot
- Test in staging first — mirror your production setup
- Upgrade standby nodes first — then the leader
Pre-Upgrade Checklist
# 1. Check current version
vault version
# 2. Read upgrade notes
# https://developer.hashicorp.com/vault/docs/upgrading
# 3. Take a backup
vault operator raft snapshot save pre-upgrade-$(date +%Y%m%d).snap
# 4. Verify cluster health
vault status
vault operator raft list-peers
# 5. Check for deprecations
vault operator diagnose
Single-Server Upgrade
# 1. Stop Vault
sudo systemctl stop vault
# 2. Replace binary
sudo cp vault /usr/local/bin/vault
sudo chmod +x /usr/local/bin/vault
# 3. Verify new version
vault version
# 4. Start Vault
sudo systemctl start vault
# 5. Unseal (if not using auto-unseal)
vault operator unseal
# 6. Verify
vault status
HA Cluster Rolling Upgrade
Step 1: Identify the Leader
# Check who is the leader
vault operator raft list-peers
# Note: upgrade standbys FIRST
Step 2: Upgrade Standby Nodes
For each standby node:
# On standby node:
# Stop Vault
sudo systemctl stop vault
# Replace binary
sudo cp vault-new /usr/local/bin/vault
sudo chmod +x /usr/local/bin/vault
# Start Vault (auto-unseals and rejoins the cluster)
sudo systemctl start vault
# Verify
vault status
vault operator raft list-peers
Step 3: Step Down the Leader
# On the leader node:
vault operator step-down
# A standby (already upgraded) becomes the new leader
Step 4: Upgrade the Former Leader
# Now upgrade the old leader (now a standby)
sudo systemctl stop vault
sudo cp vault-new /usr/local/bin/vault
sudo systemctl start vault
# Verify full cluster
vault operator raft list-peers
Kubernetes Helm Upgrade
# Update Helm repo
helm repo update hashicorp
# Check available versions
helm search repo hashicorp/vault --versions
# Dry run
helm upgrade vault hashicorp/vault \
--namespace vault \
--values values.yaml \
--dry-run
# Upgrade (Helm handles rolling update)
helm upgrade vault hashicorp/vault \
--namespace vault \
--values values.yaml
# Monitor rollout
kubectl rollout status statefulset vault -n vault
Rollback Plan
If the upgrade fails:
# 1. Stop the upgraded node
sudo systemctl stop vault
# 2. Restore the old binary
sudo cp vault-old /usr/local/bin/vault
# 3. If data migration occurred, restore snapshot
vault operator raft snapshot restore pre-upgrade-20240115.snap
# 4. Start with old version
sudo systemctl start vault
Version Compatibility
| Scenario | Compatible? |
|---|---|
| Mixed versions in HA cluster (during upgrade) | ✅ (briefly) |
| Newer leader, older standby | ✅ |
| Older leader, newer standby | ✅ |
| Skip major versions (1.14 → 1.16) | ❌ |
| Downgrade after data migration | ❌ |
Upgrade Timeline
| Phase | Duration | Action |
|---|---|---|
| Prep | 1–2 days | Read notes, test in staging |
| Backup | 5 min | Raft snapshot |
| Standbys | 5–10 min each | Rolling restart |
| Leader step-down | 1 min | Seamless failover |
| Old leader | 5–10 min | Upgrade last node |
| Verify | 15 min | Health checks, smoke tests |
Next: Security Model