homelab/renovate

Renovate for Gitea

Renovate runs as a Kubernetes CronJob and creates container image update pull requests in Gitea. It does not deploy changes itself.

Kubernetes

Create a dedicated Gitea user named renovate-bot, create a repository access token, and grant it repository read/write plus issue read/write permissions. Add read:packages if Renovate must inspect private Gitea registry images.

Create the ignored Secret locally; never commit the PAT:

cp renovate/k8s/secrets.yaml.example renovate/k8s/secrets.yaml
$EDITOR renovate/k8s/secrets.yaml
kubectl apply -f renovate/k8s/namespace.yaml
kubectl apply -f renovate/k8s/secrets.yaml
kubectl apply -f renovate/k8s/configmap.yaml
kubectl apply -f renovate/k8s/cronjob.yaml

The renovate/k8s/active marker makes the normal deployment workflow include the namespace, ConfigMap, and CronJob. The Secret is intentionally excluded from Git and must be applied separately after every new cluster.

Run it immediately instead of waiting for the six-hour schedule:

kubectl create job --from=cronjob/renovate renovate-manual-$(date +%s) -n renovate

Inspect runs with:

kubectl get cronjob,jobs,pods -n renovate
kubectl logs -n renovate job/<job-name>

RENOVATE_GITHUB_COM_TOKEN is optional but recommended for changelogs and GitHub API rate limits. Set it in the Kubernetes Secret if available.

Compose

Copy .env.example to .env, set the PAT, and run:

docker compose -f renovate-compose.yaml run --rm renovate

The Compose file is intentionally named renovate-compose.yaml, so the repository's automatic deployment discovery does not start it accidentally.

How updates flow

Renovate scans both compose.yaml files and Kubernetes manifests, opens a branch and PR with image tag changes, and waits for CI. After merge, the existing deployment workflow applies Kubernetes changes or redeploys Compose stacks. Renovate never updates running workloads directly.