diff --git a/infrastructure/vps-standby/gitlab/manifests/ha-postgres-app-externalsecret.yaml b/infrastructure/vps-standby/gitlab/manifests/ha-postgres-app-externalsecret.yaml
index c833806..8b827a0 100644
--- a/infrastructure/vps-standby/gitlab/manifests/ha-postgres-app-externalsecret.yaml
+++ b/infrastructure/vps-standby/gitlab/manifests/ha-postgres-app-externalsecret.yaml
@@ -2,10 +2,27 @@
 # (apps/gitlab/manifests/ha-postgres-app-pushsecret.yaml has home's half).
 # Pulls the authoritative app-role passwords back down here.
 #
-# Merge (not Owner/Replace): only overwrites the `password` key, leaving
-# CNPG's own generated host/dbname/username fields intact - those are
-# correctly LOCAL to each site (this secret's `host` key points at the
-# VPS's own local -rw service, which CNPG itself still needs internally).
+# creationPolicy REVERTED Merge -> Owner 2026-08-22: Merge assumed CNPG
+# itself would generate a base pg-gitlab-app/pg-praefect-app secret
+# (host/dbname/username keys) for this ExternalSecret to merge a
+# password into - true for a normal owning/primary Cluster, but WRONG
+# for these VPS Clusters since Phase 1c's recreate: `pg-gitlab`/
+# `pg-praefect` here are bootstrap.recovery REPLICA clusters
+# (replica.self: vps) - the `app` role is part of the replicated
+# global role/password state streamed from home's primary, so CNPG
+# correctly never creates a local owner secret for it here. Merge had
+# nothing to merge onto -> ExternalSecret condition
+# "SecretMissing/CreationPolicy=Merge" -> pg-gitlab-app never existed
+# -> vps-gitlab-webservice crash-looped on
+# ActiveRecord::DatabaseConnectionError for ~39h before this was
+# caught (confirmed live, unrelated to any same-day change). Owner:
+# the ExternalSecret creates the whole secret itself. This chart only
+# ever reads the `password` key from it - host/port/dbname/username
+# are hardcoded directly in infrastructure/vps-standby/gitlab/
+# values.yaml's global.psql/global.praefect.psql blocks, not read from
+# this secret's other keys, so a password-only Owner-created secret is
+# sufficient (confirmed live: no other consumer of this secret's keys
+# found).
 apiVersion: external-secrets.io/v1
 kind: ExternalSecret
 metadata:
@@ -18,7 +35,7 @@ spec:
     kind: ClusterSecretStore
   target:
     name: pg-gitlab-app
-    creationPolicy: Merge
+    creationPolicy: Owner
   data:
     - secretKey: password
       remoteRef:
@@ -37,7 +54,7 @@ spec:
     kind: ClusterSecretStore
   target:
     name: pg-praefect-app
-    creationPolicy: Merge
+    creationPolicy: Owner
   data:
     - secretKey: password
       remoteRef:
diff --git a/infrastructure/vps-standby/nextcloud/manifests/pvc-restore-cronjob.yaml b/infrastructure/vps-standby/nextcloud/manifests/pvc-restore-cronjob.yaml
index 3c5caf0..e06e276 100644
--- a/infrastructure/vps-standby/nextcloud/manifests/pvc-restore-cronjob.yaml
+++ b/infrastructure/vps-standby/nextcloud/manifests/pvc-restore-cronjob.yaml
@@ -16,8 +16,20 @@
 #   kubectl -n nextcloud create secret generic nextcloud-restic-password \
 #     --from-literal=password=<home's nextcloud-restic-password>
 #
-# Nextcloud itself isn't running (replicas: 0, see values.yaml) so there's
-# no live-write conflict risk overwriting the PVC on every run.
+# CORRECTED 2026-08-22: the "replicas: 0" assumption below was wrong -
+# confirmed live vps-nextcloud actually runs continuously at replicas: 1
+# (no replicas key was ever set in values.yaml; the chart's own default
+# applies). This job had been silently failing every run for 2+ days as
+# a result: restic couldn't overwrite the live pod's config.php (mode
+# 0640, owned by www-data/33; this job runs as UID 65534 with only
+# group 33 via fsGroup, so it can read but not write that one file) -
+# "ignoring error for /data/config/config.php: permission denied",
+# Fatal: 1 error, even though the other 31000+ files/15GiB restored
+# fine every time. Fixed by excluding config.php from the restore
+# below rather than chasing permissions - overwriting a live, running
+# app's own config.php from a background restore job is the wrong
+# move regardless (it holds this site's actual current db credentials,
+# etc.), not just a permissions bug to route around.
 apiVersion: batch/v1
 kind: CronJob
 metadata:
@@ -64,7 +76,7 @@ spec:
                   fi
 
                   echo "==> Restoring latest snapshot into /data..."
-                  restic restore latest --tag nextcloud --host nextcloud-k8s --target /
+                  restic restore latest --tag nextcloud --host nextcloud-k8s --target / --exclude /data/config/config.php
 
                   echo "==> Done."
               env: