Auto-Upgrade | Kubeadapt

When enabled, a sidecar runs alongside the agent and periodically checks for new chart versions. If a safe upgrade path exists, it applies the update and reports the result to the dashboard.

Why Auto-Upgrade

Keeping Kubeadapt up to date across a handful of clusters is manageable. At 20+ clusters it becomes a maintenance tax that scales linearly with your fleet and adds zero business value.

Auto-upgrade eliminates that overhead. Every cluster checks for updates independently, upgrades itself on its own schedule, and reports the result back to the dashboard. You get a single view of all cluster versions and upgrade history.

Enable It

yaml

agent:
  autoUpgrade:
    enabled: true

Or at install time:

bash

helm install kubeadapt kubeadapt/kubeadapt \
  --namespace kubeadapt \
  --create-namespace \
  --set agent.config.token="<your-token>" \
  --set agent.autoUpgrade.enabled=true

The Update Model

Prevention over recovery.

Kubeadapt Cloud maintains a version graph of chart releases. Each version declares which previous versions can safely upgrade to it. The platform filters this graph based on your upgrade policy, channel, and detected cloud provider, then presents the upgrader with available paths.

The upgrader is stateless. It asks Kubeadapt Cloud "what should I upgrade to?", gets a target version (or nothing), and applies the update. The operation is atomic and locked; no other process can modify the chart release until the cycle completes. If the upgrade fails, Helm rolls back automatically.

Note

The upgrader uses --reset-then-reuse-values instead of --reuse-values. New chart defaults take effect while your explicit overrides (like agent.config.token) are preserved. When you upgrade manually, pass the same flag to get the same behavior.

Blocked edges

If a released version turns out to have a bug, it gets removed from the graph. Clusters that have not yet upgraded never see that version. Clusters already on the bad version get a path that skips over it in the next cycle. The fix ships as a new version that all affected clusters pick up automatically.

Multi-hop upgrades

When the gap between current and target is large, Kubeadapt Cloud returns a sequential path: 0.17.0 -> 0.18.0 -> 0.18.5. The upgrader executes one hop per check cycle, ensuring each intermediate version's defaults are applied in order.

Platform-aware updates

The upgrader auto-detects your cloud provider (EKS, AKS, GKE, or on-premise) at startup. Platform gets sent with every update check, so Kubeadapt Cloud can scope versions by environment. Your clusters only receive patches relevant to them.

Configuration

All values live under agent.autoUpgrade.

Value	Type	Default	Description
`enabled`	bool	`false`	Enable the auto-upgrade sidecar.
`checkInterval`	string	`"24h"`	How often to check for updates.
`dryRun`	bool	`false`	Detect updates and log them without applying.

Upgrade Policy

Value	Type	Default	Description
`policy`	string	`"minor"`	Controls which versions to upgrade to.

patch : Only patch versions. 0.17.0 can upgrade to 0.17.1 but not 0.18.0.
minor : Minor and patch versions. 0.17.0 can upgrade to 0.18.0. This is the default.
all : All versions including major. Use with caution since major versions may contain breaking changes.

Release Channel

Value	Type	Default	Description
`channel`	string	`"fast"`	Release channel to follow.

fast : New features ship here first. Currently the default.
stable : Production-ready releases with additional soak time. Will become the default after v1.

Note

Both channels receive security fixes. We have not released a v1 chart yet, so all releases currently go through fast. Once v1 ships, stable will become the default channel.

Monitoring

Every upgrade attempt is visible in the dashboard under Clusters > Connectivity > Upgrade History.

Warning

The auto-upgrade service account has write access to the kubeadapt namespace. If you bring your own service account, make sure it has the required RBAC permissions listed in the generated ClusterRole.

Full Values Reference

The sections above cover what you need for enabling auto-upgrade and choosing your policy. For other configurations, see the full values.yaml.