renovate-operator and running Renovate as Kubernetes jobs

Renovate as a workload, not a cron job

The repository description is one line: an operator to streamline Renovate executions in Kubernetes. The readme expands it into the pitch, running Renovate on your own infrastructure with CRD-based scheduling, parallel execution, auto-discovery and a built-in UI.

The framing is precise. If you self-host Renovate and already run Kubernetes, the operator is positioned as giving you the control and observability that plain self-hosted setups lack. That is the actual claim, and the comparison table in the readme is a feature-by-feature account of it.

The table has three columns, the Mend Renovate CLI, the Mend Renovate Community Self-Hosted, and the operator, and it separates capabilities that come from Renovate itself from capabilities that come from running it inside a cluster. Fully open source with no signup or licence key, automated dependency updates, running on your own infrastructure and auto-discovery are all shared. What only the operator adds is the webhook API for on-demand runs, the web UI, declarative cron scheduling via CRD, auto-discovery with group and topic filtering, per-project status tracking in-cluster, parallel execution with concurrency control, Kubernetes-native pod scheduling, leader election for high availability, and job lifecycle management with TTL, deadlines and retries.

The comparison with Mend Community Edition shows the operator is not only about Renovate features. Prometheus metrics and health checks are listed as present in both the operator and the Community Edition, and missing from the CLI. What the operator adds over the Community Edition is the cluster-native layer: CRDs, jobs, a UI and leader election.

The audience is a platform team that already operates Kubernetes and is tired of a self-hosted Renovate running as an opaque container.

Two phases: discovery first, then one job per project

The readme describes how the operator works in five steps, and the sequencing is the part that matters.

At the defined time of your schedule, a renovate discovery job is started. After the discovery finished, you can see all your discovered projects in the UI. All projects are then set to be scheduled. Every 10 seconds the operator checks for scheduled projects and starts a new renovate job. And only as many jobs as defined in spec.parallelism are getting executed at the same time.

So discovery is a batch job that enumerates what exists, and the actual work is a stream of per-project jobs, dispatched by the operator on a ten second tick and bounded by spec.parallelism.

That has two consequences worth understanding before you deploy it. First, the discovery job is where the platform credentials are used to enumerate repositories, so the operator needs broad read access to your forge before it needs any write access at all. Second, the ten second check interval means a project scheduled at time T starts within ten seconds of that, which is fine for dependency updates and means a burst of newly discovered projects does not immediately flood the cluster.

The concurrency limit is what keeps a large estate from turning into hundreds of simultaneous Renovate containers, and it is declared in the custom resource rather than in a config file, which is the operator-native way to express a limit that has to be reconciled by the cluster.

Installing with Helm, from a registry or a repo

There are two documented Helm routes, and the newer one is an OCI registry rather than a classic chart repository.

The OCI option installs directly from a registry path:

helm -n renovate-operator upgrade --install renovate-operator \
  oci://ghcr.io/mogenius/helm-charts/renovate-operator \
  --create-namespace --wait

The second option adds the chart repository and installs from it:

helm repo add mogenius https://helm.mogenius.com/public --force-update
helm -n renovate-operator upgrade --install renovate-operator mogenius/renovate-operator --create-namespace --wait

Both use upgrade --install, so the same command installs on a fresh cluster and rolls forward on an existing one, and both pass --create-namespace and --wait so the namespace is created and the operator is considered ready before helm returns.

The chart is published on Artifact Hub, which is the badge in the header, and the repository also carries a charts/ directory, so the chart sources are in the repository rather than only in a separate chart repository.

On platform coverage, the readme says the operator supports all Renovate platforms, naming GitHub, GitLab, Bitbucket, Azure DevOps, Gitea and more, and that it works with any platform supported by Renovate, configured through environment variables or secrets. The caveat it adds is specific: some platforms have additional operator-specific features, such as native webhook integrations for GitHub and GitLab.

Running the operator locally needs two exported variables

The development section is unusually specific about the two things that break a local run, and both are worth knowing before you try.

First, KUBECONFIG must be exported with the absolute path to your kubeconfig, and the readme is explicit that the tilde is not expanded, so you use $HOME or the full path:

