Skip to content

Renovate (dependency updates)

Dependency bumps — Helm charts and container images — are proposed automatically by Renovate, which opens and updates pull requests against each GitOps repo. Humans review and merge; nothing lands unattended except an explicit allowlist.

How it runs

A renovate CronJob in the platform-shared namespace runs daily. It reads each repo's renovate.json and opens/refreshes PRs. To run it on demand:

kubectl create job --from=cronjob/renovate renovate-manual -n platform-shared

Per-repo config (renovate.json)

  • customManagers match specific file paths to catch versions Helm's own detection misses — e.g. a container image tag pinned in a values.yaml. A new applications/<app>/ that pins such a tag needs its own customManager entry, or Renovate won't track it.
  • packageRules control grouping, scheduling, and automerge policy.

Reading a Renovate PR

  • Cooldown / stability-days: a new release can be held for a stability window before it's eligible to merge. While it's held, treat it as do not merge — wait for the window to clear.
  • Automerge is opt-in per repo via an allowlist and is never applied to Helm chart bumps — those always get a human review.

Merge discipline

  • Bump one load-bearing dependency at a time; when something is deployed to all three ArgoCD instances, canary the least-critical one first and verify before the rest.
  • After merging, let ArgoCD sync — or trigger it yourself (see Operations).

Operator-managed images: pin to the certified matrix

When a container image is deployed by a downstream operator (a database operator, a mesh operator, a storage operator) rather than wired directly by a chart, that image's version is constrained by the operator's own compatibility/certification matrix — and Renovate's "latest patch on the registry" view does not know that. Running an operand newer than the operator certifies is untested and can misbehave in subtle ways.

Rule: pin operator-managed operands (e.g. the database server, connection pooler, and backup tool images an operator injects) to the operator's certified tags, and bump them by hand, coupled with the operator upgrade — never as independent Renovate PRs. In renovate.json, disable tracking for those exact image names and record the certified tags (and the matrix URL) in a comment beside them. A version-range boundary is a weaker guard here — build-suffix versioning (X.Y-Z) can let an off-matrix tag slip through a naive <N cap.

A 'no breaking changes' release note is not a safety guarantee for an operator-managed image

Human-facing release notes describe user-visible behaviour. They do not describe the internal contract an operator depends on — the daemon API, the environment-variable contract, gRPC additions — any of which can break operator-injected configuration without ever being flagged "breaking." When a Renovate PR bumps an operator-managed image past the range the operator is tested against, canary it first or hold it; do not rate it "safe to merge" from the release notes alone.

Automerge and holds — the policy shape

  • Allowlist, not denylist. Enable automerge per exact package name, not by trying to enumerate everything risky. A denylist's worst case is one missed entry and an outage; an allowlist's worst case is just more PRs in the manual queue. A package qualifies for the allowlist only if all of: it's a plain container image (not a chart/CRD/operator); it's single-purpose with no schema or state; a broken update has bounded blast radius (at worst a transient pod or one-shot Job); and failure is observable within hours.
  • Never automerge anything that ships CRDs, hook Jobs, or schema — that means essentially every Helm chart, every operator, and the GitOps controller itself (a broken controller patch can't be rolled back through GitOps).
  • Don't use a version cap to "force review" or "be cautious." A cap suppresses the PR entirely, so you never learn the release exists and silently fall behind — which only makes the eventual jump riskier. The manual review-and-merge of a non-automerged update is already the review gate. Reserve version caps for a confirmed incompatibility you must not adopt at all, and put general caution in the rule's description, not in a cap.

Pin tags from day one

Never add an image to a chart with :latest or any floating tag — pin a specific version (ideally with a @sha256: digest), and the same for OCI chart refs. The whole propose-upgrades-against-a-known-baseline model depends on it; a floating tag means a surprise upgrade on the next pod restart.

See also: Architecture · Operations · Sealed Secrets.