[Feature] Persist logs of finished Renovate jobs (independent of Kubernetes Job TTL)

[acuntex]

Hi!

First of all, thanks for the great work on the Renovate Operator!

Current Behavior

When clicking on Logs in the Web UI for a Renovate job, the operator fetches the logs directly from the associated Kubernetes Pod.

This works perfectly while the job is still running.

However, if jobTTLSecondsAfterFinished is configured, Kubernetes deletes the Job (and therefore the Pod) after the TTL expires. As a result:

• The Pod is deleted
• The logs are no longer available
• The Web UI cannot display logs for previous runs

Problem

In environments where jobTTLSecondsAfterFinished is enabled (which is a reasonable cleanup strategy), historical logs of Renovate runs are lost shortly after completion.

This makes troubleshooting or reviewing past runs difficult, especially if issues are discovered later.

Proposed Enhancement

It would be great if the Renovate Operator could persist the logs of the last job runs independently of the Kubernetes Job lifecycle.

For example:

• After a job completes, the operator could retrieve and store the logs.
• Logs could be persisted in a lightweight storage backend (e.g. SQLite).
• The Web UI would then fetch logs from this internal storage instead of directly from the Pod when the Pod no longer exists.

Possible Implementation Ideas

• Store logs per Renovate CR (e.g., last run, maybe with timestamps and status).
• Keep only the most recent run to avoid unbounded storage growth.
• Make log persistence configurable (enabled/disabled/storage path).
• Optionally support a configurable retention policy (e.g., number of runs or time-based retention).

Benefits

• Logs remain available even when jobTTLSecondsAfterFinished is enabled.
• Better observability and debugging of past Renovate runs.
• Cleaner Kubernetes clusters without sacrificing log visibility.

If this idea aligns with the project direction, I’d be happy to help further clarify requirements or discuss possible approaches.

Thanks!

[lukashankeln]

Thank you for opening this issue 😄

We also thought about this for some time now.

File-based storage we ruled out so far. Because sharing that data would be tricky if running multiple replicas.

I was thinking about adding a Key-Value Store, e.g. Valkey that could store the logs.

That would add an extra Deployment to the Chart though.

[askedrelic]

CronJob history limits are a different native way I would think about this; I want to control how many previous pods/runs are kept. For a single node self hosted server, this is effective enough for me.

https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#jobs-history-limits

[acuntex]

That makes sense regarding multiple replicas.

However, I'm wondering whether we need an additional dependency for the common case of running a single operator replica. I suspect many users run replicas=1, where log retention could be implemented much more lightweight.

Would you be open to a staged approach?

• Disabled/default: logStorage.mode=disabled (default)
  This is the current state.

• Minimal: logStorage.mode=memory
  Keep "last run" logs in an in-memory ring buffer, bounded by maxRuns/maxBytes/maxLines.
  No extra components, works well for replicas=1, and logs only disappear on operator restart. Still a big improvement with zero dependencies.

• Intermediate (single-replica persistence): logStorage.mode=sqlite (or similar)
  Store logs locally using a lightweight embedded database such as SQLite.
  This would allow logs to survive operator restarts without introducing external dependencies.
  It would mainly target replicas=1 setups where local persistence is sufficient.

• Advanced/optional: pluggable backend for HA/multi-replica setups (e.g. Valkey/Redis)
  This would make log access consistent regardless of which operator replica serves the request.

This way the chart stays simple for the 1-replica case, while multi-replica users can opt into a shared store.

For the advanced backend, it would be great if the Helm chart supports both options:

• Bring-your-own Valkey/Redis via connection settings (host, port, tls, auth, db, etc.)
• Optional chart deployment (e.g. logStorage.redis.deploy=true) for users who want a turnkey setup

Overall this approach could cover most common use cases, from simple single-replica setups to HA deployments, without forcing additional dependencies on everyone. The different storage backends could also be implemented incrementally and independently over time.

[jduepmeier]

I like the different modes but for the HA setup if would prefer an object storage (like s3) as target.