export KUBECONFIG=/Users/yourname/.kube/config
# or
export KUBECONFIG=$HOME/.kube/config

It also notes that KUBECONFIG may name several files separated by a colon, and that they are merged the way kubectl merges them.

Second, and more interesting, a local run has no pod and therefore no namespace of its own. The setup guide's secret check refuses every namespace in that state, deliberately, so a cluster-exposed UI cannot probe secrets in namespaces that are none of its business, and it logs why. The workaround is to export POD_NAMESPACE with the namespace you are setting up to exercise that step locally:

export POD_NAMESPACE=renovate-operator

That design decision is worth reading twice. The operator has a feature that can read secrets across namespaces, and rather than letting that feature fail in a confusing way in development, it fails loudly with a log explaining the reason. A local developer hitting that error learns what the check is for.

The tooling is just. The prerequisites say just must be installed, then just run starts the operator against the current context, and just run loads .env, so both variables can live there instead of your shell.

The container image is a scratch image with a Node stage for the UI

The Dockerfile is worth reading because it shows what the operator actually ships.

The builder stage is golang 1.27.2-alpine with CGO_ENABLED=0, and the binary is built with the timetzdata build tag, trimmed paths, inlining disabled across all packages, and the version stamped in through a linker flag. The cross-compilation arguments are the standard TARGETOS, TARGETARCH and TARGETVARIANT set, with the arm variant suffix stripped.

There is a second stage, node 24.22.0-alpine, whose only job is the web interface. It downloads Tailwind CSS and the Babel standalone bundle at build time, then installs React 19 with esbuild, bundles a small entry module that re-exports React and createRoot, and writes the result to src/static/js. So the React runtime, the styling and the transpiler are all resolved during the image build rather than fetched at runtime.

The final image is FROM scratch. It copies the CA certificate bundle from the builder, the operator binary, the static assets, and the JavaScript bundle from the Node stage, sets a non-root user with USER 1000:1000, and declares the entrypoint as the operator binary itself.

A scratch image is a defensible choice for a controller. There is no shell and no package manager in the running container, so the attack surface of a compromised operator pod is as small as it can be. The cost is that debugging inside the container is harder, and the image carries no general purpose utilities.

What the operator does not decide for you

Three limits are visible in the documentation.

The first is that the operator is not Renovate. The readme is clear that it works with any platform supported by Renovate and that you configure credentials and platform settings through environment variables or secrets. Every policy decision about which updates to open, how to group them, when to schedule them and what to ignore is still Renovate's configuration, and the readme does not document how the two configurations are layered. A team migrating from a self-hosted Renovate keeps its renovate.json and adds the operator around it.

The second is the scale of what the operator automates. Auto-discovery finds repositories and schedules them, and the readme describes it as auto-discovery with group and topic filtering, which means the operator can filter what it discovers. But the repository structure shows that the operator's own configuration, the CRDs, the Justfile and the charts, is a separate surface from Renovate's, and the getting-started guide in docs/getting-started.md is where the two meet.

The third is the platform-specific extras. The readme notes that some platforms have additional operator-specific features like native webhook integrations for GitHub and GitLab, which is a hint that the operator's webhook support is not uniform across forges. A team on Gitea or Azure DevOps should not assume the on-demand run capability they see in the table is equally complete.

There is also a USERS.md in the repository root, which is a directory of adopters, and a CODEOWNERS file, which together suggest an actively maintained project with a community around it.

Editorial conclusion

renovate-operator is a good fit for a platform team that already runs Kubernetes and wants dependency updates to be scheduled, observable and reconciled by the cluster rather than by a cron job, because the operator turns Renovate runs into jobs with deadlines, retries and per-project status you can watch. It is a poor fit for a single repository or a team that does not run Kubernetes, since the operator's whole value is cluster-native scheduling. Before adopting, read the comparison table in the readme against your current setup, plan the credential story for the platforms you use, and note that a local development run needs a kubeconfig and a pod namespace exported by hand, because a local run has no pod and therefore no namespace of its own.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mogenius/renovate-operator on GitHub
4. README
5. Releases