Skip to content

Maintenance

Kubernetes Apps

Container image updates for Kubernetes apps are handled automatically by Flux image automation — no manual intervention needed. See GitOps — Image Automation for how this works.

Note

Helm chart version updates are managed manually by bumping the version constraint in the relevant HelmRelease and pushing to the flux branch.

NAS Docker Containers

Watchtower runs on the NAS and automatically updates all Docker containers. It polls for new images every 24 hours, pulls updates, recreates affected containers, and removes old images (WATCHTOWER_CLEANUP: true).

No per-container opt-in is required — Watchtower watches all running containers by default.

Talos & Kubernetes Upgrades

Talos OS and Kubernetes version upgrades are managed via tuppr, a GitOps-native upgrade controller. Target versions are declared in flux/infrastructure/noah/tuppr/upgrade-plan.yaml:

apiVersion: tuppr.home-operations.com/v1alpha1
kind: TalosUpgrade
spec:
  talos:
    version: v1.12.4
---
apiVersion: tuppr.home-operations.com/v1alpha1
kind: KubernetesUpgrade
spec:
  kubernetes:
    version: v1.35.0

Bumping a version and pushing to the flux branch triggers a rolling upgrade — tuppr upgrades one node at a time with health checks between each, so the cluster stays available throughout.

Upgrade order

Always upgrade Talos first, then Kubernetes. Check the Talos support matrix to confirm compatible version combinations before bumping.

OpenTofu Drift

The taloser OpenTofu module tracks the Talos image version in tofu/tf-deploy/noah/locals.tf:

image = {
  version = "v1.12.4"
  ...
}

tuppr upgrades nodes in-place — it does not go through OpenTofu. After a tuppr upgrade, the running Talos version on all nodes will differ from what OpenTofu last applied, causing OpenTofu to detect drift on the next tofu plan.

To keep OpenTofu in sync, both files must be bumped together in the same commit:

  1. flux/infrastructure/noah/tuppr/upgrade-plan.yaml — triggers the actual rolling upgrade via tuppr
  2. tofu/tf-deploy/noah/locals.tf (image.version) — updates OpenTofu's desired state to match

Talos schematic in machine config

The Talos machine configs set machine.install.image to the factory installer URL built from the schematic ID and target version — e.g. factory.talos.dev/installer/<schematic-id>:<version>. When tuppr performs an upgrade, it reads this field from the running machine config to determine which image to pull, ensuring the upgrade uses the correct schematic with all required extensions (iSCSI, NFS, etc.). If this field pointed to a plain upstream image, tuppr would upgrade to a vanilla Talos image and the node would lose its extensions.

Proxmox

Proxmox is upgraded manually via the web UI or shell using the standard Debian apt workflow:

apt update && apt dist-upgrade

Note

Each Proxmox node is upgraded independently. No automation is in place — Proxmox updates are infrequent and warrant manual review before applying.