// the take
Renovate Operator is a Kubernetes operator that runs Renovate (the dependency-update bot) as CRD-defined jobs instead of a single cron container, adding a web UI, webhooks, and multi-platform support (GitHub, GitLab, Bitbucket, Gitea, Forgejo). It's for teams already running Kubernetes who self-host Renovate at a scale where one cron job and a shared renovate.json stop being enough.
CRD-based scheduling (RenovateJob, RenovateJobTemplate, ClusterRenovateJobTemplate, RenovateProject) gives declarative, per-project cron and concurrency control instead of one monolithic cron string. Native webhook handlers for GitHub, GitLab, Gitea, and Forgejo trigger on-demand runs rather than waiting on a fixed interval. Leader election, Prometheus metrics, a Grafana dashboard, and pluggable log storage (S3, Valkey) suggest someone has actually run this in production and hit the HA and log-retention pain points. Auto-discovery with group/topic filtering plus in-cluster per-project status tracking beat grepping CI logs across hundreds of repos.
This trades a single cron container for four CRDs, a webhook ingress/listenerset, an OIDC/GitHub-OAuth login flow, and optionally Valkey and S3 — a lot of extra infrastructure to run and secure compared to Renovate CLI alone. A documented v5-to-v6 migration means the CRD schema has already broken compatibility once and could again. Running inside the cluster means the operator needs credentials for every platform it talks to (GitHub App keys, PATs) plus RBAC to manage jobs, which is more secret surface than a single CI job. The webhook and UI auth paths (session store, access checks, namespace checks) are hand-rolled rather than delegated to a well-worn framework, which is worth scrutiny before exposing the UI publicly.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →