[faust-renovate]

This PR contains the following updates:

Package	Update	Change
mirror.gcr.io/library/nextcloud (source)	major	34.0.5-fpm-alpine → 35.0.2-fpm-alpine

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.

[faust-renovate]

konflate · #1776 — feat(container)!: Update image mirror.gcr.io/library/nextcloud (34.0.5 ➔ 35.0.2)

Warning

• mirror.gcr.io/library/nextcloud: major image version bump 34.0.5-fpm-alpine → 35.0.2-fpm-alpine; likely breaking changes

Note

2 resources changed across 2 apps

image	from	to	upstream
mirror.gcr.io/library/nextcloud	34.0.5-fpm-alpine@sha256:a71718…	35.0.2-fpm-alpine@sha256:ee5b56…	✅

_{konflate 0.6.6 · rendered 14defe4}

[faust-review]

Confidence Score: 3/5

[Critical risk] The reported P1 identifies forward-only database migrations without a verified pre-upgrade backup, limiting readiness to merge. Risk is critical because persistent schema changes can leave the service down in a state that reverting the image cannot repair.

Not approved: confidence 3/5 is below the threshold of 4

Findings

• [P1] kubernetes/apps/nextcloud/nextcloud/app/helmrelease.yaml:62 Major bump runs irreversible DB migrations with no pre-upgrade backup step · reliability
• [P2] kubernetes/apps/nextcloud/nextcloud/app/helmrelease.yaml:62 Probes on /status.php restart the nginx sidecar during the upgrade window · reliability

Summary

Bumps the Nextcloud app image from 34.0.5 to 35.0.2 (fpm-alpine)

A single-line major image bump of mirror.gcr.io/library/nextcloud, tag and digest together, consumed by the nextcloud HelmRelease whose chart is pinned at OCIRepository tag 9.4.1. That chart's appVersion is already 35.0.2, so the image and chart line up, and konflate's render shows the change reaching the cluster as the image string on the nextcloud and nextcloud-cron containers only. The chart's default nextcloud.strategy is Recreate and this release does not override it, so merging terminates the running pod and starts the 35.0.2 one, whose first boot runs Nextcloud's upgrade against the nextcloud-postgres CNPG cluster and the data on nextcloud-data-nfs-pvc. Expect a downtime window for that boot, and treat it as forward-only: after the migrations land, reverting this line restores 34.0.5 binaries over a 35 schema. After merging, check that /status.php reports installed and version 35.0.2 and that the pod is not restart-looping.

Review context · 7 sources · 6/7 commands

• Sources:
  • https://redirect.github.com/nextcloud/docker/releases
  • https://redirect.github.com/nextcloud/server/releases
  • https://redirect.github.com/nextcloud/server/releases/tag/v35.0.0
  • https://redirect.github.com/nextcloud-releases/server/releases/tag/v35.0.0
  • https://redirect.github.com/nextcloud-releases/server/releases/download/v35.0.0/changelog-v35.0.0.md
  • https://raw.githubusercontent.com/nextcloud/docker/master/README.md
  • https://redirect.github.com/nextcloud/helm/tree/nextcloud-9.4.1
• Commands run: curl fd gh konflate rg yq

The review's agent was told to submit what it had found on the last step it may take, so it may not cover all it meant to check.

_{Reviews (1) · Last reviewed commit: "feat(container)!: Update image mirror.gc..." · self-qwen3.8-flash-next/low}

[faust-review]

[P1] Major bump runs irreversible DB migrations with no pre-upgrade backup step · reliability

This is the step where Nextcloud applies database schema and appconfig migrations (the 35.0.0 changelog carries new migrations and appconfig-key rewrites with repair steps, e.g. server#60002 and server#61428) against the nextcloud-postgres CNPG cluster and the data on nextcloud-data-nfs-pvc. Those migrations are one-way: reverting this HelmRelease line brings back the 34.0.5 binaries, but the database already holds the 35 schema, a combination Nextcloud does not support, so a git revert is not a rollback. The chart's own strategy comment (type: Recreate) shows the upgrade is meant to run alone rather than with the old pod alongside, so a failed first boot leaves the app down until it is fixed forward or restored from a backup. Nothing in the repo pins or checks a pre-upgrade backup for this app, and installed apps on the data volume must already have 35-compatible releases or the upgrade aborts partway.

Suggested fix

Take an on-demand backup of the nextcloud-postgres CNPG cluster before merging, and confirm every app in /var/www/html/data/apps ships a Nextcloud 35 release. Keep in mind the merge is forward-only: state in the PR that rollback is a cluster restore, not a revert of this line.

Prompt for a coding agent

Before merging, take an on-demand backup of the CNPG cluster nextcloud-postgres in the nextcloud namespace (the ScheduledBackup ${APP}-postgres in kubernetes/components/database/postgres/standalone/cluster/scheduledbackup.yaml runs on a schedule, not on this change) and confirm the apps installed under /var/www/html/data on nextcloud-data-nfs-pvc have Nextcloud 35 compatible releases. Record the verification in the PR; do not rely on reverting this commit as the rollback path.

[faust-review]

[P2] Probes on /status.php restart the nginx sidecar during the upgrade window · reliability

The chart renders liveness and readiness probes against /status.php with initialDelaySeconds: 10, periodSeconds: 10 and failureThreshold: 3 by default, and startupProbe is enabled: false by default; this release sets none of the three. With nginx.enabled: true the probe block for the main container is inside the if not .Values.nginx.enabled branch, so the nextcloud-nginx sidecar is the container that carries them. During the 34 to 35 boot the instance sits in maintenance mode, /status.php answers 503, and kubelet restarts that container roughly every 30s for as long as the upgrade takes, which keeps the site unreachable and buries the upgrade in restart noise instead of letting it finish.

Prompt for a coding agent

Add a top-level `startupProbe` key to spec.values in kubernetes/apps/nextcloud/nextcloud/app/helmrelease.yaml (next to `resources`, keeping the file's alphabetical key order), e.g.:

    startupProbe:
      enabled: true
      initialDelaySeconds: 30
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 60
      successThreshold: 1

The chart renders these against /status.php on the nextcloud-nginx container, which is the only container carrying probes while nginx.enabled is true.