../../_images/kup6s-icon-deployment.svg

Renovate

Self-hosted Renovate bot that watches upstream releases and opens merge requests to bump pinned versions in the GitOps repositories. It runs as nightly Kubernetes CronJobs against git.bluedynamics.eu and covers kup6s/dp/dp-kup, kup6s/dp/dp-infra, heidi/helix-infra-charts, and heidi/helix-argocd.

One Renovate run authenticates with exactly one platform token, and GitLab group access tokens are bound to their group. The bot therefore runs one instance per GitLab group: the renovate CronJob for kup6s/dp and the renovate-helix CronJob for heidi.

Overview

Renovate detects new upstream versions, opens a merge request per update, and assigns it to a maintainer. For CDK8S deployments it also regenerates the Kubernetes manifests inside the same merge request, so that a merge is a deploy.

Component

Implementation

Runner

CronJobs renovate (01:23) and renovate-helix (02:23) in namespace renovate, image renovate/renovate:*-full, nightly Europe/Vienna

Platform auth

One GitLab group access token per instance (bot user, api scope, Developer on group kup6s/dp and on group heidi), delivered via ESO

Global config

One ConfigMap per instance (renovate-config, renovate-config-helix) — platform, repositories, allowedCommands, git author

Per-repo config

renovate.json at the root of each managed repository

Deployment

CDK8S in dp-infra/renovate/, ArgoCD application renovate-app-c8be48c9

Alerting

RenovateRunStale PrometheusRule (>36h without a successful run) plus the stock KubeJobFailed

How an update flows

  1. The nightly run extracts dependencies from both repositories.

  2. For a pinned chart or image version, a comment annotation tells Renovate where to look upstream.

  3. Renovate opens a merge request that bumps the version and, for CDK8S deployments, runs a postUpgradeTasks build to regenerate the committed manifests.

  4. The bot assigns the merge request to the maintainer, who receives a GitLab email.

  5. Merging to main triggers the normal ArgoCD auto-sync — the merge is the deploy.

Renovate never merges on its own. A human reviews every merge request, which is the control point for a live cluster.

See also

Design and rollout are recorded in docs/superpowers/specs/2026-07-26-renovate-kup6s-design.md.

Scope

The comment-annotation manager and manifest regeneration are wired fleet-wide across dp-kup and dp-infra, and for the helix-prod infrastructure components in helix-infra-charts (cnpg, ingress/Traefik, strimzi, pages, admin-access, observability). The standard managers (npm, Dockerfile, Helm) run across all repositories without extra configuration and open review-only merge requests for everything else.

The helix coverage is deliberately limited to infrastructure:

  • heidi/heidi.cloud (the application itself) is not a managed repository.

  • In helix-infra-charts, the monitoring/ component (helix-stage, GitOps-frozen) and staging-secrets/ are excluded through ignorePaths.

  • heidi/helix-argocd receives npm toolchain updates only, against its deployed production branch (baseBranches); its ArgoCD applications carry no version pins.

Table of contents