Skip to content
Homelab as Code logo Homelab as Code

Update applications

Renovate handles updates in the lab, so you do not bump version numbers by hand. It watches the pinned versions across the repo and prepares the changes. The config sets dependencyDashboardApproval, so nothing opens a pull request on its own: you decide what gets updated and when.

Taking an update from available to running is a short loop.

flowchart LR
  ren["Renovate run"] --> dash["Dependency Dashboard"]
  dash -->|tick to approve| pr["Pull request"]
  pr --> ci["GitHub Actions checks"]
  ci -->|merge| git["Git"]
  git --> apply["Applied to the lab"]

How updates surface

Section titled “How updates surface”

Renovate runs inside the cluster, managed by renovate-operator rather than the hosted Mend app. Runs happen on a schedule and in response to webhooks, so the list of available updates stays current without anyone doing anything. renovate-operator also exposes a small web UI on the tailnet where you can trigger a run by hand and watch its logs, but most days you will not need to open it.

Each run refreshes the Dependency Dashboard, a GitHub issue titled “Dependency Dashboard” in the repo. It lists every update Renovate has found, grouped by status. With approval turned on, most of them sit in a pending section and wait for you.

Approve and merge an update

Section titled “Approve and merge an update”
  1. Open the Dependency Dashboard issue in the repo.
  2. Find the update you want and tick its checkbox. That is the approval Renovate is waiting for.
  3. On its next run, Renovate creates a branch and opens a pull request for that update. Some updates are grouped (Talos, the Proxmox provider, and a few others), so one approval can produce a single PR covering several related bumps.
  4. Let the GitHub Actions checks run. Manifests go through Kustomize build validation, and the runner image, Terragrunt, shell scripts, and YAML each have their own check.
  5. Review the diff and the release notes Renovate includes in the PR body, then merge. Nothing automerges here, so every update is a deliberate merge.

Once the PR is merged, the version bump is just another commit, and where it takes effect depends on what was updated.

Where the update lands

Section titled “Where the update lands”
What Renovate bumpedHow it gets applied
App and add-on charts or image tags under kubernetes/cluster/activeArgo CD syncs the change automatically once it is in Git. Nothing else to do.
Runner toolchain in the Dockerfile (OpenTofu, Terragrunt, talosctl, kubectl, Helm, Kustomize, Ansible, and so on)The bake-image workflow rebuilds and pushes the runner image. The new versions are in effect the next time you pull that image.
OpenTofu providers and other infrastructure pinsApply on the next provisioning run for that layer.
Talos and Kubernetes versionsRolled out by tuppr, which carries out the node and cluster upgrades.
GitHub Actions versionsUsed on the next workflow run.

So for the apps themselves, the work ends at the merge: Argo CD does the rest. The other categories need their normal workflow to run before the update is live. The GitOps half of that is explained in How a change reaches the cluster.

Section titled “Related”